QAP Support Forum

Full Version: Support Current Folders in file managers supported by QAPconnect
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This is following a suggestion from tmp.

This simple solution would allow QAP to build the "Reopen Current Folder" menu or to execute the "Reopen Current Folder in Dialog box" for any file manager supported by QAPconnect.

1) The user adds to the QAP working folder a script file named "QAPconnect-CurrentFolders" (any supported executable extension: .COM .EXE .BAT .CMD .VBS .VBE .JS .JSE .WSF .WSH .MSC .AHK) that is getting the path of the folders in the file manager (one or more if the manage supports multiple tabs) and store the values in the Clipboard, one by line, the first line being the active folder. Users could share their scripts on the QAP forum.

2) When getting the list of current folders, QAP takes a backup of the Clipboard, executes the "QAPconnect-CurrentFolders" script and, if the clipboard contains existing folders paths, use them to build the "Reopen a Folder" menu or use the first line to execute "Reopen Current Folder in Dialog box" command. After, QAP restores the previous backup.
Hey, thank you, Jean,

Thank you for picking up my original thought and improving it even further.
Regarding your thought itself, this also seems like it would be a nice solution for as many people as possible, since it would not only allow for ahk code but for many other languages / options as well of how to supply the path(s). Thank you. Looking foreward to the day when it might be realized. :-)

Regards, S.

EDIT:
If I understand you correctly, the "QAPconnect-CurrentFolders" file would actually have nothing directly to do with the QAPconnect feature or the ini file - besides that "Reopen Current Folder" would reopen the chosen folder in the "preferred" file manager, correct? Escpecially the question from where the script fetches the folder(s) would be completely independent from the "preferred" file manager, although in real life it would probably be one and the same file manager, but it is up to the script to decide on its own from where the folder(s) are fetched really. I am thinking of scenarios where there are multiple file managers being used. Then the script could of course fetch folders from as many file managers as the coder would want it to. But maybe the user would want to switch the "preferred" file manager more often than you might think. Or sometimes want to have Windows Explorer as the source and sometimes a different file manager. But maybe I am thinking too far ahead. Please, consider this a simple brain storming session. Thanks.
> Escpecially the question from where the script fetches the folder(s) would be completely independent from the "preferred" file manager

Yes. It will be the user's responsibility to set the correct script for the file manager selected in the QAPconnect list.

> I am thinking of scenarios where there are multiple file managers being used.
> But maybe the user would want to switch the "preferred" file manager more often than you might think.
> Or sometimes want to have Windows Explorer as the source

Regardless of the selected alternative file manager (Directory Opus, Total Commander or one of the QAP connect file managers), the folder(s) Windows Explorer window(s) are always added to the "Reopen Current Folder" or checked for the active file manager window for the "Reopen Current folder in dialog box".

After that, if the user has possibly multiple active file managers, it would be the job of his script to check for the current QAPconnect file manager (from the variables ActiveFileManager and QAPconnectFileManager in the QAP ini file) or to check the multiple sources when setting the content of the Clipboard.

I propose this approach for to minimise the work in QAP in order to implement and deliver this feature faster (admitting it is intended for above average "power users"). An approach more integrated in QAP would require more work/time and would be in competition with other feature requests that would benefit more users.

Jean