Known bugs in PMView Pro v3.00 - Known bugs that will be fixed soon Options

[Peter]

The following are known errors in the current version, and will be fixed in the upcoming v3.01 release scheduled for 6/16/03:

Both versions:

-Zooming may crash PMView
-Trial version: The evaluation period (time) is migrated from PMView 2000 with the rest of the settings (this was not intended).
-There is no way of knowing if PMView is showing the default or actual resolution of a file in the File Info dialog. v3.01 will add the text "(Default)" after the resolution if the actual resolution is unknown.
-Minimizing the PMView main window causes the scroll bar positions to be reset to their leftmost/uppermost positions when the window is restored.
-The red and blue colors are swapped when displaying JFIF (JPEG) files with RGB color space. (Such files are not common).
-The "ExposureTime" field in the EXIF data is not always displayed as a fraction. How it is displayed depends on how the camera stored the data. v3.01 will always display it as a fraction regardless of how it is stored.

OS/2 only:

-Loading an image when the main window is minimized crashes PMView.
-The info tip help in the File Open window may paint incorrectly when a popup menu is shown.
-The info tip of the File Open window may appear when the cursor is outside the window.
-Performance (speed) problem with conversion and EA Icon thumbnail creation in directories with many files (>1000).
-EA Icon thumbnails cannot be created on drives that do not have write permission enabled.
-Installer does not install an icon on Warp 3
-Installation fails if there is a space in the path name. (The v3.01 installer will have a notice telling not to use spaces in the installation paths. The actual problem will be addressed in a future release when an upgrade to the WarpIn installer is available that lets us solve the problem).

Thanks,



Edited By Peter on 1055546550

[Guest_Barry_*]

Another bug new to this version, PMView 2000 would open a file dialog for the current directory when you load it from the command prompt with "pmview ." but now this feature is gone

[DSperber]

Another bug new to this version, PMView 2000 would open a file dialog for the current directory when you load it from the command prompt with "pmview ." but now this feature is gone

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.

[Peter]

Another bug new to this version, PMView 2000 would open a file dialog for the current directory when you load it from the command prompt with "pmview ." but now this feature is gone

This is a feature change. PMView now loads the file sequencer with the files specified instead of opening up the File Open dialog.

PMView test/*.jpg *.gif loads the file sequencer with all jpg files in the test subdirectory and all gif files in the current directory. (The file sequencer is the unit that holds the file names that should be displayed when you press PgUp/PgDn).

PMView . opens all files in the current directory

Thanks,

[Peter]

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.

Darryl,

How about if I added a command line flag, say "/EXIsting". If a copy of PMView is running, then "pmview /EXI filename.jpg" would load the file into an existing copy of PMView.

Woudn't this do what you're asking for?

(Adding this feature is something I have planned to do for a long time anyway...)

Thanks,

[DSperber]

How about if I added a command line flag, say "/EXIsting". If a copy of PMView is running, then "pmview /EXI filename.jpg" would load the file into an existing copy of PMView.

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.

[Guest_Barry_*]

Another bug new to this version, PMView 2000 would open a file dialog for the current directory when you load it from the command prompt with "pmview ." but now this feature is gone

This is a feature change. PMView now loads the file sequencer with the files specified instead of opening up the File Open dialog.

PMView test/*.jpg *.gif loads the file sequencer with all jpg files in the test subdirectory and all gif files in the current directory. (The file sequencer is the unit that holds the file names that should be displayed when you press PgUp/PgDn).

PMView . opens all files in the current directory

Thanks,

So how do I have pmview pop up a file open dialog when it first loads? ???

[Peter]

So how do I have pmview pop up a file open dialog when it first loads?

We will need to add a command line option (or notebook option) for this.

Thanks,



Edited By Peter on 1055109043

[Peter]

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.

Yes, this is what it would do. The existing instance must also have been started with the /EXI flag. This lets you start other instances without the flag and they can run "safely" without risk of being overtaken by the application(s) that use the /EXI flag. For instance, if you have manually launced a separate copy from the shortcut on the desktop and is editing a file, it is very unlikely that you would want this instance "hijacked" by another app. Don't you agree?

This feature, and the possibility to add a shortcut key for minimize will be in v3.10.

Thanks,



Edited By Peter on 1055108876

[DSperber]

The existing instance must also have been started with the /EXI flag. This feature, and the possibility to add a shortcut key for minimize will be in v3.10.

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.