bug#11732: Follow-up to bug#11732

[martin rudalics <rudalics@gmx.at>]

 > I didn't mean the owing window, I meant the other windows on the
 > desktop, belonging to applications other than Emacs.  Using
 > HWND_TOPMOST makes me unable to raise any window of another
 > application above the dialog box in the z-order.  The existing code
 > does allow that.

Because it leaves the entire z-order handling to Windows.  The idea of
using a dialog box is that you tell Windows to glue together the frame
with the dialog box and let no other window enter the z-order in
between these two.  How Windows implements that has likely never been
analyzed so we won't know.  But I suppose that Windows simply
intercepts all (implicit) z-reorder requests to let no other window
in.

Now if Masayuki's proposal breaks this relationship please tell me
exactly how.  IIUC you mean to say that with focus follows mouse sans
autoraise the two Emacs windows (always) appear on top of other
applications.  But sans autoraise means that the z-order should not
change when you move the mouse so you apparently clicked into another
application's window or tried to Alt-tab to it.  Please clarify this
giving us the precise steps you used.

In either case having Emacs fiddle with the z-order and activation of
dialog box windows is dangerous and should be avoided in the first
place.  Also, the code below is creepy and certainly not what a
well-behaved application is supposed to do:

	      EnableWindow (edit_control, FALSE);
	      /* Note that at least on Windows 7, the above call to EnableWindow
		 disables the window that would ordinarily have focus.	If we
		 do not set focus to some other window here, focus will land in
		 no man's land and the user will be unable to tab through the
		 dialog box (pressing tab will only result in a beep).
		 Avoid that problem by setting focus to the list here.	*/
	      if (hdr_code == CDN_INITDONE)
		SetFocus (list);

 > OK, so the call to w32_dialog_in_progress has nothing to do with the
 > z-order of the dialog wrt its owning frame, right?

Right.  I meanwhile tried to document this better.  Please have a
look.

 >> Note that Emacs waits for the dialog to finish and doesn't redisplay
 >> in this time.  Hence if during a dialog I temporarily show another
 >> window on top of the dialog and remove that other window, the text in
 >> the Emacs frame is usually garbled until the dialog finishes.
 >
 > Yes, I know.  That wasn't what I was worried about.

I know.  My note was just a reminder that moving other windows above
the Emacs frame while a dialog is in progress doesn't result in a
pleasant user experience anyway.

martin