8
votes

I have a Delphi 2006 app which can pop up a modal dialog in response to an error condition. It seems to get itself into a state where one of these modal dialogs is open, positioned in front of the main form, but neither form is responding to messages. Clicking on either gives a "bonk". The app is running fine, the UI is updating the main form, but you can't do anything. I guess there is most likely another modal dialog under the main form. Whether it is one of mine or one from Windows I have no idea.

Other points:

  • the app responds to keyboard shortcuts OK. One of these shortuts shuts down the app gracefully and this worked. I have been unable to reproduce the situation since.
  • the app has a tray icon. This responds to right mouse clicks. If I minimize the app from here the main form minimizes and leaves the modal dialog displayed, still without focus. If I restore the main form, things are as they were, with neither window having focus. Alt-tab has similar results.
  • platform is Windows 7
  • I call DisableProcessWindowsGhosting before any forms are created
  • I open the modal dialogs with

    ModalDialog.PopupParent := MainForm ;
    ModalDialog.ShowModal ;
    
  • I postpone these error dialogs if other modal dialogs are open:

    if (Application.ModalLevel = 0) then
        {open modal dialog}
    

My question has two parts:

Is there a way of programmatically finding out what window has focus? I could then take some action for this scenario or a last resort I could them provide a shortcut key to bring it to the front or take some evasive action (depending on the dialog) like set the ModalResult to mrCancel.

How can this situation arise? Normally when I get a modal dialog behind the main form (I can do that by getting the modal dialog to open, minimizing the app from the tray icon, then restoring the app again - the app main form restores in front of the dialog, with the dialog still retaining focus), I can bring it to the front again by clicking on the tray icon, or close it with the Esc key but it didn't work in this case.

**UPDATE**

Misha's fix worked apart from non-delphi dialogs like TSaveDialog. I was able to get them to work as well by adding Application.ModalPopupMode := pmAuto ; just before the call to Execute.

By "got it to work" I mean that the save dialog was in front after the following sequence:

  • open save dialog
  • minimize app from tray icon
  • restore app from tray icon

whereas it was behind the main form without the ModalPopupMode := pmAuto.

So I'm hoping these changes will help the (as yet unreproduced) problem.

4
Finding out which window has focus and taking remedial action is not going to help. You need to deal with the problem at source. And that means understanding the window ownership (i.e. PopupParent).David Heffernan
Thanks @David. Finding out what window has focus is certainly going to help as it will possibly show me how I can reproduce the problem, which I can't do currently.rossmcm
Once you have it manifesting you should be able to use something like Spy++ to understand the ownership relationships. I'd try to debug this from the outside, at least until you have a repro.David Heffernan
You can often make it reproduce by adding {$ifdef DEBUG}Sleep(5000);{endif} to your debug build - a little experimentation is required to find the place where it would be most "devastating". The magic trigger for this z-order hell is windows thinking your application is not responding.Warren P

4 Answers

4
votes

The last active popup window (VCL or not) can be queried with GetLastActivePopup:

function GetTopWindow: HWND;
begin
  Result := GetLastActivePopup(Application.Handle);
  if (Result = 0) or (Result = Application.Handle) or
      not IsWindowVisible(Result) then
    Result := Screen.ActiveCustomForm.Handle;
end;

This is somewhat copied from TApplication.BringToFront.

Bringing this window to the front can be done by SetForegroundWindow:

SetForegroundWindow(GetTopWindow);

Note that Application.BringToFront might do the trick altogether, but I once experienced it did not function properly, a situation I have not been able to reproduce since though.

5
votes

If a form that has focus takes too long to respond to messages (Form1), so that Windows thinks Form1 is unresponsive, and Form1 then displays a modal form (Form2), after Form2 is displayed and the application is processing messages again, Form1 will be brought to the front, thereby potentially "covering" Form2.

Putting this in the Application.OnIdle event will do the trick:

  if Assigned(Screen.ActiveForm) then
  begin
    if (fsModal in Screen.ActiveForm.FormState) and
       (Application.DialogHandle <= 0)) then 
    begin
      Screen.ActiveForm.BringToFront;
    end;
  end;
0
votes

GetForegroundWindow() is the function you are looking for, if you know the title or have the handle of the modal window it's straightforward.

HWND GetForegroundWindow();

Retrieves a handle to the foreground window (the window with which the user is currently working). The system assigns a slightly higher priority to the thread that creates the foreground window than it does to other threads.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms633505%28v=vs.85%29.aspx

0
votes

I used Misha’s solution and worked a little further (using NGLN’s code), to solve the problems rossmcm has seen (handlings non VCL dialogs).

The following code is running I a timer:

type
  TCustomFormAccess = class(TCustomForm);


if Assigned(Screen.ActiveCustomForm) then
begin
  if ((fsModal in Screen.ActiveCustomForm.FormState) and
      (Application.DialogHandle <= 0)) then
  begin
    TopWindow := GetLastActivePopup(Application.Handle);
    TopWindowForm := nil;
    for i := 0 to Screen.CustomFormCount - 1 do
    begin
      CustomFormAccess := TCustomFormAccess(Screen.CustomForms[i]);
      if CustomFormAccess.WindowHandle = TopWindow then TopWindowForm := CustomFormAccess;
    end;
    if Assigned(TopWindowForm) and (Screen.ActiveCustomForm.Handle <> TopWindow) then
    begin
      Screen.ActiveCustomForm.BringToFront;
    end;
  end;
end;