Can't modify bogus window style

[Pete Gontier]

I'm trying and failing to modify a dialog resource in a project I did not
create. Here is the declaration:

IDD_MAFW_DIALOG DIALOGEX 0, 0, 264, 194
STYLE DS_SETFONT | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU |
WS_THICKFRAME
EXSTYLE WS_EX_ACCEPTFILES
CAPTION "Dialog"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
END

Looks pretty vanilla, huh? However, when this resource is compiled into the
executable file, the style field ends up with the value 0xFFFF0001, which is
blatantly wrong. I discovered this upon inspecting this resource in memory,
but it's wrong in the binary file as well.

Attempts to edit this resource with Visual Studio (2005) seem to have no
effect. I can set or clear any bit and still end up with 0xFFFF0001. It's as
if somebody is post-processing all my dialog resources and slamming them
with the bogus value (and of course I checked for that).

Any clues?


Pete Gontier
http://www.m-audio.com/
pete (at) m-audio (dot) com

[Pete Gontier]

This issue continues to vex me. Testing the dialog within Visual Studio
produces exactly the behavior changes I would expect from editing the
dialog's properties, but all changes get overridden somehow during the build
process, when the style goes to 0xFFFF0001 no matter what I do.

On 8/9/07 4:34 PM, in article

Post by Pete Gontier
I'm trying and failing to modify a dialog resource in a project I did not
IDD_MAFW_DIALOG DIALOGEX 0, 0, 264, 194
STYLE DS_SETFONT | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU |
WS_THICKFRAME
EXSTYLE WS_EX_ACCEPTFILES
CAPTION "Dialog"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
END
Looks pretty vanilla, huh? However, when this resource is compiled into the
executable file, the style field ends up with the value 0xFFFF0001, which is
blatantly wrong. I discovered this upon inspecting this resource in memory,
but it's wrong in the binary file as well.
Attempts to edit this resource with Visual Studio (2005) seem to have no
effect. I can set or clear any bit and still end up with 0xFFFF0001. It's as
if somebody is post-processing all my dialog resources and slamming them
with the bogus value (and of course I checked for that).
Any clues?

[Pete Gontier]

Here's the resolution, for those thousands of you on the edges of your
seats:

Instead of being properly architected in a straightforward way, MFC is using
a system-level training automation hook to provide an opportunity for
applications to modify windows after they are created but before they appear
on the screen. MFC clients are blissfully unaware of the details, which is
as it should be, but it makes debugging much more difficult. Anyway, our app
was using this mechanism to second-guess the window style loaded from the
resource. We couldn't find any legitimate purpose for this, so we got rid of
it, and suddenly my changes to the dialog resource were honored.

Making it even more difficult to understand what was going was another MFC
weirdness. When it loads dialog resources, MFC declares them to have an
obsolete type, and later, in another function, decides whether the data is
actually modern. The obsolete type thinks the style bits occur at offset 0,
but in fact the first 16 bits of modern data are always 0xFFFF because this
signifies that the type is modern and the style bits actually occur at
offset 14. I was looking at the data through the lens of the obsolete type,
trusting the MFC sources, and thinking the tools were ignoring my attempts
to modify the window style. Of course, an MFC engineer could argue the
problem was in my head because I was insufficiently familiar with the
history of dialog resource formats. Whatever.

I continue to unrepentant about not adopting MFC, but part of this problem
was also our own fault.


On 8/13/07 12:24 PM, in article

Post by Pete Gontier
This issue continues to vex me. Testing the dialog within Visual Studio
produces exactly the behavior changes I would expect from editing the
dialog's properties, but all changes get overridden somehow during the build
process, when the style goes to 0xFFFF0001 no matter what I do.
On 8/9/07 4:34 PM, in article

Post by Pete Gontier
I'm trying and failing to modify a dialog resource in a project I did not
IDD_MAFW_DIALOG DIALOGEX 0, 0, 264, 194
STYLE DS_SETFONT | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU |
WS_THICKFRAME
EXSTYLE WS_EX_ACCEPTFILES
CAPTION "Dialog"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
END
Looks pretty vanilla, huh? However, when this resource is compiled into the
executable file, the style field ends up with the value 0xFFFF0001, which is
blatantly wrong. I discovered this upon inspecting this resource in memory,
but it's wrong in the binary file as well.
Attempts to edit this resource with Visual Studio (2005) seem to have no
effect. I can set or clear any bit and still end up with 0xFFFF0001. It's as
if somebody is post-processing all my dialog resources and slamming them
with the bogus value (and of course I checked for that).
Any clues?

Pete Gontier
http://www.m-audio.com/
pete (at) m-audio (dot) com