A very simple SetGadgetColorEx() function [Windows]

[Zapman]

Looks cool, thanks for sharing !

Merci Fred !

[Zapman]

[Improper handling]

[Zapman]

The codes above had been updated to correct some minor bugs, to add commentaries and to improve functionnalities.
If you want a complete set of the Zapman's color libraries, you can download it from https://www.editions-humanis.com/downlo ... ads_EN.htm

[Ziltch]

Very Useful Code !!!

Thanks for sharing.

[Zapman]

The code figuring in the first post has been updated again.
It is faster for all gadgets, but especially for large gadgets such as PanelGadgets.
ComboBox and ListIcon are now better supported.

[HeX0R]

I was testing your code with my DialogDesign0r, starting up went flawlessly, and all looked pretty good and coloring was very fast.
But when I switched themes (which initiates quite some SetGadgetColor-commands), i first was thinking, "hmm... only some of the gadgets got a new color, something might be wrong".
Then I wanted to close DD, but nothing happened, which let me guess, your code is burning events somewhere.
So I was waiting and waiting and waiting, and out of a sudden the other gadgets got colored very slowly.
I think it took more than 3 minutes until all gadgets got their new color.
When trying to find the reason, I stumbled accross this code line:

Code: Select all

For ct = 1 To 50 : WindowEvent() : Next

What kind of construct is that?
I first changed it into

Code: Select all

While WindowEvent() : Wend

And it took ~30s, still way to long, so I removed the whole line and now it takes only 3s, which might be acceptable.
I didn't see any difference (besides speed), but I need to investigate more closer here.
[Edit]
O.k., content of the frame in your example is not drawn (before you hover the mouse over it)

btw.:
I've added:

Code: Select all

Macro GetGadgetColor(a, b)
	GetGadgetColorEx(a, b)
EndMacro

Macro SetGadgetColor(a, b, c)
	SetGadgetColorEx(a, b, c)
EndMacro

to the bottom of your code, to make sure I don't have to change anything in DD.

[Zapman]

I stumbled accross this code line:

Code: Select all

For ct = 1 To 50 : WindowEvent() : Next

What kind of construct is that?

Hello HeXOR,
I'm not proud at all of the line you identified in the code. It's clearly a hack to try to fix an issue I haven't fully understood (but I think and hope it's the only one in this code).
Strangely, it looks like the FrameGadget is drawn over the gadgets it contains, and only after a few cycles of WindowEvents does everything return to normal.
I'll take a close look at this and finally solve this mystery that I haven't been able to figure out so far.
Congratulations on your ability to pinpoint the issue.
Thank you for testing, and I promise I'll be back soon with an updated code that fixes the issue.

For

Code: Select all

Macro GetGadgetColor(a, b)
	GetGadgetColorEx(a, b)
EndMacro

Macro SetGadgetColor(a, b, c)
	SetGadgetColorEx(a, b, c)
EndMacro

I think it's absolutely OK.

[Zapman]

Hi HeXOR,

First post of this subject has been updated. The version Feb 2024-4 of this code fixes the problem.
It appears that the case of the FrameGadget is quite special in that this gadget has no background. So I treated it separately, which allowed me to remove the hack that was causing the problem.

I kept your suggestion of overring the native GetGadgetColor() et and SetGadgetColor() functions.
Therefore, in theory, you don't have to do anything other than include the new version of the file.

Thanks again for your feedback.

[HeX0R]

Hmm... I liked the previous one more.
Now:

Previous:

(don't get confused, I named the pictures wrong, DD-new is in fact the previous version)

[Zapman]

As I said, the frame gadget has no background. The white you see is something behind the gadget. What is it?

[HeX0R]

o.k., got it now.
In fact you are right... and you are wrong
I was wondering why your previous code was able to color the background of my Frame when it is a transparent one.
The reason is simple:
Mine is not transparent, yours in your example is.
I then remembered, that the flag #PB_Frame_Container had been introduced in... I think PB6.02.
Which I don't use, BUT:
Mine is a dialog, and it seems as if all FrameGadgets there have the Container flag always set (which makes sense, since they always are containers in dialogs).

Conclusion:
Background of FrameGadgets in Dialogs can be colored just fine, those in Windows (when no #PB_Frame_Contaner had been set), not.

[Zapman]

I then remembered, that the flag #PB_Frame_Container had been introduced in... I think PB6.02.

Each tester makes me ask myself questions that I would not have thought of. Thanks!
The fact is that I have not yet taken care of the options that could be specified when creating gadgets.
Concerning the FrameGadget, for the moment, I do not yet know where and how I can retrieve the options specified when creating it, in order to adapt the behavior of my procedure accordingly.
I will look and come back to you with a solution.
Thanks again.

[minimy]

Very good code zapman! thanks for share!

[HeX0R]

I will look and come back to you with a solution.

Don't put too much energy into it, the result of your function is really nice (I "hacked" it already for dialogs), but it has some performance issues (high CPU load) in DD.
And in fact, I was not going to use it for that project anyway, because it is considered to be cross-platform.
I was more interested in the look & feel.
But it might be useful for an upcoming project.
Keep up the good work!

[Zapman]

Don't put too much energy into it, the result of your function is really nice

This library, as all the other I published, is still in progress.
Your remark heps me to find its weaknesses and to work on it for all users (including myself). So, I'ff fix that like all other signaled problems.
I'm almost there. I'll post a new version tomorrow.

it has some performance issues (high CPU load) in DD.

By principle, the chosen method consisting to let the gadget to be drawn and replacing colors after the fact, inevitably consumes a bit more CPU. But the operations can be optimized, as I have already done since the first versions, and this may improve further in the future.
Thank you very much, HeXOR.