The tratment of modality and transient-for relationships is well known to be buggy in gdk/win32. There are lots of bugs already open for this. This bug could probably be resolved as a duplicate of one of them. I'm too lazy right now to look for the right one, though.

You shouldn't have describe two different problems in one bug report, though. I'm chaning the Summary to refer to only the first problem, with gtk_message_dialog_new(). Feel free to open a separate bug report for the other problem.

(In reply to comment #1)

On the 2nd problem:
> Also, I have two dialogs opened with gtk_dialog_new_with_buttons. One uses
> "GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT" and the other just
> "GTK_DIALOG_DESTROY_WITH_PARENT", yet both of these appear to behave as modal
> dialogs (I cannot bring the main window to the front when either is open).

> Steps to reproduce:
> 3. Open a dialog using gtk_dialog_new_with_buttons with
> GTK_DIALOG_DESTROY_WITH_PARENT and without GTK_DIALOG_MODAL.
> 4. Try to click on the main app window - nothing happens (the launched dialog
> is behaving modally).

> Actual results:
> The dialog launched by gtk_dialog_new_with_buttons without GTK_DIALOG_MODAL
> does behave modally.

> Expected results:
> When a dialog is launched by gtk_dialog_new_with_buttons without
> GTK_DIALOG_MODAL it should be possible to bring the main app window to the
> front.

I worded that badly. The dialog was created by gtk_dialog_new_with_buttons but was actually launched by gtk_dialog_run(). gtk_dialog_run forces the dialog to be modal, as described in the documentation, so the 2nd reported problem is not a bug anyway.

I want to make sure this comment links to this bug
http://bugzilla.gnome.org/show_bug.cgi?id=371036#c7
because I believe they are related since his "workaround" directly effects this bug as I understand it.

I am unable to reproduce this now.  I believe it may have been fixed by bug #112404.  Can you please confirm?  Otherwise I will close this bug.

And if you believe it is not yet fixed, can you please attach a minimal but complete test program that will exploit the bug?

It looks like bug #112404 is fixed in GTK 2.10.14 which is not yet available in at either of the two main Windows port sites (Tor's and GLADE/GTK+). I will confirm this is fixed when one of those gets up to 2.10.14.

Check http://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.10/ 

The 2.10.14 zipfiles are even linked to from the http://www.gimp.org/~tml/gimp/win32/downloads.html page, although you should always just look on the ftp.gnome.org site to check for fresh binaries from me. I don't necessarily update the www.gimp.org page that often. (And it says so on the page.)

I've now re-built my app with GTK 2.10.14 / GLIB 2.12.13 and I'm afraid that messages displayed via gtk_message_dialog_new specifying GTK_DIALOG_MODAL are still not properly behaving as modal. When one is displayed and I click on the main app window, the latter is brought to the front (but controls on it are unresponsive) and the message window disappears behind it.

I will see if I can knock up a simple program to demonstrate the problem.

I'm looking at gtk-demo.exe to test.  I double-click "Dialog and Message Boxes", click "Message Dialog".  That brings up a modal dialog, and I am unable to move it behind its transient parent, which is the dialog with the title set to "Dialogs".

However, I can bring "GTK+ Code Demos" above the modal window.  And I'm not sure if this is a bug or not, but my guess is that it is not.  I don't think "Dialogs" sets "GTK+ Code Demos" as its transient parent.

If you can still reproduce the problem then if you can create a simple, but complete, test program that I can compile (preferably in C) that would be a big help.  I would really like to get transient and modal windows working well.

This program (based on hello world from the tutorial) demonstrates the problem. I compiled it under cygwin with:

export PKG_CONFIG_PATH="c:/GTK/lib/pkgconfig"
gcc -mwindows -mms-bitfields tst.c `/cygdrive/c/GTK/bin/pkg-config --cflags gtk+-2.0` `/cygdrive/c/GTK/bin/pkg-config --libs gtk+-2.0`

When it runs it has a "Launch message win" button. Click that and a message dialog window is opened. At this point click the main window and the message window disappears behind it so it cannot be seen. Try to click the close x on the main window and nothing happens. You need to drag the main window out of the way to see the message window so that you can close it.

#include <gtk/gtk.h>

GtkWidget *window;
static void launch( GtkWidget *widget, gpointer   data )
{
    GtkWidget   *dlgWin;
    dlgWin = gtk_message_dialog_new(GTK_WINDOW(window),
                                    GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT,
                                    GTK_MESSAGE_INFO, GTK_BUTTONS_OK,
                                    "Testing");
    gtk_dialog_run(GTK_DIALOG(dlgWin));
    gtk_widget_destroy(dlgWin);
}

static gboolean delete_event( GtkWidget *widget,
                              GdkEvent  *event,
                              gpointer   data )
{
    g_print ("delete event occurred\n");
    return TRUE;
}

static void destroy( GtkWidget *widget, gpointer   data )
{
    gtk_main_quit ();
}

int main( int   argc,
          char *argv[] )
{
    GtkWidget *button;
    
    gtk_init (&argc, &argv);
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    g_signal_connect (G_OBJECT (window), "delete_event", G_CALLBACK (delete_event), NULL);
    g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (destroy), NULL);
    gtk_container_set_border_width (GTK_CONTAINER (window), 100);
    button = gtk_button_new_with_label ("Launch message win");
    g_signal_connect (G_OBJECT (button), "clicked", G_CALLBACK (launch), NULL);
    g_signal_connect_swapped (G_OBJECT (button), "clicked",
			      G_CALLBACK (gtk_widget_destroy), G_OBJECT (window));
    gtk_container_add (GTK_CONTAINER (window), button);
    gtk_widget_show (button);
    gtk_widget_show (window);
    gtk_main ();
    
    return 0;
}

