Author Topic: Classic vs. Modern Control Styles  (Read 12420 times)

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: Classic vs. Modern Control Styles
« Reply #15 on: July 01, 2012, 09:44:22 PM »
i think you could classify it as a bug in the XP OS
i tried the following mod to Hutch's code...
Code: [Select]
    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

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6659
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Classic vs. Modern Control Styles
« Reply #16 on: July 01, 2012, 10:08:55 PM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

MichaelW

  • Global Moderator
  • Member
  • *****
  • Posts: 1209
Re: Classic vs. Modern Control Styles
« Reply #17 on: July 01, 2012, 10:21:10 PM »
It might also have something to do with the version of XP. Mine is Version 2002.
Well Microsoft, here’s another nice mess you’ve gotten us into.

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: Classic vs. Modern Control Styles
« Reply #18 on: July 01, 2012, 11:00:15 PM »
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

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6659
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Classic vs. Modern Control Styles
« Reply #19 on: July 01, 2012, 11:20:22 PM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: Classic vs. Modern Control Styles
« Reply #20 on: July 02, 2012, 02:30:33 AM »
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

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: Classic vs. Modern Control Styles
« Reply #21 on: July 02, 2012, 03:44:57 AM »
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
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

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