Tuesday, March 11, 2003, 11:42:09 AM, Rolf Kalbermatter wrote:
Hi,
The main reason why I made this patch is to make our software package work under WINE. Our application was heavily relies on correct behavior of SHFileOperation function. In particular:
- User confirmation for deleting files and folders.
- Ability to delete files only in any given directory.
- Receiving notifications for every operation to refresh screens properly.
I'm going to check those things. I know that file movements did not implement SHChangeNotification, mainly because I wanted to check first that they really got genereated in Windows native.
I'm not sure here. I haven't tested it under windows. But logic suggests that it will. Since all other operations from SHFileOperation do generate Notify events.
Do you mean in 2) that the user can acknowledge every single directory to be deleted? Mmmh, thinking about it I see that Windows allows to select 4 different buttons to delete all, only this, this not or cancel. Well this is sort of involved but can be implemented.
in 2) I Meant use of flag FOF_FLILESINLY
Yes, I could hack that patch and make it work but I used existing code as a basis since it implements _all_ functionality of SHFileOperation except unicode.
That is not exactly true. The rename operation is not fully implemented in the current code as well as some of the operations with multiple file names.
Sorry my bad. I should of looked at the code closer.
Major missing parts was: - No implementation for FOF_FLILESINLY - Incorrect Notify events - Improper handling of *? in some tests (don't remember which ones)
My point here is: I don't think Alexandre will apply this patch if it doesn't pass all tests while current code does.
[skip]
So, after a file gets deleted it's path is no longer valid. What was happening is application was getting notification that whole drive was deleted!
Mmh, we have to investigate further in Windows. Because the Win32... functions itself in W2K do actually not take this precaution and appearently assume that SHChangeNotify does the proper action. So either W2K does something else somewhere or the Wine SHChangeNotify function is broken in that it should be able to create notifications even for just deleted directory and file paths. I guess the later as MSDN mentions nothing that the parameter needs to be an IDLIST instead of a path for those operations but rather explicitedly mentions that SHCNF_PATH is allowed for SHCNE_DELETE, SHCNE_RENAME, SHCNE_RMDIR and such.
Well it's hard to tell what _exactly_ going on inside native shell32.dll. :-) There are number of thing which look different: - Notification events happening about 1-2 seconds after operation is completed. - There whole Explorer thingy running at all times. Who knows what it keeps in it's memory? :-)
When I said "This fact verified on windows." here is what I did: I tried to create PIDL from non-existent file. In WINE we have same problem: delete first, create PIDL and send to app _after successful_ operation. Unless we'll cache this operations on low level and keep it's info around for some time - it will not work. In some way I did exactly that - stored PIDL of file/directory that was about to be deleted/renamed.
If you want I can run few tests on Windows to see how it reacts on SHChangeNotify call with a path of a deleted file.
[skip]
I still intend to get the patch(es) to SHFileOperation applied if possible, but also want to make sure it doesn't break your application at all. Are you interested to get eventual new patches sent directly as they get verified?
Yes I would be very mach interested in testing these patches in my sand box.
Vitaliy Margolen