emptist, 2005/11/19: strange thing: sdx refuses to move
After testing out how to use tclkit and sdx to built a single exe, I decided to create a dir for these three files: tclkit.exe sdx.kit tclkitsh.exe, to find
tclkitsh sdx.kit
runs into a:
invalid command name "sdx"
while the original copy of these files in another dir still works.
MHo, 2005/11/11: trying to do a
tclkitsh sdx.kit
from within a directory which includes spaces in its name, fails:
D:\Dokumente und Einstellungen\hoffmann\Eigene Dateien\Downloads>tclkitsh sdx.kit version wrong # args: should be "source file" while executing "source sdx.kit/main.tcl" ("uplevel" body line 1) invoked from within "uplevel [list source [file join $self main.tcl]]"
Quoting hell strikes again. The problem is that the sdx script (sdx.kit/lib/app-sdx/sdx.tcl) runs
uplevel #0 source [file join $b $a.tcl]
and $b is the current directory, which can contain spaces. The simple fix is to change this to
uplevel #0 [list source [file join $b $a.tcl]]
and all should be well.
Thanks, should be fixed now. -jcw
December 20, 2002
If you use Windows \ notation for a filename, SDX fails.
If you try to add registered methods to the .KIT filetype (wrap, unwrap etc) then when you right-click on the filename and choose the method, SDX fails. This appears to be fixed for the *first* filename but not for the second. That is, tclkitsh can find sdx.kit, but tclkitsh with SDX can't find your file. It creates an empty correctly-named .vfs folder and aborts.
When I massaged the filename the problem went away:
file unwrap.tcl
set aa [lindex $argv 0] set aa [string map {\\ /} $aa] exec tclkitsh.exe sdx.kit unwrap $aa
I registered this as "<path>tclkitsh <path>unwrap.tcl %1" and it worked for me on Windows XP and Windows 98.
It might be possible to fix this inside SDX assuming that you'll never need a unix backslash character in a filename. I'm not sure that's a good idea.
Jonah Thomas
ZipGuy 06-06-2003 -
I have created a Starkit to solve this problem on Windows. It's called Windows SDX Shell Fix and it front-ends sdx.kit.
LV 2007 July 11
Here's what I see as I am attempting to survive my first dealings with starkits under Windows (shudder). Just wanted other first timers to see what to expect. Hopefully the experts will wander by and add useful tips for us here.
I have a tclkit.exe, a starkit (tls.kit), and sdx.kit.
I open a cmd.exe window and I type:
sdx.kit lsk tls.kit
Initially, I get a dialog from windows saying it doesn't know how to deal with a .kit file. I point it to the tclkit.exe. I then type the command again.
This time, I get a tkcon console, as well as a widget that is titled "sdx" with a label of "Command line:".
I type "help", and the sdx help output appears in the console. But the command line dialog is gone. Okay, that's how things work on Unix...
So, I quit the tkcon, and type the command again. I see that the arguments are doing me no good in cmd.exe, so I type just the arguments into the sdx command line window. That seems to work.
Sure would be nice if I could just run sdx.kit with arguments and not have to interact with the other windows - anyone know how to make that happen?
Things probably work better if you use tclkitsh.exe i.s.o. tclkit.exe, i.e. "tclkitsh sdx.kit ..." -jcw
LV 2007 July 12 Thanks for the suggestion. I changed my script to:
#! tclkitsh if { $::argc == 0 } { puts stderr "USAGE: $::argv0 ScriptToWrap" return 1 } set basename [file rootname $::argv] set p /path/to/tools set tclkit $p/tclkitsh.exe exec $tclkit $p/sdx.kit qwrap $::argv exec $tclkit $p/sdx.kit unwrap $::basename.kit exec $tclkit $p/sdx.kit wrap $::basename.exe -runtime $p/tclkit.exe
For some reason, the mks toolkit shell is invoking something for this script that still displays a frame, and, for that matter, ends with a "Segmentation violation".
Also, because I am trying to build a script that will wrap Tk based scripts, I use tclkit rather than tclkitsh. This means that my helloworld.tcl had to change to
package require Tk console show wm withdraw . puts "hello, world"
Now, when wrapped, what happens is that the console opens up with the output to stdout and the program completes.
Whew! What a long complicated set of things (many of which I didn't document here because they were more to do with the toolset I was using, the environment we have here, etc.).
Hopefully this will be of help to someone else though.