SzakiLaci

Forum Replies Created

Viewing 20 posts - 1 through 20 (of 149 total)
  • Author
    Posts
  • in reply to: [Solved] AV error at function TsAlphaImageList.GetCount #71322
    SzakiLaci
    Participant

    Tip2:

    I had always memory release problems while destroying forms with VirtualImageList on it.
    Found a solution:
    Calling this proc when form is getting destroyed solves it:

    procedure VirtPicList_FREE(var v : TsVirtualImageList);
    begin
        if v = nil then Exit;
        try
            v.ShareImages := False;
            v.UseCache    := False; // this also calls ClearImages 
            v.Clear;
        except end;
        v := nil;
    end;

    Called simply by:

    procedure TFrm_money.FormDestroy(Sender: TObject);
    begin
      VirtPicList_FREE( MyVirtList );
      ... 
      inherited;
    end;
    SzakiLaci
    Participant

    After I’ve upgraded to latest version=17.01
    this error seems to disappeared. (But not tested enough yet… so it’s not final.)

    I take it back 🙁

    It has turned out: the same error can still happen with the latest version too.
    While it’s rare compared to the old one.

    So I will put back the 2019 version, it was much much more stable and will enhance the AC code with the recommended try…finally and some try..except lines.

    in reply to: [BUG] Form.SendToBack bring the Form to foreground ! #71314
    SzakiLaci
    Participant

    This Solution WORKS fine:

    
    procedure Send_Form_to_Background(h: THandle);
    begin
        SetWindowPos(h, HWND_BOTTOM, 0,0, 0,0, SWP_NOACTIVATE or SWP_NOMOVE or SWP_NOSENDCHANGING or SWP_NOSIZE or SWP_NOOWNERZORDER);
    end;

    The “trick” is SWP_NOSENDCHANGING which prevents AC to interfere.
    link to MSDN SetWindowPos…

    SzakiLaci
    Participant

    Dear Chris2023,
    Please delete your post.
    This is not a solution.

    in reply to: [BUG] Form.SendToBack bring the Form to foreground ! #71309
    SzakiLaci
    Participant

    Dear Chris,
    Thank you for trying to help, but you have misunderstood something very much.

    1. Nobody cares, how you bring that form2 to the front. (Mouse, Show, BringToFront, SetFocus )

    2. The problem is the opposite:
    – you can not send it behind the other form !
    Because even if it is already at the back, it brings it to front. What it SHOULD NOT !!!

    SzakiLaci
    Participant

    After I’ve upgraded to latest version=17.01
    this error seems to disappeared. (But not tested enough yet… so it’s not final.)

    But, other huge errors started to appear, like:
    sendtoback-brings-the-form-to-foreground

    SzakiLaci
    Participant

    Thank you very much!
    I will change that.

    Can You please add a few more examples, what else to search for, not just “CreatePen” ?

    And yes, I’ve also noticed there are still some memory leaks in the code.
    But it seems it has improved a lot since the 2019 version.
    noticed Serge forgets to put:
    inherited Destroy;
    to the end of the Destroy procedures after all other “clearings”, instead of the beginning.

    2.
    Do you know if it’s enough to FreeAndNil(FTextTimer) a timer component, instead of first stopping it by :
    FTextTimer.Enabled := False;
    ?
    (like he does at: destructor TacCustomCombo.Destroy; )

    SzakiLaci
    Participant

    Sorry, forgot to tell: I’m using 2019.05 version: v14.29

      object sSkinManager1: TsSkinManager
        SkinsFilter = [sfiInternal]
        Effects.AllowAnimation = False
        AnimEffects.DialogShow.Active = False
        AnimEffects.FormShow.Active = False
        AnimEffects.FormHide.Active = False
        AnimEffects.DialogHide.Active = False
        AnimEffects.Minimizing.Active = False
        AnimEffects.PageChange.Active = False
        AnimEffects.SkinChanging.Active = False
        AnimEffects.SkinChanging.Time = 0
        AnimEffects.SkinChanging.Mode = atDropDown
        ButtonsOptions.OldGlyphsMode = True
        ButtonsOptions.ModalButtonsColoring = []
        Active = False
        CommonSections.Strings = (
          '[PN_ATLATSZO]'
          'TRANSPARENCY=100'
          ''
    ...
        UseCache = False
        Bitmap = {}
    
    
      object sSkinProvider1: TsSkinProvider
        AllowAnimation = False
        AllowBlendOnMoving = False
        AllowSkin3rdParty = False
        ScreenSnap = True
        AllowExtBorders = False
        UseGlobalColor = False
        AddedTitle.Font.Charset = EASTEUROPE_CHARSET
        AddedTitle.Font.Color = clNone
        AddedTitle.Font.Height = -11
        AddedTitle.Font.Name = 'Arial'
        AddedTitle.Font.Style = []
        SkinData.SkinSection = 'FORM'
    ...
    

    I guess first thing You will recommend to upgrade it, but I’m afraid something similar may happen, as last time. (Worked several month long to correct all the anomalies.)

    SzakiLaci
    Participant

    I have a suspicion that this error has to do with Thread safety somehow.

    The “new” background thread I mentioned gives “out of memory” messages too, while the program’s mem-usage is under 150MB, and the OS has min. 1GB+ free RAM.
    (As You can see from attached bugreports. That thread is called: “HatterNTAK_szal”)

    I see that from my own LOGs:
    When a TUIBQuery component tries to load max 64 tiny rows from database. (Which is very small amount of data, max 1-2 Kbytes.) It can open that table, so the try..except writes: “out of memory” error to my LOG file.
    Maybe it has nothing to do with it, but that’s my only “similar error” starting point so far.

    Also checked the VGA-memory usage, no problems there either.

    Worth to mention that I’m using FastMM4 latest module, so that should be stable too.
    ( Of course with {$define AssumeMultiThreaded} enabled )

    • This reply was modified 1 year, 3 months ago by SzakiLaci.
    in reply to: How to get the owner Form of a TsTitleButton ? #70049
    SzakiLaci
    Participant

    No.
    Self = 1 form only!
    That would “work” only, if I repeat that 58x on 58 different form.

    This:
    SaveMyFormsPosition( TForm(TsSkinProvider(tsTitleButtons(TsTitleButton(Sender).Collection).Owner).Owner ) );
    works universally. It was enough to do it once, and add sSkinProvider1TitleButtons0MouseUp on the fly to each runtime-created button.

    Tested.

    in reply to: How to get the owner Form of a TsTitleButton ? #70043
    SzakiLaci
    Participant

    I think I have found a way:
    TForm(TsSkinProvider(tsTitleButtons(TsTitleButton(Sender).Collection).Owner).Owner )

    in reply to: How to get the owner Form of a TsTitleButton ? #70042
    SzakiLaci
    Participant

    AC version: 14.29

    in reply to: Optimize an application speed #59811
    SzakiLaci
    Participant

    Recompiled the speedTest Demo with 14.29 version.

    Everyone can now download the 3 EXE files and compare speed between releases.

    (By copying results into 1 Sheet helps a lot.)

    [attachment=9436:OnShowSpeedTest_14.29.exe]

    I did not see much difference between 14.28 vs. 14.29

    in reply to: Optimize an application speed #59782
    SzakiLaci
    Participant

    After 14 hours of work, I've finished my “Ultimate SpeedTest Demo” app.

    There is a XLS file inside …_src.zip to show and compare results.

    (Inside there are 2 sheets, one runned on a 12 year old XP laptop, and a modern Core i5)

    Exe files : [attachment=9427:OnShowSpeedTest_EXEs.zip]

    Source + Excel sheet: [attachment=9428:OnShowSpeedTest_src.zip]

    To reproduce the results at the same order I recommend to:

    1. Click [Component Tests] button first

    2. Than START

    3. Click [Component Tests] button again (to run it skinned)

    I've compiled it with 14.28 and 14.03 versions of AC, but could not do it with 2015 version (10.14) because it did not compile:

    201508 [Error] RLINK32: Unsupported 16bit resource in file “E:…AlphaSkinsDemosOnShowSpeedTestMain.dfm”

    ________________

    The columns of the Excel shows, that:

    – it has been ca 10% improvement of speed during the last 4 month

    But it also shows some bugs and strange things still unresolved:

    0.) sImage is not showing (BUG)

    See: #33

    1.) re-re-repainting of the form while showing should not occur

    See: 360ms – FormShow finished. [Skinned]

    2.) Showing a PageControl 100x takes 3000ms >> but changing between the 2 Sheet takes 9000+

    #22 (Shouldn't be max 6000ms ?)

    3.) Showing an sEdit 100x takes 2x so much time if skin is turned OFF :-O

    See: #11 vs skinned

    109ms – — Finished.

    62ms – — Finished. [Skinned]

    4.) 468ms – AcEndUpdate(False); >> should be 0ms !!! (BUG)

    5.) Clearing a Cashe of a VirtualImageList should not take 400ms each time (BUG)

    (Closing a form with VirtualImageList on it >> results the same I think )

    422ms – Small pic cache CLEARED.

    6.) #41 TEST: RadioGroup + CustomColor

    Should be same fast as unskinned! (140ms), not 1500ms

    Since it should look the same.

    7.) If you compare #51 + #52 + #53 #54,

    that's most strange time difference.

    Shouldn't be self-edited 'SkinSelection' be the most slow operation? Because it's 5 time faster!

    in reply to: skinning problem with 14.28 #59774
    SzakiLaci
    Participant
    'Support' wrote:

    Yes, the NOSLOWDETAILS key used in tests mainly, it should not be used in applications.

    hmmm… in this case, this is a very confusing name choice, isn't it? (Just the opposite of what it should represent.)

    IMHO it should be renamed everywhere to:

    SLOWDETAILTEST

    or

    TEST_SLOWDETAILS

    in reply to: Manually trigger highlight #59773
    SzakiLaci
    Participant

    This topic should be moved to

    Technical support >> Tricks

    (And delete this reply I've just made here)

    in reply to: TsGroupBox painting problem #59756
    SzakiLaci
    Participant
    'Support' wrote:

    Thank you for the demo, the control will be repainted automatically in the nearest release.

    Repainting problem fixed at version 14.28,

    but there is still an ugly gray border around the title.

    (See 2th picture at #1 post)

    The problem with that is that it visually separates the Title from the things below it >> makes the whole concept of a “groupBox” pointless.

    Users are totally confused by this.

    ____________

    Anyway … I've tested to globally change style to gsCard. In this case the titlebar somehow gets much more thick (greater height) so it flows under other components.

    in reply to: CustomColor painting anomalies #59754
    SzakiLaci
    Participant

    Since Version 14.28 sCheckBox does not paint CustomColor either.

    For a few millisecond it is visible, when the background is painted, but after that it gets repainted again with normal (gray).Tried to add an extra line: ChkB.SkinData.Invalidate(True) ; // but did not help either…

    in reply to: Memory Leaks in AC 14.27 #59748
    SzakiLaci
    Participant

    This fixed 🙂

    Code:
    2196: if not CanUseCache or not FUseCache then
    2197: FreeAndNil(IcoBmp);

    You can close the topic.

    in reply to: Memory Leaks in AC 14.27 #59747
    SzakiLaci
    Participant

    [attachment=9415:sPageCtrl_Memory_leak2.jpg]

    The problem happens both with and without FastMM4 unit.

Viewing 20 posts - 1 through 20 (of 149 total)