75609 - Cannot use Windows MSAA support with WINVER=0x0400

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Aaron Leventhal]

The current build system uses a default WINVER of 0x0400.
This gives us the lowest common denominator of Windows support.
However it does not define some things we need to support MSAA (Microsoft 
Active Accessibility), such as OBJID_WINDOW and WM_GETOBJECT.

Is there any reason we can't use WINVER=0x0500 as the default now?

I notice that in some modules, people are forcing WINVER = 0x0500 temporarily 
before they include certain files.

Comment 1

[Aaron Leventhal]

Attachment: Workaround, we just need to define the right things and include winable.h

Comment 2

[Aaron Leventhal]

Leaf, I have a workaround.

I don't know if you still want to try and fix the WINVER problem for future 
work.

Comment 3

[Aaron Leventhal]

Leaf, can you try building on NT with my patch and WINVER=0x0400? If you can 
test it and see that it still builds a working program, and r= this, that would 
be great.

Aaron

Comment 4

[Aaron Leventhal]

Attachment: Got rid of a few more ifdef's after speaking with evaughan

Comment 5

[Aaron Leventhal]

Attachment: Better patch based on most recent source

Comment 6

[timeless]

\ No newline at end of file

is there a reason to keep this one:
 // accessibility only on Windows2000 and Windows98
but not most of them: ?
-        // accessibility only on Windows2000 and Windows98

Comment 7

[John Gaunt (redfive)]

I applied the patch and compiled on NT4 sp6. It compiles just fine, but I don't 
see a change with what I can find using the Inspect Objects tool from MSAA. I 
can't step to individual elements inside the webpage, just the outermost 
window/frame the min/max/close buttons and then it jumps to the console window 
that launched the broswer. 

Comment 8

[Aaron Leventhal]

Interesting, well at least it compiles on all platforms now.
Did you rebuild everything or just the accessible, layout and widget 
directories? Also, sometimes you need to do:
nmake /f makefile.win depend
before
nmake /f makefile.win
Don't be deeper than a top level directory of mozilla, otherwise it won't use 
the "build" directory and link the .dll's.

Comment 9

[Aaron Leventhal]

Oh, one more thing - are you testing it with mfcembed or with Mozilla/NS6? It 
won't work with a XUL-based browser at all. You have to test with mfcembed.

Comment 10

[John Gaunt (redfive)]

I initially just applied the patch and rebuilt ( nmake -f client.mak build_all )
from the mozilla directory assuming the makefile system would pick up the file
modifications ( which in retrospect I think it did ). Then I tested using
mozilla. Not seeing the results I was hoping for, I clobbered ( nmake -f
client.mak clobber_all ) and rebuilt the entire tree from mozilla ( nmake -f
client.mak build_all ). Re-tested using mozilla and saw the same thing.

I don't see a mfcembed binary in the dist\W*\bin directory. How do a test using
that?

Comment 11

[timeless]

you should have --enable-tests (or not have --disable-tests) and you should not 
have NO_MFC.  

try
cd mozlla\embedding\tests\mfcembed
nmake /f makefile.win install
[i don't have mfc installed, so i haven't played w/ this]

Comment 12

[John Gaunt (redfive)]

Thanks for the pointer timeless.

Woo-hoo, it works!! :-) I can use the object inspector and looks like I can
navigate to all the GUI elements. not much within the HTML page though, buttons
and textfields show up, but not hyertext links or plain text.

Comment 13

[Peter Trudelle]

P1/moz0.9.1, need ETA date.

Comment 14

[Aaron Leventhal]

This is part of our accessible branch tbat is getting reviewed.
It's already done. Will mark fixed once it checked into the tip.

Comment 15

[Aaron Leventhal]

checked in

Comment 16

[Jon Granrose]

verified.