I've uploaded v11.0.28 (RC1) to the ftp and web autoupdater sites. This should address all known bugs, and it now includes support for Tk scripts.
I renew my b27 comment about modifying the @tcl documentation to be about supporting 'Tcl expressions' and not 'Tcl/tk expressions.' My simple Tcl/Tk script (posted before) executes as expected from the prompt. Here's a new one. File: test.tcl Code: puts "abc" C:\Tcl\demos\Tk8.5>test.tcl abc Unfortunately, this simple command line Tcl script now blocks until the Tk window is closed by the user. I understand you have no way of knowing what kind of script will be executed, Tcl vs Tcl/Tk, without actually parsing the script file(s) first. And, with included files possible, finding a Tk command or 'package require Tk' may be tedious. But, unless both Tcl scripts can be run as under tclsh and Tcl/Tk scripts run as under wish, the behavior may be viewed as 'wrong' by a user. Tim
I get the error System Error: The program can't start because tk85.dll is missing from your system in TCMD x64 11.0.28 on Win7 Ultimate
On 2009-10-21 05:58, rconn wrote: Unfortunately tcc.exe and tcmd.exe (the x64 versions) now die on startup with "This application has failed to start because tk85.dll was not found. Re-installing the application may fix this problem." Note that I don't have any trace of TCL or TK on my system, TCmd.ini contains "Tcl=No", and there is no tcl85.dll or tk85.dll anywhere in my PATH. This problem does not occur with the x86 version, however.
If you don't want the script to block, then there's no reason to execute it from TCC -- just use tclsh. The internal Tcl/Tk support is intended 99% for Tk scripts, as you will see in future builds. Rex Conn JP Software
That's fine. I just wanted to provide you with my feedback so you will know what to include in the documentation to manage user expectations, command line for Tcl/Tk and @tcl for Tcl. This reminds me of a feature request I made long ago. Hmmm. :) Tim
Replace "tedious" with "impossible", given the number of ways that Tk can be indirectly invoked. And the Tcl/Tk developers apparently don't have any way of doing it, or they wouldn't need to create multiple variations of the shell (which require the user to already know how whether it's a Tk script). The best I can do is *not* do a Tk_Init before the script is invoked, which requires the user to have a "package require tk" somewhere, and after the Tcl_EvalFile look for Tk windows. This is necessary because unless I shut down & reinitialize the interpreter, the next Tk script will fail -- it also means you cannot have a persistent interpreter executing Tk scripts from the command line. I've also added a @TK var function which will allow you to execute a script without the "package require tk", and which will always create the Tk window & enter an event loop. Rex Conn JP Software
Would it work to have an option for the user to choose which shell to use, tclsh or wish? Requiring the 'package require Tk' with wish would be acceptable for that option (at least for me). Perhaps there could be an optional parameter for both @tcl and @tk, to return the exit code instead of expression result. Also, @tcl doesn't appear to return the results of an expression. Here's an example: Code: C:\Tcl\demos\Tk8.5>echo %@tcl[expr 123 + 456] expr 123 + 456 C:\Tcl\demos\Tk8.5>tclsh % expr 123 + 456 579 % exit Tim Edit: For some reason, this message was not emailed to me.
Not sure what you're referring to here -- TCC doesn't use any shell (tclsh or wish) to execute the Tcl/Tk scripts; it runs them internally. I don't know of a way to have an option to return the result code without interfering with (unknowable) the argument syntax. The @TCL result string is fixed in build 29.
Without integrated supported, the user would have to explicitly call either tclsh or wish to execute their script. My suggestion is to include a similar choice to set a default for the internal support. The user could choose whether the internal support should include the Tk window and event handler (for Tcl/Tk scripts) or not (for Tcl scripts). Further, something like a setdos command/parameter variant could be used to programmatically switch between the Tcl vs Tcl/tk internal support variations. Tim
I don't think there's any need for that. In 11.0.29, TCC will execute the script (via Tcl_EvalFile), and then look to see if a Tk window was created (which will happen automatically if the script does something like "package require tk"). If so, TCC enters an event loop; if not, it's assumed to be a Tcl script and TCC will return immediately. If you want to make a script that's uninterpretable even by the Tcl/tk parser, you can force either Tcl or Tk interpretation by using @TCL and @TK. The only potential problem I can see with this approach is if you want to create a Tk script *without* an event loop -- but I don't think there's any way to do that with tclsh or wish either. Rex Conn JP Software
