Recent

Author Topic: Hiding Memo's scrollbars  (Read 7630 times)

anna

  • Sr. Member
  • ****
  • Posts: 426
Hiding Memo's scrollbars
« on: May 04, 2010, 11:36:50 am »
When I make Memo's ScrollBars property equal to ssAutoHorizontal, ssAutoVertical or ssAutoBoth , scrollbars appear in all cases (even if there is no text in Memo). But they mustn't. Scrollbars must appear when text goes out of vertical or horizontal  border.

So, how to hide scrollbars when text does not out of Memo's border ?
(http://img85.imageshack.us/img85/9122/45254828.png)
« Last Edit: May 04, 2010, 11:55:32 am by anna »
WinXP SP3 Pro Russian 32-bit (5.1.2600)

Wodzu

  • Full Member
  • ***
  • Posts: 171
Re: Hiding Memo's scrollbars
« Reply #1 on: May 05, 2010, 06:15:57 am »
I think that there is no such additional option in the TMemo itself.

What you need to do is to look into the source of TMemo and track the behaviour of scrollbars.
When they are set in ssAuto they are disabled by default but visible. When you are inserting some text into it at the length of the text line is greater than the length of the TMemo horizontal scrollbar is enabled. You must track the code responsible for it and observe how internal state of scrollbars is changed. Then you will be able to change it as you want.

I've tried to find that line of code but was not able to. I do not know Lazarus \ LCL good enough.

Actualy I am confused by the Lazarus code policy. Why there is a code in the *.inc files???

For example custommemo.inc. Why do we have atleast 3 file extentions for the code: .pas .pp .inc? Why not to keep the code in PAS and some conditional defines in the INC file?

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4536
  • I like bugs.
Re: Hiding Memo's scrollbars
« Reply #2 on: May 07, 2010, 10:00:03 am »
Actualy I am confused by the Lazarus code policy. Why there is a code in the *.inc files???

For example custommemo.inc. Why do we have at least 3 file extentions for the code: .pas .pp .inc? Why not to keep the code in PAS and some conditional defines in the INC file?

.inc files are a way to split the code into many files but still avoid circular reference problem. Usually interdependent classes must be placed in one file because they would create circular references otherwise. FPC and Lazarus codetools support .inc files well so it is a working solution.

Regards,
Juha
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2614
Re: Hiding Memo's scrollbars
« Reply #3 on: May 07, 2010, 05:44:18 pm »
Actualy I am confused by the Lazarus code policy. Why there is a code in the *.inc files???

For example custommemo.inc. Why do we have at least 3 file extentions for the code: .pas .pp .inc? Why not to keep the code in PAS and some conditional defines in the INC file?

.inc files are a way to split the code into many files but still avoid circular reference problem. Usually interdependent classes must be placed in one file because they would create circular references otherwise. FPC and Lazarus codetools support .inc files well so it is a working solution.

Nope, that is not the reason.
For the compiler, the inc files still act as if they were part of a unit. So no solution to circular references.

The split is more historical when we worked with a lot of ppl on the same units so when checking in there were less chances on a merge conflict. Indeed, FPC and Lazarus handle them well (better than Delphi) so, in most cases you don't even notice that you are in a .inc file
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4536
  • I like bugs.
Re: Hiding Memo's scrollbars
« Reply #4 on: June 06, 2010, 02:46:12 am »
Nope, that is not the reason.
For the compiler, the inc files still act as if they were part of a unit. So no solution to circular references.

The split is more historical when we worked with a lot of ppl on the same units so when checking in there were less chances on a merge conflict. Indeed, FPC and Lazarus handle them well (better than Delphi) so, in most cases you don't even notice that you are in a .inc file

Sorry, I didn't notice this reply earlier.

There were long discussions on mailing lists about how to prevent circular reference with interdependent classes. The classes must be in one big unit file or then split into .inc files.
This is one such thread:
 http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg16051.html

Your split seems to have the same motive. Why didn't you split the code into separate units? Because of circular references! So, the only choice was to use .inc files.

I have heard a comment from a professional programmer that Delphi is not suitable for big projects because you must put everything into one big file.
I also used to think it's a big problem but I have changed my mind. With a good IDE you can manage big files well, and you can use .inc files to split them if needed.

Juha
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

 

TinyPortal © 2005-2018