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

[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.