[RESOLVED] Background button color in themed button

Hi everyone... old VBforums user here, fairly advanced I would say. Last time I connected here was some 8 years ago.

I am here to get advice on a long list of overdue issues in order to make my programs look and perform better. And for those who may have had the question on their mind, all VB6 programs work totally fine on Windows 10 Technical Preview. All GDI, even the 16 legacy calls, all GDI+, everything. Win 10 s****s, but that's another matter ;

So first things first, and one topic at a time.

I am using InitCommonControls along with a manifest file to get themed look. It's all working very well except for one thing. The background color all around the button remains the standard greyish VB6 form background color. It's does not look all that bad on the standardized light bluish background color I use for my programs, but in some areas, like when I put my command buttons in a picture container whose background is darker, they don't look as good. I tried hardsetting the backcolor before compile, but no avail.

Is there an API call I can use to change the backcolor of themed command buttons?

Looking at the screenshot below, is that what you are talking about? Notice that the command buttons on top half have a small border that isn't painted to the form's backcolor. While the bottom half resolves that pretty well. If so, it may require subclassing the form or whatever container your buttons are in/on.

Themed controls appear to send a WM_PRINTCLIENT message to the control's parent before repainting the control. From what I can gather, VB either doesn't respond to that message or doesn't do it as expected when themed.

To get around that, you'll need to subclass for that message, then tell VB to paint the area using a WM_PAINT message

A simple example is located here. That example focuses on a frame, but same logic (and nearly same code) can be used for a form.

Question. What version of Windows are you using. Have read that Win7 and above may have fixed other drawing issues related to themed controls. Don't know if this was 'fixed' or not also.

Thanks La Volpe for this, (and for the past, been looking regularly at your stuff on Planet Code), this seems to be just what I am looking for.

I have just set about solving the issue today as a matter of fact, did not try win 7 on 8, but it is not fixed on Win 10.

I'll see your example code and report.

> I tried hardsetting the backcolor before compile, but no avail.
Strange because I find that setting the button's Backcolor to that of its container works just fine on XP thru 8.1.

When i set up to use themed buttons a while back, and I made tests with various manifest files and use either InitCommonControls or InitCommonControlsEX, there was conflicting literature/examples, and the results varied as what worked consistently and what did not, but after a while, I found out of my own what did work and what did not. There are bad code examples running around.

With your example code, I thought it would be a cinch, but it did not work first time and I had the re-examine the full thing, especially the manifest file, which actually was kind of blank as to the proper fields are concerned. Only the presence of the manifest file was required for the theme buttons to work. So I had a little bit of trouble, and on the very last try, after which I would have to come back and ask for more advice, it worked.

Rock solid, tested on Vista, Win 8 and Win 10.

Thanks, LaVolpe.


Attachment 119477

Quote:

---

Originally Posted by Magic Ink

> I tried hardsetting the backcolor before compile, but no avail.
Strange because I find that setting the button's Backcolor to that of its container works just fine on XP thru 8.1.

---

Actually, I made a mistake. I thought the possible solution was to set the backcolor of either the parent or the container, and the OS would know what to do and that's what I did. The reason I did not try to set the button backcolor (althought I should have) is that in the past, I tried that and it did nothing on non-graphical buttons.

But now that you say.. I will try that for sure...

My
>Strange because I find that setting the button's Backcolor to that of its container works just fine on XP thru 8.1.
Needs a little qualification because on Frames in XP the button needs to be inside a picture box to avoid the 'square black border' syndrome.
Graphical buttons will not theme.

Ok... back to report.....

Setting the backcolor, either at design or at run-time does work....

Problem is my application (actually just one of them) has dozens of forms and buttons by the hundreds... but I found out some other things too....

With the call back method you need to set only one call per container and that takes care of all the buttons in that container. As it happens, most of my buttons are in containers and I have to set the backcolor for those at run-time anyway. Less maintenance is needed this way.

Also... the IDE does not like you setting the callback function for the main form at least... but containers, it does not seem to mind too much apparently. I have not had a crash of the IDE setting callbacks for a few containers. I have not covered all the application just yet but I am fairly confident that there will be no problem doing so. Another plus is that you don't have to use a conditional compilation directive for the IDE, so that's less code to maintain here as well.

At any rate, the setting of the backcolor of command buttons is less work than I wrote about earlier, as I already have a routine that does that for all checkboxes in a form in one call :

setCheckBoxesBackColor Me, ccolor

Allright, thanks the both of you...

I now have two solid options to make my apps looking spiffier than ever before without any blind spots, and that pretty much covers all the esthetics concerns I had.

Can move on to something else ;

Being able to set the backcolor of a themed command button can of course be regarded as a feature (although it will only affect the button's 'border' color). So if you have a button which does something 'serious' you may choose to give it a red border.

LaVolpe... because you asked, FYI, I reverted the program to the state it was before posting question, plugged in my Win 7 system.

No, Win 7 does not do better on themed command buttons. It`s either the subclassing method, or the individual command button backcolor.


Thanks again.

Quote:

---

Originally Posted by Navion

When i set up to use themed buttons a while back, and I made tests with various manifest files and use either InitCommonControls or InitCommonControlsEX, there was conflicting literature/examples, and the results varied as what worked consistently and what did not, but after a while, I found out of my own what did work and what did not. There are bad code examples running around.

---

Indeed, there are.

Actually you don't need to explicitly call either of those entrypoints, all that matters seems to be to get comctl32.dll loaded before letting VB6 create any UI elements. Ideally you also want to load shell32.dll prior to that or you risk additional potential for crashes because of interdependencies.

A dummy call to InitCommonControls in Sub Main does little besides force the loading of comctl32.dll. You could call anything else just as well, e.g. GetMUILanguage.

Once you get past that all VB6 forms and controls take care of calling common controls init routines themselves as required.