Hello Peter,

I noticed a new "feature" in PMView Pro that I do not like.
When deleting files in the file open window, PMView Pro now add their filenames OS2SYS.INI's key PM_Workplace:handles.
The previous versions only did this if you used the file open window to move files by drag and drop to another folder.

Moving thousands of files this way over time once caused my OS2SYS.INI file to become quite large, which cause an noticable increase in hard disk activity and system slowdown when OS/2 wrote OS2SYS.INI to the harddrive.
You should normally have these two keys.
PM_Workplace:handles0
PM_Workplace:handles1
Instead I had 0-11, twelve keys all made of filenames of images moved with PMView's file open window.
Checkini and Multimaint would not automatically shrink them by deleting the old file handles because the files still existed on the hard drive.
I had to manualy delete keys PM_Workplace:handles2-11 using Multimaint in order to shink my OS2SYS.INI file.

So years ago I made a rule never to move images using PMView's File Open Window, and to use FM/2 file manager instead, in order to keep my ini files small.
Deleting files used to be ok.
But now deleting files using PMView Pro's file open window causes the filename to be added to PM_Workplace:handles.
This is pointless because the file is no longer on the harddrive and Checkini or Multimaint will just remove the file handle next time I do an ini check.
So this new "feature" needs to go.

If you ever decide to totally redesign the file open window I suggest you isolate the drag and drop process from the desktop like FM/2 file manager does instead of duplicating the bad behavior of the OS/2 desktop's drives folders.

This is because PMView Pro uses the PM WPS APIs instead of low level OS/2 DOS APIs to delete the files.

I agree that the side effect is not welcome. It's strange that WPS does not clean after itself when the file is deleted.

The reason for using WPS is to give the user instant visual feedback in the WPS folders. (If WPS is not used, there is a delay [typically 5 seconds] until the WPS folders are updated).

I'll see what I can do about this. If there is not a solution to the problem I can always add an option that lets you tell PMView to use DOS APIs for copy/move/delete instead of using the PM WPS APIs.

Thanks,



Edited By Peter on 1054927257

It looks like the cleanest solution is to add an option for not using the WPS for file operations.

Thanks,

Hello Peter,

Thanks for eplaining the benefits of using the wps instead of the DOS APIs to me.
It really sounds like this is a problem that IBM has to fix with OS/2 and not a PMView Pro specific problem.

In the meantime I agree that adding an option to select between the two methods is the perfect solution.
I can't wait start using PMView Pro's file open window for all my image file operations again!
PMView Pro's file open window will once again be my first choice wjen it comes to viewing thumbnails of, moving and deleting image files.

Thanks,

Cristopher,

I'll see what I can do about the WPS/DOS issue. PMView Pro has nicely isolated all the copy/move/delete functions to one source code module. This means it should be pretty easy to add the option you need. I'll see if I can do it for 3.01. If not, 3.10 (the next "feature release") will definitely have it.

Thanks,



Edited By Peter on 1055039943

3.01 will have this option.

Thanks,



Edited By Peter on 1055127175