When opened from a system modal application, NewView opens in background

[Lewis Rosenthal]

When an application is launched as system modal and help is requested, if NewView is configured as the default help viewer, it is opened behind the modal application. It cannot be brought to the foreground, and the only way to share the screen between the main program window and NewView is to resize them to fit tiled on screen.

In contrast, the IBM help viewer, when launched from the same modal application (assuming that is the default help viewer) properly opens in front of the system modal application, and the user may switch between the main program and the help at will.

[Lewis Rosenthal]

To illustrate the issue, start ArcaOS' MiniLVM with the /modal command line switch.

[ataylor]

FTR, this issue very probably lies in the replacement HELPMGR.DLL, not in the NewView application per se.

[ataylor]

Actually, it probably has to be addressed in both places.

Aaron's development notes include this:

In original helpmgr, the help window is set to be owned by EITHER
a) the active top-level window when help requested (by whatever means)
OR, if set:
b) the "relative window" set by a HM_SET_ACTIVE_WINDOW message.

In NewView I've currently disabled the ownership; because it's usually
more annoying than helpful.

and the HELPMGR code (viewer.c) has this note on launching NewView:

  // set up viewer parameters:
  // <helpfilename> /hm:<helpwindow>
  // currently not used: /owner:<ownerwindow>

At a guess, I'd suspect what needs to happen is:

1. HELPMGR should be updated to pass the owner window to NewView
2. Either HELPMGR or NewView should determine whether the owner is system-modal.
3. If NewView is passed an owner, and it's system modal, NewView should be forced to the top of window z-order (either by setting SYSMODAL or possibly by using WS_TOPMOST if that is sufficient). I'm not sure if this logic needs to be in NewView or HELPMGR; quite possibly either place would work.

[Lewis Rosenthal]

Another place where similar behavior may be observed is within NewView itself. For example, start NewView wihtout passing it a file spec (thus, its own help file is displayed), and access Tools | Search all Help Files... In the dialog which is presented in front of the main program window, select Help.

Result: The focus changes to the main program window behind the Search all files dialog, but the Search all files dialog is left blocking the view. However, in this case, the dialog may be moved out of the way, and the main application is fully responsive (the dialog does not block).

Separate ticket/issue?

[ataylor]

I had a eureka moment and realized it didn't need to be that complicated.

All NewView needs to do is check on launch whether _any_ system modal window exists. There can only be one system modal window at a time, after all.

Now, if there's a system modal window at the moment the NewView window opens, NewView remembers that window's handle, then sets itself system modal. On exit, it sets the original window back to system modal.

Implemented in build 2.19.8b (attached to ticket #49).

[ataylor]

Replying to Lewis Rosenthal:

Another place where similar behavior may be observed is within NewView itself. For example, start NewView wihtout passing it a file spec (thus, its own help file is displayed), and access Tools | Search all Help Files... In the dialog which is presented in front of the main program window, select Help.

Result: The focus changes to the main program window behind the Search all files dialog, but the Search all files dialog is left blocking the view. However, in this case, the dialog may be moved out of the way, and the main application is fully responsive (the dialog does not block).

Separate ticket/issue?

Totally unrelated issue. This is normal non-modal dialog behaviour, and IMO it's the correct behaviour in this case. (It's the same a Find/Replace dialog works in most text editors, for example.)

Basically, WAD.

[Lewis Rosenthal]

I need a little more time to set up a custom ArcaOS ISO with NewView for the installer vs View. I thought I could shortcut the process, but the build system isn't cooperating. Expect a definitive response from me tomorrow at some point.

[ataylor]

You can test using the 5.1.99 version of MiniLVM (or later) by running "minilvm /modal" and then opening help from there. (Note that this will not work with earlier versions of MiniLVM.)

In any event, there seems to be a problem opening secondary dialogs when NewView is running system modal. It seems Sibyl itself just isn't designed for this. I'm likely going to have to add special processing to all of NewView's secondary dialogs (although I may just disable some of them, like printing, which are unlikely to be useful in this mode).

[ataylor]

Update system modal fix (plus fixes for #49 and #63)

[ataylor]

Try the attached (dubbed build 2.19.8d). I've tried adding my system-modal interception logic into the TForm class itself. Quick testing here looks promising.

[ataylor]

It seems this approach, too, has limitations. Specifically, opening a dialog from within a dialog (such as a font setting under Options) still causes problems.

I'm thinking at this point the best approach is to simply turn off system modality entirely while NewView is open, and restore it on close if appropriate.

[Lewis Rosenthal]

I am not seeing any issues with 2.19.8e when opening a secondary dialog from within the application when NewView is started from minilvm /modal (MiniLVM 2.54). Specifically, if I launch help from MiniLVM and then access Tools | Options | Fonts and then click Select... for Normal font, I get a font selection dialog which itself is modal (as expected).

The true test for me will be to swap NewView into the ArcaOS installation environment, as that is what actually prompted this ticket. So far, however, the latest build seems to have addressed the issue quite admirably.