[SzakiLaci]

Tabs do not recalculate size if using ScaleBy();

[attachment=9342:sPageControl scaleBy2.png]

[attachment=9343:sPageControl scaleBy.png]

[Support]

I will check it soon.

[SzakiLaci]

Anyway, this problem occures at non-scaled design time cases too!

Code:

page.UpdatePadding; >> does not help
page.TabSpacing := 1;>> does not help
page.Realign; >> does not help
page.Caption := … >> changing does not help

So how do I force-update it?

[Support]

Hello!

If you are using a code like “sPageControl1.ScaleBy(150, 100)” then control have a standard behavior.

Tabs are not changed because font is not changed (tabs autosized there).

So, try to set the ParentFont property to False before scaling:

Code:

sPageControl1.ParentFont := False;
sPageControl1.ScaleBy(150, 100);

[SzakiLaci]

'Support' wrote:

… try to set the ParentFont property to False before scaling…

Hi,

did you TRY this method?

I've tested it both design time, both runtime, but it does not do anything!

[Support]

Yes, look the demo, please

[SzakiLaci]

FOUND a temporary SOLUTION!

(but it's slowing down the loading time a bit 🙁 )

[attachment=9375:sPageControl scaleBy_Fixed.jpg]

1.) The main Problem was:

– sVirtualImageList.StdHandleUsed was set to FALSE at design time by me.

2.) WHY?

– because since last version (14.26) Loading time of my APP increased by 19000ms ! (I have 87 images and 2 virtual-lists to show them in calculated size.)

… so I had to set: StdHandleUsed = False; + UseCache =False; at design time on both VirtLists.

Before 14.26 update, code like this was running in 1ms:

Code:

sBigPicList.AcBeginUpdate;
sBigPicList.Height := 80; // this is a simplified example. The size is calculated according the % set + screen size.
sBigPicList.Width := 80;
sBigPicList.UseCache := True;
sBigPicList.AcEndUpdate(False);

After update > at each line stopped for 4-6000ms.

3.) Trial 1 – OK, but too slow:

It WORKS, if I'm turning it on at first line:

Code:

sBigPicList.AcBeginUpdate;
sBigPicList.StdHandleUsed := True; //760ms
sBigPicList.Height := 85; // 4600ms
sBigPicList.Width := 85; // 6900ms
sBigPicList.UseCache := True; // ?ms
sBigPicList.AcEndUpdate(False);

but each line takes too much time to load.

4.) Trial 2 – Fail:

It FAILS to calculate PageControl-space properly, if I'm turning it on at last line

Code:

sBigPicList.AcBeginUpdate;
sBigPicList.Height := 85; // 0ms
sBigPicList.Width := 85; // 0ms
sBigPicList.UseCache := True; // 0ms
sBigPicList.StdHandleUsed := True; //718ms >> acBeginUpdate seems not to supress refresh 🙁
sBigPicList.AcEndUpdate(False);

5.) Trial 3 – OK + bit slow:

So the way “between” is to force-regenerat it after set:

Code:

…
sBigPicList.StdHandleUsed := True; //718ms >> acBeginUpdate seems not to supress refresh 🙁 … + 2.8MB memory comsumption
sBigPicList.AcEndUpdate(False);
sBigPicList.Loaded(); // 680ms + 2.3MB memory comsumption more. (only 0.74MB was freed between the 2 lines)

6.) Questions…

I really do not understand:

– why does a VirtualImageList needs to consume memory and CPU to PRE-generate a list of pictures what we may not even use??

– why does it have to run it twice? (Especially if the 1th line is closed inside an acBegin/End-update ?)

– why isn't it freeing those 2.8MB before regenerating the list?

7.) Memory leak

Since I've set StdHandleUsed = True again >> any time I'm opening a Form with sPageControl on it, the program can not close properly.

It reports random amount of memory leak of 11-21 pieces of: TFont + TPen + TBrush + TBitmap + TBitmapCanvas + TBitmapImage.

[attachment=9374:StdHandleUsed_Memory_leak.jpg]

(Fixing the problem = 20min. Writing this letter = 120min.)

[Support]

Please, do not use different sizes of fonts here. Discussion will be more clear in this case.

Quote:

– why does a VirtualImageList needs to consume memory and CPU to PRE-generate a list of pictures what we may not even use??

Standard handle of the imagelist used in cases when standard VCL or windows controls uses pictures via API.

For example, standard menu uses glyphs from imagelists via API functions like “ImageList_GetIcon(ImgList.Handle, i, ILD_TRANSPARENT);”

Standard imagelist handle used there and should be created by the imagelist. So, this is a question of compatibility with standard API.

When this handle is created then all icons should be converted to Icon and stored in standard format for using by API functions.

Quote:

– why does it have to run it twice? (Especially if the 1th line is closed inside an acBegin/End-update ?)

I will check it and fix it in the nearest release.

Quote:

– why isn't it freeing those 2.8MB before regenerating the list?

I need to see an example where it happens. Maybe this space used for standard part of imagelist?

Small demo-app can make a bugfixing Much faster.

Quote:

Since I've set StdHandleUsed = True again >> any time I'm opening a Form with sPageControl on it, the program can not close properly.

It reports random amount of memory leak of 11-21 pieces of: TFont + TPen + TBrush + TBitmap + TBitmapCanvas + TBitmapImage.

I will check it, but, if you have a test-app with memory leaking, then it may reduce problem solving time drastically.

[Author]

Posts