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]

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.