The reason to call IsUserAnAdmin and InitCommonControls before any VB6 Forms or controls load is to ensure that the proper versions of the two libraries containing these entrypoints get loaded into the process before the VB6 runtime can screw things up.

You could just as easily do a LoadLibrary on both shell32 and comctl32 instead, but by rights you should hang onto the handles returned and call FreeLibrary on them before your program exits.

Both calls are no-ops as far as our programs are concerned. They are just easy tricks to cause the two libraries to be loaded and freed without a lot of fiddling.

People who call InitCommonControlsEx are just cargo-culting. There is nothing to be gained here if you are using normal VB6 intrinsic controls and OCX controls, since they'll take care of any InitCommonControlsEx calls required by themselves. Sure, you can do it instead of calling InitCommonControls by why jump through the extra hoops? Doing both is just silly.

Either way you go, these calls are best done in a Sub Main and not deferred until a Form_Initialize event even though you might get away with that most of the time... Right up until it doesn't and then you have a lot of head-scratching to do. Just do it right, do it first thing in Sub Main.


The UxTheme varies from version to version of Windows but in many places it does take priority over the old-style color attributes of controls. This is intentional. The whole idea of the theming is to give applications a consistent look.


As far as your "black frame around buttons in a Frame" goes, it is probably an artifact of rendering Win32-based controls like a Command button within the Frame, which is a lightweight ActiveX container control. OLE2 and Win32 GDI sort of "battle it out" over rendering in that scenario. It might look better on a later OS where the Win32 control has changed a bit, but probably not due to any concessions made for the VB6 Frame. It is probably more luck than anything else.