简体   繁体   中英

Explorer Namespace Extension- what is the entering method of Save in third party application?

I have a program with Namespace Extension that is based on linking (the folders does not exist locally). Whenever i try to save a file under the folder that is using the ShellExtension i get an error:

C:\\folderPath...

Path does not exist.

Check the path and try again.

I try to find the entry point that explorer is calling in order to create the folder just before it tries to save, yet all my attempts seem to fail. I can catch the open event by breakpoint on "OnCommonDialogOKButtonClicked" method.

maybe this is an explorer bug, yet i'm not certain.

I have found on some external link that is associated with ShellExtension the following information: linkshellextension and i quote:

Unfortunatley this is a bug in Explorer, and I don't have a clue how to come around this in explorer. If you start the symlink to an .exe from a command prompt it works fine, and even third party explorers like SpeedCommander can do this, but explorer seems to have a limitation Does anybody know the registry hack to enable this in explorer.exe? Drop me a line.

where is the entry point? Is it a poor design of explorer? I have to create the folder while navigating in order to solve the problem?

The folder must be created and exist locally whenever the save button is clicked. I'm guessing you're using EZNamespace (according to the method you supplied) - which internally, it's called after the file dialog is destroyed . which is poor design by them.

they suggest to create all of your folders while navigating - but i found another way.

The reason it happens, is because when the dialog suppose to close, the path should exist (file dialogs usually are created with an option that says "PATHMUSTEXIST" or "FILEMUSTEXIST" in case of open file dialogs - this cannot be changed after the 3rd party application created the dialog.

i'd suggest to try and implement IObjectWithSite in your custom virtual folder, here's an example:

http://blogs.msdn.com/b/winsdk/archive/2015/03/24/how-to-register-for-file-dialog-notifications-from-shell-namespace-extension.aspx

Just change all "open" to "save" and it will work.

eventually what this does, is that it hooks and registers the IFileDialogEvents for that specific dialog. then you can control some actions around it (for example, use "OnFileOk" instead of your above method, which allows you to cancel the "Ok" with your validations, and also get the actual IShellItem selected.

Whenever "OnFolderChange" is called, you can create your folder, and delete the old one: https://msdn.microsoft.com/en-us/library/windows/desktop/bb775880(v=vs.85).aspx

Just make sure to not destroy it when the "ok" is eventually clicked, you may delete the folder when the dialog is destroyed (so if user will decide to cancel, you will not have junk folders in your file system).

this should be done here:

if (m_fileOpenDialog != NULL)

        {

            m_fileOpenDialog->Unadvise(m_cookie);

            m_fileOpenDialog->Release();

            m_fileOpenDialog = NULL;

            m_cookie = 0;

        }

just make sure to keep a flag if you pressed the "ok" and not delete the folder.

If the folder exists, the file will be created in the designated file system (you MUST make sure that your virtual file's GetDisplayName will point to the real file system path.

another important note, whenever "OnFileOk" is called, your file will not be there yet (as this runs on the main thread of the 3rd party application). you will have to wait for it to finish writing itself to the file system, then handle it if you want.

As this post is old, if any more concrete examples are needed, just hit with a comment and i'll supply.

Good luck.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM