[JM-DG]

Something like this?

Attachments:

You must be logged in to view attached files.

[JM-DG]

Personally, I can edit my posts a few minutes after they have been created.
But the edit button does not appear anymore after a certain period of time.

[JM-DG]

Somehow the gif didn’t link.
Retry: Gif

[JM-DG]

I see it, this issue will be solved in the nearest release, I think.

Thank you for this.

In my original post, I misspoke (I was talking about trackbar but I meant statusbar).
Let me rephrase my question.

I know that there’s a way to paint skin section on a component using the “SkinSection” property.
There’s a skinsection called “Statusbar” which seems to draw the background of the statusbar.
Is there a way to draw only the grip part of the statusbar on a given component?

My goal here would be to have a panel visually have the grip section of a statusbar drawn onto itself.

[JM-DG]

Version of AlphaControls 2021 16.23 b56 is used.
I believe it’s the latest available.

[JM-DG]

True.
However, adding them in 32 bits mode, then switching to compile in 64 bits seems to work.

[JM-DG]

I tried to attach a small demo but it got blocked because of its file size & file type.
I try again with a cleanedup zip file.

Attachments:

You must be logged in to view attached files.

[JM-DG]

'Jin' wrote:

It is impossible. For example you have some function, it works 15 seconds form the begin till end. And I can put Application.ProcessMessages or something else only after this function, but it will not resolve my issue, because for all 15 seconds ArcPreloder will not show for user this function calculation process. From my point of view it is bad practice to put such string like ArcControl.Update() in your code for such kind of component.

It is bad practice to use Application.ProcessMessages()/ArcControl.Update() in a loop to force an update,

but it is also bad practice to run an intensive job on the main thread instead of having it in a separated thread of its own.

[JM-DG]

'Support' wrote:

The OnSkinChanging event occurs before loading of new skin and allows to prevent loading of the skin.

Look on the OnSkinLoading event. This event occurs when skin is loaded but not activated yet. Maybe that's what you need.

I tried the OnSkinLoading event before and it was causing me some problem… (I can't remember what)

However I just tried it again and everything worked fine.

Thank you. This is what I needed.

[JM-DG]

I see that the new event has been added.

Thank you for that. 🙂

However I thought that the event would come after the new skin information has been loaded up. +/- line 3160

After the code:

Code:

ResetSkinData;
InitCommonData;

Example:

Code:

try
ResetSkinData;
InitCommonData;
except
on E: Exception do begin
FSkinName := OldName;
ShowError(E.Message);
end;
end;

if Assigned(FOnSkinChanging) then begin
FOnSkinChanging(Self, FSkinName);
end;

If not, I have to redo some of the logic in the current onSkinChanging event in order to get the color palettes of the new skin being loaded.

Ex:

Code:

procedure TDataModule1.sSkinManager1SkinChanging(Sender: TObject;
const NewSkinName: String; var AllowChanging: Boolean);
var color:TColor;
begin
sSkinManager1.ManagerState := sSkinManager1.ManagerState + [msSkinChanging];
sSkinManager1.ResetSkinData;
sSkinManager1.CommonSkinData;
sSkinManager1.ManagerState := sSkinManager1.ManagerState – [msSkinChanging];

color := clNone;
if(not IsDarkColor(sSkinManager1.GetGlobalColor)) then
begin
color:= sSkinManager1.GetHighLightColor(true);
end;

BorderIcons.BlendColor:= color;
PlayerControls.BlendColor:= color;
LargePlayerControls.BlendColor:= color;
end;

[JM-DG]

'Stephane wrote:

I don't know if “Support” was confused between the look of the glyph when the button is Enabled = False and the Grayed property of the BitBtn, but I was. So I though I could add my input.

I too find it weird that the discoloration of an icon that has no color changes of color.

It is like if the icon was blended with the button color.

Yeah, thanks for your input. Sometimes I have a hard time expressing myself correctly in english. 🙂

[JM-DG]

'Support' wrote:

Which behavior do you expect?

Well I don't understand

why the glyph becomes slightly colored (light red) when grayed = true & the imagelist colorblend = clNone

But becomes actually grayed when grayed = true & the imagelist colorblend = clRed (example).

Why is it not grayed in both instances?

I'm not sure of what behavior to expect,

but in one instance (grayed = true) = glyph is colored

and in another instance (grayed = true) = glyph is actually grayed.

[JM-DG]

It may be unrelated but I realised that the grayed property of the bitbtn seems to behave inconsistently.

Let say I use an imagelist with an unchanged blendcolor clNone with white glyphs:

– The normal glyph color will be white: ok.

– When I set its property grayed to true, it becomes slightly colorblended depending of the skin (not grayed).

But then, when I use an imagelist with a custom blendcolor (let's say clred) with white glyphs:

– The normal glyph color will be red: ok.

– When I set its property grayed to true, it becomes properly grayed.

So my question is:

“If I use an imagelist with an unchanged blendcolor clNone with white glyphs & I set its property grayed to true, it becomes slightly colorblended depending of the skin (not grayed).”

Why is that?

[JM-DG]

'Saeidd2016' wrote:

Hello,

There is a new problem in version 14.23 . When we set a TsAlphaImageList as image list of TVirtualTreeView component, it only shows grayed images and doesn't show colored images.

It seems to be related to the recently changed BlendMode to the TsAlphaImageList component.

I made a demo testing the new feature and there are a few unexpected results. This is one of them.

I'll share the demo when I'll get home.

[JM-DG]

'Support' wrote:

Hello

Sorry, I was planning to make it like in standard ImageList.

But when I was researching a behavior of standard component then I have found that this behavior is very strange and unexpected and I was a bit confused.

So, I need to specify, which behavior do you expect from this property?

Ultimately what I try to achieve is this:

When there's a “dark skin” loaded, the icons contained in my TsAlphaImageList would be color blended to a given light color

& when a “light theme” is loaded, the icons contained in the same TsAlphaImageList would be color blended to a given dark color.

Since all the buttons with icons in the application are using this ImageList, they would all be updated to be color blended correctly.

So I would expect this property to do the same thing as the buttons GlyphColorTone property does.

But it would color all the icons contained inside the TsAlphaImageList to a given color & update all the buttons which use this centralized imagelist throughout the application.

In this example, since there's simply 2 buttons, maybe you don't understand the use. But in a full-blown application with multiple windows/units with multiple controls using icons, it would be awesome to change 1 property of the centralized TsAlphaImageList which would update the color of all icons throughout the whole application.

Example:

[JM-DG]

I'm still eagerly looking toward this feature. 🙂

[JM-DG]

'TAZ' wrote:

I downloaded your project. I find it interesting in that if you cycle the page control tabs that it now behaves (at least on my computer). I have no explanation as to why it straightens out.

Yes, same thing on my end. I noticed this when explaining the behavior to someone else.

[JM-DG]

'dxMos' wrote:

Hello,

just for information!

Delphi 5 + Ver.14.20

I have to replace …

Code:

if CharInSet(Key, [#32..#255]) and

with

Code:

if (KEY IN [#32..#255]) and
(FDataLink.Field nil) and
not (Key IN ['0'..'9']) and
(Key {$IFDEF DELPHI_XE2}FormatSettings.{$ENDIF}DecimalSeparator) and
(Key '-') then begin

Thomas

I just added the file acntUtils in the uses of the problematic files & everything worked out.

[JM-DG]

'Support' wrote:

Thanks for the demo.

The issue is not repeated with latest versions of the Delphi.

I will think how to improve it in the neareast release.

With some tests, I realised that it can be as simple as simply removing the “SWP_NOREDRAW” flag from the cFlags constant.

I dunno if it's a good solution though.

[JM-DG]

'TAZ' wrote:

For curiosity sake, I downloaded the project. I then ran JM's compiled exe and verified that the second window background is missing. You have to move the mouse over for it to show.

I then loaded the project into my Delphi IDE and compiled it. Then ran the exe from (1) the IDE and (2) as a stand alone and the problem did NOT occur. The second window background appeared when called.

Not sure if this helps.

Windows 7 Ultimate, Delphi 10.2.3, AC 14.18

So it would be a Delphi7 problem only? <_<

[Author]

Posts