[SzakiLaci]

'Support' wrote:

SzakiLaci, I think, your memory leak is not linked with PageControl, reason is same as in a leak reported by HeDiBo (ImageList with disabled UseCache property).

I think, this memory leak is removed already, changes will be available in the nearest release.

Upgraded to v14.28

Memory leak is STILL THERE! Also in the DEMO app I've uploaded for you.

To reproduce the problem you can simply:

1.) move the mouse up & down & up & down …. over the pagecontrol's TABs

or

2.) scroll the whole window up & down

[SzakiLaci]

[attachment=9411:PageControl_MemLeak.zip]

move mouse up and down many times on the tabs, so they highlight for a moment.

[SzakiLaci]

'Support' wrote:

Which type of button do you use here? TsSpeedButton?

TsBitBtn.

[SzakiLaci]

'Support' wrote:

I'm sorry Dick, my message was addressed to SzakiLaci.

I can send you new files where your reported memory leak is removed (by PM).

Thanks for the reply!

Yes, I'm using FastMM4 too.

It is strongly recommended for Delphi7.

But program's memory usage is increasing too, (measuring with Process Hacker), so it's definitely not a “false alarm” of FastMM4 debugger.

I'll create a DEMO.

[SzakiLaci]

'HeDiBo' wrote:

may create a TBrush which is not freed when rShadowBmp is freed

Do you think this can affect sPageControl component too?

Currently it has a huge memory leak too >> whenever hoovering the mouse over TABs, it creates a new BMP + Brush +++ never freed.

(3-600 of them pro minute, if someone is actively moving the mouse)

It completely ruined my APP, users calling me every day…

Reported the problem a week ago, no fix yet.

(WTF is happening to Serge lately ???)

[SzakiLaci]

'Stephane wrote:

I'm trying to figure out why a form in my app does not scale.

Can you tell my where the scaling occurs in AlphaSkins libraries?

Are you using it the default delphi-way? (OnShow event)

For me, this works:

Code:

type
Form1 = class(TForm)
…
private
already_scaled_once: Boolean;
end;
…
procedure TForm1.create(Sender: TObject);
begin
already_scaled_once := False;
end;

procedure TForm1.FormShow(Sender: TObject);
if not already_scaled_once then begin
already_scaled_once := True;
ScaleBy(200,100);
end;
end;

(In this case it works even if the Skin turned OFF.)

[SzakiLaci]

Here is a DEMO to simulate both cases:

[attachment=9403:TGroupBox_paint.zip]

[SzakiLaci]

'SzakiLaci' wrote:

This is what I ment by: “it should draw the upper-part of bigger fonts on top of the title bar.” >>

[attachment=9366:submenu_override.jpg]

Any progress on Overdrawing on the outside elements? (Title bar)

________

Also I have noticed, the skinned draw happens AFTER normal menu is drawn first.

Since I'm using a 10+ year old (XP) laptop to test speed, I can visually SEE the update happens 2x. (1th: normal menu is drawn, after that 2th skinned menu is overdrawn)

[SzakiLaci]

'Support' wrote:

Try this code, it's enough, I think:

Code:

var
…
N31.Caption := N31.Caption + ' ';
end;

CustomFont is not required, maybe.

No, sadly it does NOT work. That was the first thing I've tried.

As I've wrote before: I'm over ca. 30 different scenarios, spent 1.5 days with it.

CustomFont IS required too!

… except you have changed something in your code at 14.26 >> 14.27 ?

[SzakiLaci]

'Support' wrote:

You can try to change the SkinData.SkinSection property to 'GROUPBOX' or 'TRANSPARENT'

Maybe these skin section will be better for such case.

Hi,

I've spent this day and the day before, to figure out more about these problems:

• Changing a panel's SkinSelection to 'UNKNOWN' solves the problem.[*]So probably 'TRANSPARENT' would help at other cases too.[*]You were right about the Skin-difference! If I choose something else than the default (Golden) skin >> the “under-white” line gets smaller.

But the problems with these “solutions” are:

• Changing every each panel + groupbox + editboxes +++ one by one is an impossible missions :huh:[*]This problem is relative new (If I look back pictures from 2 years ago >> everything was fine than).[*]If I set somewhere CustomColor := True; >> As a user, I obviously expect it would draw THAT color what I've set before at .Color := clBlue; Not half of it.

So I think a skin should NEVER be able to overdraw my Color, what I've set, if CustomColor= True;

(Otherwise what would be the purpose of CustomColor setting ??)

• Analized “Golden” skin, but can not figure out, what's the difference between that and other skins.

It looks completely standard:

Code:

GLYPHMASK = @0117@0276@0174@0310@3@1
PARENTCLASS = EDIT
SHOWFOCUS = TRUE
STATES = 1

There is not even a color-definition or any thing else.

Cheers

[SzakiLaci]

'Support' wrote:

I think, buttons without skins should use the ShowFocus property only.

They should not depend from TsSkinManager.ButtonsOptions.ShowFocusRect property if have standard look.

How you think?

Sounds like a perfect solution! :a3:

[SzakiLaci]

'HeDiBo' wrote:

Suddenly, I find a focus rectangle on TsButton, that I did not see before…

Hi, 🙂

I just would like to mention there is a nice way to show :

which TsBitBtn has the focus at NON-skinned mode, by setting the .FocusedColor := clLime; property.

It may has nothing to do with this new problem… just would like to recommend a bit precaution, because it is related to “non-skinned focus” things.

