Is anyone able to tell me what the basic difference is between programs which have classic-looking controls and programs which have modern looking control styles?
I thought it might have been the use of a manifest file as I'd found these supplied with applications using modern controls, but then I found an almost identical manifest file with a program using classic controls... so no help there.
(http://i46.tinypic.com/5oxcf8.png)
the manifest file is only part of the equation
to get the "UxTheme" style controls, it is probably also necessary to call InitCommonControlsEx
InitCommon controls may work, rather than InitCommonControlsEx
- and - there was some discussion that the function need not be called, only referenced
for example, you might be able to place the function name in the data area
dd InitCommonControlsEx
this may also work
i prefer to call it :P
the UxTheme looks nicer, but comes at a cost
for some controls, it can be more difficult to subclass the control to get certain features
for example, it is hard to change the background color of a button without owner-drawing it
Under Windows XP I have not been able to get that exact behavior. With InitCommonControls or InitCommonControlsEx I get the newer button style, but without either of them the call to CreateWindowEx fails with a "Class does not exist" error.
Quotethe manifest file is only part of the equation
That's wild! Thank you very much dedndave, that explains everything.
Is there also some kind of way to achieve the same effect without using manifest or resource files?
I realise that large projects are more difficult to maintain without these files.
Quotethere was some discussion that the function need not be called, only referenced
for example, you might be able to place the function name in the data area
That's bizarre, I guess it's something to do with the way windows checks for the initialisation call.
Quotethe UxTheme looks nicer, but comes at a cost
for some controls, it can be more difficult to subclass the control to get certain features
for example, it is hard to change the background color of a button without owner-drawing it
Right, I won't run into that issue any time soon, but thanks for the warning!
Thank you very much for all of your assistance!
The bare minimum msgbox code that I was mucking around with is attached if it's of any interest to anyone.
Quote from: MichaelW on June 30, 2012, 08:37:05 PM
Under Windows XP I have not been able to get that exact behavior. With InitCommonControls or InitCommonControlsEx I get the newer button style, but without either of them the call to CreateWindowEx fails with a "Class does not exist" error.
That's weird, I'll have to cross that bridge at some stage, thanks for the heads up MichaelW
Quote from: dedndave on June 30, 2012, 08:01:39 PMthe manifest file is only part of the equation
I just deleted the line
invoke InitCommonControls and references to comctl32.inc & comctl32.lib and it still produces a UxTheme'd message box.
So it seems to only require a manifest file included as a resource.
you will find that the behaviour is very OS-dependant
i guess you are using windows 7
i use a version of XP
if the manifest file appears without the InitCommonControls, the program will not run at all :P
best thing you can do is to have someone test it under all OS's you intend to support :t
Its this simple with the SP3 XP I use, I can take an old program, Win2000 era, make an external manifest file for it and it displays the later controls. There is in fact good reason to include a manifest file as it does not matter on Win2000 but works on later versions to modernise the interface. Many more cynical than I would suggest that Microsoft used this technique to render older programs obsolete in terms of appearance but in most instances you can just add an external manifest.
I have not checked this in a while.
When Win95 came out, you could switch between 3.1 style and Win95 style by setting the linker subsystem to 3.1 or 4.0.
Thank you dedndave & hutch!
I do use Windows 7, although I just set up XP Mode (which is distributed with SP3 installed) to test this and now I see that you guys have already explained exactly what I found:
| InitCommonControls call & manifest file | msgbox displayed with uxtheme |
| InitCommonControls call only | msgbox displayed without uxtheme |
| manifest file only | msgbox does not display at all |
| neither InitCommonControls call nor manifest file | msgbox displays without uxtheme |
Enabling Visual Styles: http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175%28v=vs.85%29.aspx)
Application Manifests: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374191%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa374191%28v=vs.85%29.aspx)
i did a little more reading...
i learned something that i wondered about, before
that is - how do these UxTheme-enabled programs work under win 2000 ???
thing is - under win 2000, manifests are not supported
so - the OS does not recognize that there is a dependancy - and the EXE runs without it
Here is a message box with a manifest, works on my XP and Win7 64 bit displaying the later interface.
no window, here
i suspect it is as Michael says - Class Does Not Exist
i add the following
.data
dd InitCommonControls
and it works with XP theme
Quote from: hutch-- on July 01, 2012, 03:30:40 PM
Here is a message box with a manifest, works on my XP and Win7 64 bit displaying the later interface.
we cannot see any message box it closes
It works if we add what Dave post
.data
dd InitCommonControls
This has not worked the way I expected under XP. In my button in an app window example, if I include the manifest then I must do the InitCommonControls bit, or I get no button. If I forgo the manifest and the InitCommonControls then I get an old-style button. And the same for the msgbox example, except instead of no button I get no MessageBox dialog. It looks like if you include the manifest, then the old-style classes don't get registered. I guess Microsoft is done with them.
Come to think of it, with Windows 8 they appear to be done with a bunch of things that I've never even looked at :biggrin:
i think you could classify it as a bug in the XP OS
i tried the following mod to Hutch's code...
include \masm32\include\masm32rt.inc
.data
szComCtl32 db 'ComCtl32.dll',0
.code
start:
INVOKE LoadLibrary,offset szComCtl32
push eax
fn MessageBox,0,"I am a Messaage Box ","Howdy",MB_OK
CALL FreeLibrary
exit
end start
and it works
so - i would say the OS fails to load comctl32.dll, when it ought to do so automatically
t would seem that the variable is both the language version of Windows and the OS version of Windows. My XP SP3 is a US English version, my Win7 64 bit is an Ultimate US English version and it works on both of these. I think from memory that Dave is running an OEM version of XP and I suspect the Rui is running a non-English language version of Windows.
Now I remember a similar problem that Erol pointed out by code that used InitCommonControlsEx() that failed with his language version of Windows so it would appear that to be safe, even if you are not using any of the "common" controls that you use at least InitCommonControls() or the extended version if you need to specify the control type in conjunction with a manifest file.
It might also have something to do with the version of XP. Mine is Version 2002.
yah - mine is OEM MCE2005
don't expect MS to fix it any time, soon - lol
XP is beyond it's support life - and this isn't a critical or security issue
Its probably the case that mine has the bulk of the later upgrades as it is an install that is XP Sp3. Slow pain in the ass installation, its even slower than Win2000.
when i built this one, i must have put about 300 MS updates on it - lol
i think it is as you mentioned earlier - it is just a version thing
and i don't think MS ever got around to writing a hot-fix for it - but - i will look for one
after reading a bunch of complaints about how comctls v6 and manifests weren't working - lol
(must have been a million hits on that)
i came across some material on Geoff Chappell's site
he has a fairly comprehensive reference...
http://www.geoffchappell.com/studies/windows/shell/comctl32/index.htm?tx=10-12,14 (http://www.geoffchappell.com/studies/windows/shell/comctl32/index.htm?tx=10-12,14)
which includes details of the different versions
of particular interest was the section on InitCommonControlsEx...
http://www.geoffchappell.com/studies/windows/shell/comctl32/api/commctrl/initcommoncontrolsex.htm?tx=10-12;2 (http://www.geoffchappell.com/studies/windows/shell/comctl32/api/commctrl/initcommoncontrolsex.htm?tx=10-12;2)
when i read that page, i noticed that he made some comments about InitCommonControls
that i believe apply to MS C compilers - and do not apply to assembly language programming
because it involves the start-up code that is executed in compiled code
at any rate....
it dawned on me that this may not necessarily be an OS version thing, after all
it could be that the WinSxs registration entries are a bit out of whack
thus causing different behaviour on different machines
so - i want to do a little research and see if i can verify that my machine has the assemblies properly registered
this may not be so easy, as it seems to fall in the "undocumented" zone of MS