This would make all implementations for finding applications currently in place in Cyberduck Windows obsolete, as I'd like to just create one implementation which is capable of opening a file with any application, through Windows Shell.
Append last item "Open With …" which uses SHOpenWithDialog.
Unsure how to fit this into EditorFactory and ApplicationFinder though.
Need to extend Application class to allow for passing IAssocHandler down the line and invoked with a file path.
Cannot use ApplicationLauncher or ApplicationFinder as provided by AbstractEditor as that relies on Process.Start, which is unavailable here.
CLI behavior changes to following: --edit downloads file and opens default/recommended handler. If non available use SHOpenWithDialog
Adding --edit=with or --edit-with always uses SHOpenWithDialog. Opinions here?
Behavior will need to address for situations where there is no editor defined for a file type, i.e.:
For .mp4 there is no editor defined on my system, but an application which is set as default viewer.
Do we want to allow fast editing (Ctrl+K) for files with no registered application capable of editing a file type?
SHAssocEnumHandlers will return any application with registered open verb of file type, not necessarily only handlers which are edit capable. There is no way of determining whether IAssocHandler can edit a particular file.
We can ShellExecuteEx any arbitrary ProgId with specified verbs. This will need PInvoke, as ProcessStartInfo/Process.Start cannot use lpClass-field for starting a ProgId.
Need to differentiate in ApplicationLauncher between ProgIdApplication and ShellApplication, which use different ways of invoking (IAssocHandler.Invoke/ShellExecuteEx).