The Zipguy 06/06/2003 zipguypub @ bellsouth dot netWSF makes it easy and forgiving to assign right-click sdx commands to your context menus on Windows. SDX fails currently on those commands since the Windows Shell uses \'s. Also WSF makes it easier for newbies to starkits, tcl and/or sdx to get it working on Windows.This is what WSF looks like unwrapping a file
SDX under Windows mentions this problem as wellNormally, on Windows, along with with a new file extension, you get a new file type and actions for that type which appear in the right click context menu. So for a Starkit's .kit extension, actions like "wrap", "unwrap","list", "update" etc. would be natural.In windows this is accomplished by creating a new "File Type" of "Kit file" and associating the extension ".kit with that "File Type". Then new actions are added along with commands to perform those operation. At the end of the command for a given action a %1 or "%1" is placed and and windows will replace that with the fully qualified name (drive:\path...\filename.ext) of the file which was right clicked.Unfortunately if one tries to do this using sdx.kit it fails, because the path separator in Windows "\" is the escape character to TCL so it mangles the filename badly. Things get very ugly if a subdirectory starts with "t" or "n" which get interpreted as "tab" and "return" respectively (there are more ugly characters).Gotta hate Microsoft's forward slashes in file paths. But also gotta hate Tcl's compulsive automatic and so often inadvertent path translation.
This is one of the annoyances with using SDX on Windows that WFS fixes. Since Windows will set the path to the folder which contains the file before invoking the command, simply doing a
set lastparm [file tail [lindex $argv end] ]and then a
set argv [lreplace $argv end end $lastparm]or combined
set argv [lreplace $argv end end [file tail [lindex $argv end] ] ]and then passing control to sdx.kit would suffice to fix the problemSo if a file named rightclicked.kit (thought it was going to be foo.kit didn't you?) were right clicked upon and an "Unwrap"command choosen that was defined as
"<path>tclkit-win32.upx.exe" "<path>sdx.kit" unwrap "%1"tclkit would get called with the parameters
<path>sdx.kit unwrap <path>fileclicked.kitThis would fail for the reasons given above.wsf.kit is a drop-in front-end for sdx.kit so if you change the command to
"<path>tclkit-win32.upx.exe" "<path>wsf.kit" unwrap "%1"wsf will remove the path from the filename.NOTE: wsf.kit must be in the same folder as sdx.kit. Tclkit can be anywhere.wsf:
- receives the parameters
- adjusts the last one which has the <path>filename.ext so that it just has filename.ext
- calls sdx passing the parameters
- it's running under Windows
- the last parameter is a filespec
- the file exists (gives error if not)
- that sdx.kit exists in the same folder as wsf.kit
and will be submitted to the Starkit Archive (http://www.tcl.tk/starkits/). IE USERS: you may have to Right-Click on the previous link and select "Save Target as.." to download it (if you get a screen of gibberish)If you just want to look at the source it's at [1]'Defining the .kit "File Type" and sdx "Actions"'Adding the "Kit File" File TypeFrom Windows explorer: (Windows ME)
- select "Tools">"Folder" Options from the menu
- select the "File Types" tab
- click the new button under the "File Types" list
- put ".kit" in the "File Extension" field
- click ok
- if necessary, from Windows Explorer select "Tools">"Folder" Options from the menu and then the "File Types" tab
- click on the "KIT" file Type
- click on the "Advanced" Button near the bottom
- in the "Edit File Type" dialog box, click on the "New" button to the right of the "Actions" listbox.
Action Command ----------------------------------------------------- List "<path>tclkit-win32.upx.exe" "<path>wsf.kit" lsk "%1" UnWrap "<path>tclkit-win32.upx.exe" "<path>wsf.kit" unwrap "%1" Update "<path>tclkit-win32.upx.exe" "<path>wsf.kit" update "%1" Wrap "<path>tclkit-win32.upx.exe" "<path>wsf.kit" wrap "%1"Where <path> is the fully qualified path to the file. You can use the browse button for the tclkit file.Then make sure that you put sdx.kit in the same folder as wsf.kit.By fully qualifying the tclkit and wsf files you can use these commands on a file in any folder on your Windows partitions.
Orphan SDX Processes Problem There is another SDX potential problem that wsf.kit addresses. sdx.kit runs in a console and gives messages.When it's finished the savvy tcl user would know to:
- hit enter to get a prompt
- and type in exit to end that session.
Since adding a "File Type" with an "Associated Extension" and adding "Actions" and defining "Commands" is often seldom used by far too many Windows users (because Windows installers usually do this for them), this is a terrritory where too many Windows users rarely tread. Consequently, it is also an area with which they are unfamilar, and quite likely to make mistakes.Consider also that these are exactly the people that we would like to make successful, and precisely at this time since they probably just got excited about tcl, tclkit, starkits, have downloaded tclkit and sdx, and want an easy way to be able to unwrap that neat little application and look at the code. This would be an awful time to have them get frustrated by this thrashing around with Windows nonsense.For these reasons, instead of just keeping wsf very simple, it tries to be very forgiving and notice and detect errors that they may have made, and give them helpful error messages.These excited TCL newbies would read the success messages and most likely almost all of them would just close the window, which leaves the tclkit running. This can lead to all kinds of problems with memory and in-use files further down the road. If one just closes the console, you need to Ctrl-Alt-Delete and cancel the zombie tasks to free things up.... Not good.
Which you kill like this
To solve this situation, after all the edits, just before the call to sdx.kit, wsf creates a small window with only an exit button so that it's obvious that something is running, and provides them with an easy way to end the task.Unfortunately, sdx.kit does a
wm withdraw .so wsf.kit does an
after 500 wm deiconify .after sdx runs.Also the new version v1.01 does anafter 300000 exitso if it the console and any other windows gets closed somehow, it exits after 5 minutes.
Great care was taken to avoid having to modify sdx.kit or include sdx.kit, and to design wsf.kit to be easy to use, mistake tolerant, and informative (er.. verbose) in error situations. As a result it is probably large, considering the small role it really plays.As this is the ZipGuy's first starkit it probably has lots of room for improvement and better coding by those more knowledgeable and smarter. At least it works and meets the intended goals. So comments and constructive criticism are very welcome.
by The ZipGuy email: zipguypub @ bellsouth dot net
website: http://www.zipguy.012webpages.com
Free PDF: http://www.zipguy.012webpages.com/freepdf.htm
TCL: http://www.nonags.org/members/zipguy/tcl.htmWow, this is geat. Is there anything I can do to help make SDX fit in better? -jcw
Zipguy 06/07/2003 - Updated the Starkit with some minor changes, code cleanup, did some proc-ification and added the "Exit" button and appropriate messages whenever an error is detected.wsf.kit version is now v1.01. Also added a page for the Windows Shell Fix Source so people can peruse the code here without having to download and unwrap the WSF Starkit.The ZipGuy is quite pleased (flattered actually) that you like my humble WSF JCW. Obviously you haven't looked at my crude code [2].
JMN 2003-10-19 You can presumably do away with the separate exit button and timer by adding the following line after you do the 'console show'.console eval {wm protocol . WM_DELETE_WINDOW exit}I think this would be a nice addition to SDX too - I've added it to both on my system.. it doesn't matter if it's called twice.
