[SzakiLaci]

I've just tested todays newest release: 13.19 Stable.

I see many improvements, but it's still not complete:

TsTreeView is still not properly drawing images.

[attachment=8862:stretch_test2.png]

______________

Setting AlphaImageList + VirtList Height or Width still takes several thousands of milliseconds!

Which is totally unnecessary, since it's only a “virtual size” !!

The only thing should happen during size-changing is:

– clear prev. cached images

– inform components using this (virt)imageList to “redraw” if visible. ( .invalidate is enough)

What it should NOT do:

– do not start any stretching operation!

– do not redraw Images having “Stretched = True”

I would solve all of these problems by creating and managing a List of components attached to each (virt-)ImageList.

So you would know what needs to be “alerted of any change”. (resizing, picture replace, etc.)

Code:

type
TattachedComponent = packed record
obj : TsWinControl;
type: enum … (sBitBtn, sImage, sTreeView …)
end;

_______________

PNG files are stored in .dfm and .exe files still in HEXA format >> taking up 16x more space than the original image.

[Support]

Hi, sorry for a delay

Quote:

TsTreeView is still not properly drawing images.

You should enable a support of manifest in the project for better drawing of glyphs with alpha-channel.

Items are drawn by Windows system there and alpha-channel just not supported if manifest is not used.

If you uses Delphi 7 and newer – just add 'XPMan' in the 'uses' clause.

Or try to replace the TsTreeView component by the TsTreeViewEx component (items are drawn by AlphaControls engine there).

Quote:

Setting AlphaImageList + VirtList Height or Width still takes several thousands of milliseconds!

Which is totally unnecessary, since it's only a “virtual size” !!

This delay exists because standard ImageList handle generated there and all images are converted to standard ImageList format for support of glyphs in standard or third-party components.

You can disable this behavior, change the TsVirtualImageList.StdHandleUsed property to False. Work of component will be faster in this case.

Quote:

PNG files are stored in .dfm and .exe files still in HEXA format >> taking up 16x more space than the original image.

I'm not sure what you mean. The TsAlphaImageList keeps format of glyphs unchanged. They are stored as Png if were loaded from Png files.

Can you show an example Dfm-file, please?

[SzakiLaci]

'Support' wrote:

Or try to replace the TsTreeView component by the TsTreeViewEx component (items are drawn by AlphaControls engine there).

It has made NO difference! Drawing images exacly the same (ugly) way 😀

'Support' wrote:

…just add 'XPMan' in the 'uses' clause.

Results:

1.) Both TsTreeView and TsTreeViewEx images became beautiful … but:

2.) ALL TsPanel backgrounds with “CustomColor=True” became TRANSPARENT ! 🙁

3.) ALL TsBitBtn background placed on those TsPanels became TRANSPARENT too! 🙁

4.) If Skin is OFF >> [background=yellow]”custom colored”[/background] TsPanels do NOT get redrawed >> causing a total chaos.

[attachment=8876:CustomColorPanels_not_drawing.png]

'Support' wrote:

… change the TsVirtualImageList.StdHandleUsed property to False.

After doing this >> ALL sBitBtn images disappeared!

'Support' wrote:

The TsAlphaImageList keeps format of glyphs unchanged.

You are right. I could not reproduce this with the current version.

And the .DFM storage is no problem, because after compiling >> it gets the orginal PNG size back.

[Support]

Hello!Can you make and upload a demo with described issues, please?

[SzakiLaci]

Can you please put back .FocusedColor property of TsBitBtn from

public >> to published ?

It's invisible now in Object inspector and the old projects can not load either.

(Version: 2018.10.0x 14.03 beta)

[Support]

Hello!

Yes, I will move it in the 'published' in the v14.04

[Author]

Posts