SpecialFolders Automation Script

Support for developers of new plugins, third-party plugin announcements and discussions.
User avatar
SvA
Posts: 441
Joined: 29 Mar 2006, 02:41
Location: DE

SpecialFolders Automation Script

Post by SvA » 22 Jun 2012, 15:56

This is an Automation plugin scrip which allows you to jump to windows special folder path by selecting them from a list with symbolic names and determining it's actual path from a windows API using CSIDL-constants. Additionally it allows to execute the actions on that folder's context menu, so as to launch an explorer window (e.g for folders which do not have a file system representation, such as Network Connections)

The Automation plugin does not provide a suitable interface for this kind of plugin, so the script launches a Html Application (.hta) to provide the interface. Unfortunately, I did not find a way to make this interface modal, Salamander is rendered inoperable until the script ends, though. (It shows a tiny dialog to inform you, however the offered abort does not work.) So, make sure you don't get confused!

The ability to launch items from the folder's context menu is not well tested. I used Open, Explore, and Properties many times, with no problems occurring, but use it on your own risk. The whole script, not only this feature comes without any warranty of any kind.

Tested on Windows XP and Vista.

Feedback and bug reports and suggestions welcome. Enjoy!

To install extract the contents of the archive to some directory configured to be a script directory in Automation plugin e.g. $(SalDir]\plugins\Automation\scripts by default. All files need to be in the same directory.
Attachments
SpecialFolders.zip
SpecialFolders 1.0
(22.78 KiB) Downloaded 295 times

User avatar
SvA
Posts: 441
Joined: 29 Mar 2006, 02:41
Location: DE

SpecialFolders Automation Script: History and Background

Post by SvA » 22 Jun 2012, 17:31

Over in an other Thread (SDK Documentation to English I posted a request to the community to provide SDK translation to English, unfortunately with no response to the actual appeal. Jan Rysaviy's response, asking what kind of plugin had I mind to create I left unanswered there for several reasons
  • I did not want that thread to take off in another direction
  • I believe it'd be good to give more people the opportunity of contributing
  • and finally, and most compelling^, I did not know, what kind of plugin I intended to create
I have had many ideas, most of them rising from a momentary need and soon after be forgotten, until the need arises again. Most of these are either viewers or archivers.
But two things, I believe can be solved with plugins, come to mind frequently
  1. a flat folder view in a panel. With this I mean to have basically the search result panel from find in a regular directory list panel, with a path column added.
  2. some way to jump to all those special windows folders which may be somewhere different on each machine/for each user.
This latter plugin I intended to tackle first, but I really didn't know what interface would work best. A menu extension? A pseudo-filesystem? Might it be possible to extend the standard change folder dialog or create a dialog to be used as an alternative? Might it be possible to add KNOWNFOLDERID-Pseudo-variables to path names in the same manner as environment variables (e.g. $[TEMP] -> ${COOKIES})

To answer that question, and maybe even get rid of it by providing another solution I decided to try implementing it through the Automation plugin. I knew I had looked at it before, and rejected the idea, but this time I went about with more determination. The most challenging part of it was the user interface. Automation plugin allows to design a simple form, but it is intended to acquire input before the actual script runs, i.e. script execution is halted while the form is executed, nor does it support handling events. Any button pressed closes the form. Furthermore, only the most basic controls are offered, nothing suitable to present a list of some 60 options to the user.

An UI could be created with some more elaborate scripting languages, such as perl, but I wanted to stick with the default scripting languages provided by the OS. When looking to UI options for these you get referred to HTA or IE-automation. The latter tends to be slow to launch and tends to not show the UI but instead show a blinking item in the task bar for you to activate. With both solutions, the UI is not modal to Salamander's window, as it ought to be. So, I decided to opt for the HTA-solution with the disadvantage of having at least one additional file.

The next problem, that resulted from this having a detached UI was how to communicate between the launcher script and the UI. HTA does not provide access to SdtIn, StdOut, StdErr, and does not allow to return an exit status. It does allow access to command line parameters, though. Since I could avoid having to communicate while the UI is open (it would prove handy though for the options dialog), I utilized command line parameters to get info to the UI and the environment to pass back the chosen folder. Since the process environment does not work I used volatile environment, which Windows Scripting Host provides easy access to, and was astonished that it worked even on XP which does not have a volatile environment, as far as I know. WSH somehow handles this.

As the choice for presenting the options I thought of a grid control, but, since html does not provide one I decided to first try several drop-down selectors which I would synchronize, I thought of letting the user choose either using the CSIDL constant name, the CSIDL constant number and the name provided by the API. I then found that the number would be useless for almoust anyone and the name provided by the API was ambiguous, so I dropped them both. An obvious replacement for the grid control had been a table, but I am not an experienced html programmer and I doubt a table would provide the selection capabilities I needed.

I soon recognized, that it is very uncomfortable to select from so many options, most of them rarely used. For this reason I created a history list, which seems to suite the task well.

My UI is multi language capable. At the moment English and German are provided. Since I found no way to get the UI language chosen in Salamander, I use the system's locale, with no option to override it. This again is due to the limited character of Automation plugin forms, which I chose to implement an options dialog. I just don't know any useful method to let the user choose his preferred language, given there were more than just the two as of now.

Automatic language selection is not implemented in the .vbs-part, although all localizeable strings are collected to a section in the beginning of the script.

Conclusion
- Automation scripts don't go together well with more than the most basic UI needs.
- With what I learned from using he plugin, I would want to implement this with the SDK in the same way the change directory dialog is with a list of selections provided underneath the combo box with either history entries or user picked entries shown for quick'n'easy selection and the complete list from the browse button.

By the way: I had a problem with the layout of the option dialog with AS 2.54: the Ok and cancel buttons overlapped. I thought I have seen that problem also with AS 3.0 beta 1 PB79 once, but I am not sure. I cannot do anything against this. it appears to be an error in the automation plugin. I Checked with the Image Conversion sample plugin, which showed the same flaw, mostly, but not always reproducible with 2.54

Post Reply