Having this "dedicated single-instance" for use and re-use by any parent-level launching tasks is the right solution. And it makes perfect sense that all such launches, including the first, would designate /EXI in order to define the intent.

And outside of this, other launches without /EXI would simply continue to create new instances as they do today, safely out of the reach of the being "hijacked" by the /EXI task, as you describe.

Excellent.

I look forward to this feature (and hopefully "minimize") in 3.10.


P.S. - in planning for how I'm going to assign keys after this feature becomes available, I'm contemplating some use of ESC, ENTER, and PAUSE which is intuitively consistent in all situations, not to mention the fact that after years of ESC and ACDSee I'm used to ESC making the image display window disappear and its Browser window re-appear when the Browser is active and that is how the image window was launched. This is conceptually my so-called "Z-return" function, where the display window disappears or at least loses focus (or is minimized) and the parent window (whatever it is, ACDSee Browser or parent launching program such as Agent) regains focus, while somehow retaining "quick re-launch" capability.

I'm trying to get my brain organized as to some intuitive was to assign keys for PMView to accomplish what I want but am stymied a bit because some crucial keys (e.g. ESC) which might have an obvious intuitive usage in one situation will cause confusion and problems for a second situation if that key is assigned the keyboard shortcut appropriate for the first situation. The reason for this "confusion" is that in ACDSee it is the Browser (FOC) window which is the "main task" whereas in PMView it is the display window.

What seems to be needed (at least for "basic" keys like ESC, ENTER, and PAUSE) are perhaps two or three or five alternative available definitions (e.g. ESC-1, ESC-2, ESC-3, etc.) which could then be assigned to the particular situation that wants that particular usage.

It seems all you would you need to do is support multiple such definitions for the same key in the Shortcuts notebook page, and then make use of them correctly in the application.

For example, when the image display window has the focus, ESC-1 might be "operative". But when the FOC window has the focus, ESC-2 might be "operative". Perhaps labeling them ESC-DISPLAY and ESC-FOC might make things easier for the user to grasp the concept.

ESC-1 might be assigned to "File -> Open" while ESC-2 might be assigned to "Exit", as a way of reversing the current PMView notion where it is the display window which is the main task and from which the program normally ends if CTRL+F4 is pressed.

Exactly how I would want to use ESC, ENTER, and PAUSE in all situations still isn't quite definite in my mind yet, but I do feel this general facility to support at least several multiple uses for "basic" keys would be quite useful, even if it's only the two specific uses of ESC that I've described in the above paragraph's example as a minimum.

If that parameter utilizes the existing instance and replaces the existing image currently being displayed with the new file named in the second launch, then it sounds like we've got it licked. Presumably it would also "restore" the display window if it was currently minimized.

I'd still also like a keyboard shortcut available to "minimize" (e.g. I would probably assign ESC), thus returning focus to the Z-parent. This would effectively be the same as leaving behind a "quick launch thread in the Windows System Tray" for an OS/2 environment, in anticipation of the next launch from a parent program (e.g. email client).

However the real purpose of this feature for me is for use when launching PMView from a parent program (e.g. email client), not from the command line. So the launching program would need to be configurable so that this new /EXI operand could be included. Fortunately Agent supports that, so this might just work after all.

Presently, the only opportunity I have to set PMView as the default viewer for a particular file type (extension) is at program installation.

But if I would like to change those defaults later (e.g. to make PMView the default viewer for a type I had previously un-checked because I was using another program at that time but now I've changed my mind) I can't get it done without going through a reinstall of PMView again in order to get that dialog presented.

Can the File Association dialog be added to the Preferences notebook?

I don't know if I'd call this a problem or a blessing.

If the File Open window is opened, then the Explorer View pane also opens and that means all hard drives must be up and spinning. If you've got drives that spin down because of inactivity, they will now all have to spin up to satisfy Explorer even though your command-line launch for one image just wanted to view that one image.

Also, when the File Open window is opened all thumbnails in the current directory will be built. That, too, seems unnecessary and inappropriate when you're just trying to view one single image.

When launching PMView from another app (e.g. from an email program to view an image file attachment), launching just the image seems good. That way you can have a simple keyboard shortcut assigned like ESC to correspond to File -> Exit to exit quickly (back to the launching app), and this whole process is just about as short and efficient as you could think of.

What I've also done is assigned the ENTER key as a keyboard shortcut for File -> Open to enter the File Open window, which is how I will get into the current directory and build all thumbnails for the current directory if that's what I really want to do while viewing the single image launched from my email program (yes, all spun-down drives will now spin up, but that's a one-time delay).

After both the image display window/full-screen and File Open window are available, pressing the ENTER key repeatedly toggles back and forth between the two windows (only because of my keyboard shortcut of ENTER, of course).

This seems to give me the near-best of what I really want when using PMView as the default viewer to be launched from another app.

The real-best implementation would be if there were some way to EXIT-FOR-QUICK-RELAUNCH which would leave a PMView thread still active (e.g. in the Windows System Tray) so that the next command-line launch (from the email app) for another image file wouldn't have to go through all of the same first-time initial overhead of starting a program from scratch, but could really "quickly launch".

I believe this "quick relaunch" idea is a problem in OS/2 for which there is no solution, where I can't seem to make a second commad-line launched instance of a program use the current existing instance even though the Properties of the desktop program object indicate to "use existing instance". Perhaps there's some operand in the START command which will provide this, but otherwise each subsequent launch while a current instance is already active seems destined to create another instance.

But ideally, I'd like the existing instance (even if minimized) to be restored to view with the new image replacing the existing (or last-viewed) image. I do not want a second instance created.

And ideally, I'd like a new keyboard shortcut available to MINIMIZE (i.e. "minimize" from the System menu) which would minimize either just the image window or both the image window and File Open window (if it was open) with a single keystroke. That would be one way to simulate the Windows System Tray in OS/2, prepared for "quick relaunch" if some way could be figured out to avoid always creating a new instance of the program any time it's launched from another app.

Oh well.