sPageControl ScaleBy bug

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #38286
    SzakiLaci
    Participant

    Tabs do not recalculate size if using ScaleBy();

    [attachment=9342:sPageControl scaleBy2.png]

    [attachment=9343:sPageControl scaleBy.png]

    #59614
    Support
    Keymaster

    I will check it soon.

    #59654
    SzakiLaci
    Participant

    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?

    #59657
    Support
    Keymaster

    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);
    #59659
    SzakiLaci
    Participant
    '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!

    #59660
    Support
    Keymaster

    Yes, look the demo, please

    #59663
    SzakiLaci
    Participant

    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.)

    #59665
    Support
    Keymaster

    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.

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.