So any new update regarding this may affect that behavior too, since it is a bit hard to test each property setup in every possible variations.

(Delphi GeExpert addon has a great feature to replace all components on the form at once. TsButton >> TsBitBtn.)

Cheers

PS: could you please edit your first topic to announce which version do you experience this new behavior? (After upgrading from which?)

It will help Serge too… 😉

[SzakiLaci]

'Support' wrote:

Standard ComboBox can have a wrong scaling in some cases, that's why I wrote about limitations. Look this article (a part about ComboBox):

https://zarko-gajic….ooks-correctly/

But, I have made some tests and TsComboBox was working well there in csDropDownList and csDropDown styles.

And I have added TsComboBox in your demo with ScaleBy calling and it was scaled well there too.

If you have a small demo with bad TsComboBox scaling, can you give me it? It may much reduce a time of the problem solving.

Thanks, I'll read it!

– I've just thought if you know about a problem of the original Delphi component, you are trying to fix if by overriding it. Don't you?

(Or it's just not possible in this special case?)

– Anyway I've just realized: the painting problem is global! Even simple sEdit components set with CustomColor := True; show same symptoms:

(Coloring them while stepping on them = OnEnter / OnExit)

[attachment=9383:CustomColor_Edit_draw_BUG.jpg]

PS: please correct title spelling mistace: Itemheit > Itemheight

[SzakiLaci]

'Support' wrote:

sComboBox is inherited from standard TComboBox and have standard limitation in sizing by ItemHeight property.

What kind of “limitation”? If I can set ItemHeight > an enhanced=derived component shouldn't be able to calculate this property itself based on font-size + dpi?

Quote:

I think, you can play with size of font for automatic changing of a control height. Maybe, set ParentFont property to False before “ScaleBy” calling.

That is what I'm currently forced to do. But searching hundreds of ComboBoxes one by one on 60 forms is not really someone wish, if buys a “ready to use” component pack. Don't you agree?

And that won't solve the painting bug!

Quote:

Maybe, set ParentFont property to False before “ScaleBy” calling.

Setting 1 property one by one and hoping it will be good … or calculating the right height is almost the same amount of work.

Quote:

Can you show a demo with slow recalculating and repainting?

🙁 if I have time I'll make a demo for this too… anyway I said nothing about “SLOW”, but “BAD”!I've already waisted more than a week to report ALL these bugs.

Quote:

By the way, you saw the TsSkinManager.Options.PixelsPerInch property? You can look it in work in the ASkinDemo or AMegaDemo

Maybe you can use this new feature instead of old “ScaleBy” using?

The last time I've checked, it did NOT work, if SKIN was turned OFF.

Skinned APP runs 16-32x slower.

On tablet PCs + no-fan POS PCs using ATOM CPUs + while using remote desktop >> skin has to be turned OFF to be able to run the APP properly.

[OFF] sorry, for beeing in such bad mood, but I really believed about this 14.26 version is stable. Now I'm behind schedule of 2 weeks because all of these problems, Now I have to cancel jobs, vacation, etc. And when I read here about bad tips instead of you would fix the a bug… [/OFF]

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

[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!

[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?

[SzakiLaci]

[Dirty Solution]

After trying 30 different ways, the ONLY solution I have found is:

(Using the patched sSkinMenu.pas file Serge sent me.)

Code:

procedure TFrm_MenuSize.mmResize();
var f: integer;
MI: TMenuItem;
begin
f := round( (Screen.PixelsPerInch / 96) * sspe_FontSize.Value) ;
if not sSkinManager1.Active then begin // NON-SKINNED
Screen.MenuFont.size := f;
Screen.IconFont.size := f;
end
else begin
// sSkinManager1.MenuSupport.CustomFont := False;
sSkinManager1.MenuSupport.Font.Size := f;
sSkinManager1.MenuSupport.Font.Style := [fsBold]
sSkinManager1.MenuSupport.ExtraLineFont.Size := f+2;

sSkinManager1.MenuSupport.CustomFont := True; // <<< THIS IS the most important line !!! It will re-build the font

// sSkinProvider1.RepaintMenu(); // FAQ says it needed, but it does not help fully http://www.alphaskins.com/afaq.php#T2
// sSkinProvider.UpdateSkinCaption(sSkinProvider1);
end;

MI := MainMenu1.Items[MainMenu1.Items.count-1]; // last item … so it won't flicker too much
MI.Visible := not MI.Visible; // turn OFF / ON … or the opposite >>> it will recalculate all item's WIDTH
MI.Visible := not MI.Visible;
end;

[SzakiLaci]

This is what I ment by: “it should draw the upper-part of bigger fonts on top of the title bar.” >>

[attachment=9366:submenu_override.jpg]

[SzakiLaci]

'Support' wrote:

Thank you for the demo.

Look what I see.

When font size is changed without skins then font is changed in popup menu only

When font is changed with skins then font is changed in popup menu and in the menu line (this is a new behavior, previous behavior was like standard).

PS. Can we chat in the Skype? It's more effective, I think.

Hi,

YES, but I can force-refresh non-skinned menu >> so it's fine!

But I can not:

– repaint skinned menu after font change >> nothing happens

+ it should draw the upper-part of bigger fonts on top of the title bar.

This 2 things needs to be fixed.

You have to know : your forum system usually does NOT sends any notification, if a topic changed! (Even if Watching is > ON >> and “immediate” is set.)

I'm PM-ing you my SkyPe. (I don'T know yours)

Thanks!

[Author]

Posts