[SzakiLaci]

Dear Support,

sComboBox component can not handle properly ScaleBy at all.

1. Problem:

– ItemHeight property is not calculated properly (including windows-dpi)

[attachment=9370:sComboBox_ItemHeight_error.jpg]

2. Problem:

– if set manually at runtime (to fix 1. problem) & also CustomColor=True >> only half is painted. (looks ugly + users can not understand the proper usage)

[attachment=9369:sComboBox_ItemHeight_Paint_error.jpg]

Currently I need to run 2 procedures on ALL forms after OnActivate + ScaleBy >>

– to search ALL components and recalculate size.

– and to do this on Frames too

So windows are opening slow with flickering 🙁

[Support]

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

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.

Can you show a demo with slow recalculating and repainting?

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?

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

[Support]

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.iz.hr/delphi-high-dpi-road-ensuring-your-ui-looks-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.

[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

[Support]

It's a lack of this skin, border is drawn with bold white parts there.

Borders are drawn over a colored background, that's why white parts are drawn over the colored background.

When component is in edit mode, then edit are is filled over borders, it looks like a better drawing.

So, skin should be changed for avoiding this issue.

[Author]

Posts