In regard to Cody's comment #8, I just tried running gtk-demo.exe and for me it does show the problem. This was the version of the program in gtk+-dev-2.10.14.zip (downloaded from the link in Tor's comment #6). I tried it on two different PCs, one running Vista-64 and one running Windows XP, and saw the same behavior in both cases:

I open the Dialogs window and click the Message Dialog button on it and a message dialog opens. Now I click the Dialogs window and it comes to the front, on top of the message dialog. But if I instead click the Interactive Dialog button on the Dialogs window, then the Dialogs window cannot be brought in front of that one. Again this demonstrates that the problem is only with the message dialog.

To reproduce this from scratch, starting on a Windows XP PC with no GTK installed, I did the following:

1. Ran gtk-dev-2.10.7-win32-1.exe previously downloaded from the GLADE/GTK+ website to install GTK 2.10.7 as C:\GTK.
2. Downloaded the following and unzipped them into C:\GTK to upgrade that to 2.10.14: atk-dev-1.12.3.zip cairo-dev-1.4.8.zip glib-dev-2.12.13.zip gtk+-dev-2.10.14.zip libpng-1.2.8-lib.zip pango-dev-1.16.4.zip.
3. Ran gtk-demo.exe from C:\gtk\bin.

Created attachment 94397 [details]
Screenshot of gtk-demo.exe showing the problem

I've attached a screenshot of gtk-demo.exe showing the Dialogs window brought to the front in front of the message dialog that was launched from it.

Thanks Ian, I'll look into this.  The GTK I have installed on my Windows box is not exactly the same as 2.10.14, because I've been working on another transient-related patch.  Maybe my current patch is what is causing the difference in this behavior.  I'll get back to you.

I think the patch I have posted to bug #164537 might solve this issue.  I'm pretty sure that's the only difference between my Windows box and 2.10.14.  I'll try to get that resolved soon.

2007-10-17  Cody Russell  <cody@jhu.edu>

        * gdk/win32/gdkevents-win32.c
        * gdk/win32/gdkwindow-win32.[ch]: Force non-modal transient dialogs
        to iconify with their parents on Win32.  Maintain a list of transient
        children, and whenever a window is hidden or restored we now do the
        same thing to all connected transient windows above and below the
        current window in the chain.  See comment under WM_ACTIVATE for the
        reasons why.  (#164537, #371036, #405178)

Cody gave me a copy of his patched libgdk-win32-2.0-0.dll with the above fix, and using that with GTK 2.12.1 the message window is now behaving as expected and staying on top. So I can confirm this bug as fixed pending release of a version that includes this change.

I finally got a chance to download the latest GTK Windows build (2.12.3) and can confirm that modal dialogs are now behaving as I would expect. This bug can be closed as fixed.