Modality is completely broken for all native Dialogs on vista 5840. but works fine on vista 5734. Actually parent should be blocked by the child dialog (parent should be inactive), but here child goes behind the parent & allows the user to interact with some components on the parent such as scrolling a text area, selecting an item from the list and clicking on the menuitems (when dialog is active). Even windowEvents are also triggered.

This behavior is seen with the following dialogs - 
1. FileDialog
2. Native PrintDialog
3. Native PageDialog

Step to reproduce:
------------------
1) Run the attached programe.
2) Type some characters into the textarea, so that you can see both the scrollbars.
3) Select "Open FileDialog" button, you can see a file dialog is open. Click on the parent(Frame) . Observe that filedialog goes behind parent.  
4) click on the textarea scrollbar so that you can see the charactes on the textarea scrolling.
5) Click on the "File" Menu. you can see some of the MenuItems & allow us to select some of the menuitem.
6) Click on "Open Dialog", you can see a dialog, 
7) Click on the parent, Observe that parent (frame) is inactive.

I tested this on Mustang b103. This behavior is not reproducible with WinXP with the latest mustang build. Also not reproducible with dialogs created through 'java.awt.Dialog' constructors. This behavior is seen with APPLICATION as well as TOOLKIT MODALITY.
Posted Date : 2006-11-01 13:57:57.0

N/A

The bug is not reproducible with 5840 build on our Vista Enterprise desktop. However, the problem originally appeared on Vista Ultimate, so I have tried it too and caught the bug.

After some investigation I have found that the following line in WFileDialogPeer is wrong (marked with *):

    void setHWnd(long hwnd) {
        this.hwnd = hwnd;
*       if (hwnd > 0) {
            for (WWindowPeer window : blockedWindows) {
                window.modalDisableByHWnd(hwnd);

On the Vista Ultimate all the window handles (HWNDs) are negative, so the condition 'hwnd > 0' is always wrong and no Java windows that should be blocked are really blocked. I'm not sure if negative values for HWND are valid, but anyway this check should be corrected to 'hwnd != 0'.
Posted Date : 2006-11-01 18:05:24.0

As I know, on Win95 all the window handles were negative too, if casted to integer/long, so this bug is not Vista-specific.
Posted Date : 2006-11-08 09:13:32.0