[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 [starkit]s 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.


----



[Category Tclkit]