Take Command v11 Public Beta Build 27 Uploaded

[rconn]

I've uploaded build 27 to the ftp beta and web updater sites. This should address all of the reported bugs to date.

Note that the TCTOOLBAR input files have changed to match the [TOOLBARn] sections in TCMD.INI, so if you have existing files you're reading with TCTOOLBAR /R you will have to edit them to include the section name.

Also, the /P option has been removed from ZIP.

 

[TimButterfield]

I retested the Tk behavior.

Here is my Test.tcl file:

wm title . "Test"
label .lbl -text "Test text"
pack .lbl -ipadx 80 -ipady 20

C:\Tcl\demos\Tk8.5>echo %@tcl[source test.tcl]
source test.tcl

It doesn't run the Tk script like it does the Tcl script.

C:\Tcl\demos\Tk8.5>test.tcl
Tcl: window name "lbl" already exists in parent

It seems the prior source ran part of the script, but just didn't display it. If I close and restart TCMD without running the first echo %@tcl line as above, I get this behavior.

C:\Tcl\demos\Tk8.5>test.tcl

That ran the Tk script and displayed the window; it didn't need to run wish as before. I then closed the window.

C:\Tcl\demos\Tk8.5>test.tcl
Tcl: can't invoke "wm" command:  application has been destroyed

Apparently, it doesn't reinit Tk if windows get closed.

Tim

 

[rconn]

I retested the Tk behavior.

The Tk support is not yet enabled. I will let you know when it's working.

 

[TimButterfield]

Re: Take Command v11 Public Beta Build 27 Uploaded

Sorry. Just responding to the "This should address all of the
reported bugs to date." that didn't exclude Tk this time. I will wait
for you to explicitly say Tk is fixed.

Tim

On Mon, Oct 19, 2009 at 3:48 PM, rconn <> wrote:

> ---Quote (Originally by TimButterfield)---
> I retested the Tk behavior.
> ---End Quote---
>
> The Tk support is not yet enabled. *I will let you know when it's working.
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rex Conn
> JP Software

 

[rconn]

Re: Take Command v11 Public Beta Build 27 Uploaded

> Sorry. Just responding to the "This should address all of the
> reported bugs to date." that didn't exclude Tk this time. I will wait
> for you to explicitly say Tk is fixed.

Tk is currently an unimplemented feature, not a bug.

Rex Conn
JP Software

 

[TimButterfield]

Re: Take Command v11 Public Beta Build 27 Uploaded

On Mon, Oct 19, 2009 at 7:35 PM, rconn <> wrote:

> ---Quote---
>> Sorry. *Just responding to the "This should address all of the
>> reported bugs to date." that didn't exclude Tk this time. *I will wait
>> for you to explicitly say Tk is fixed.
> ---End Quote---
> Tk is currently an unimplemented feature, not a bug.

Understood. As an FYI, if it remains that way for the released
version of v11, the reference to 'Tcl/Tk' in the documentation will be
in error.

Tim

 

[rconn]

Re: Take Command v11 Public Beta Build 27 Uploaded

> ---Quote---
> > Tk is currently an unimplemented feature, not a bug.
> ---End Quote---
> Understood. As an FYI, if it remains that way for the released
> version of v11, the reference to 'Tcl/Tk' in the documentation will be
> in error.

If I can't work around the Tk bug, I will remove both Tcl and Tk from v11
before release.

Rex Conn
JP Software

 

[rconn]

> Here is my Test.tcl file:
>
> Code:
> ---------
> wm title . "Test"
> label .lbl -text "Test text"
> pack .lbl -ipadx 80 -ipady 20
> ---------
>
> Code:
> ---------
> C:\Tcl\demos\Tk8.5>echo %@tcl[source test.tcl]
> source test.tcl
> ---------
> It doesn't run the Tk script like it does the Tcl script.

Why are you trying to run a script via the @tcl var function? The @tcl
function is intended to execute a single Tcl / tk statement, not a script.
Thus, it has no event loop, and Tk scripts will never (ever) work.

> Code:
> ---------
> C:\Tcl\demos\Tk8.5>test.tcl
> Tcl: window name "lbl" already exists in parent
> ---------

WAD, and doing exactly what you told it to (though admittedly not what you
expected it to do). When you close the Tk window, you're destroying the "."
root Tk window, which causes Tk to be destroyed. (This is special Tk
behavior with the root window.) There's two choices here: either I have to
make the interpreter non-persistent (so you'll lose everything between
script invocations), or you have to use something like "wm withdraw ." to
hide the root and then create a new one.

> Apparently, it doesn't reinit Tk if windows get closed.

How would it know?

Rex Conn
JP Software

 

[TimButterfield]

Why are you trying to run a script via the @tcl var function? The @tcl function is intended to execute a single Tcl / tk statement, not a script. Thus, it has no event loop, and Tk scripts will never (ever) work.

I tried that because of the documentation. It says it supported Tcl/Tk. Tcl is the language. Tk is the Tk GUI Toolkit. Since Tk was claimed to be supported, I tried it.

WAD, and doing exactly what you told it to (though admittedly not what you
expected it to do). When you close the Tk window, you're destroying the "."
root Tk window, which causes Tk to be destroyed. (This is special Tk
behavior with the root window.) There's two choices here: either I have to
make the interpreter non-persistent (so you'll lose everything between
script invocations), or you have to use something like "wm withdraw ." to
hide the root and then create a new one.

How would it know?

Rex Conn
JP Software

That was one of the reasons behind my prior suggestion of an @tk function, to initialize the root Tk window and event loop as needed. I wasn't sure what to expect as the documentation provides no examples. I was just trying things to see what would happen, trying to guess and fill in the blanks about what may or may not be supported. The parameter I passed was a valid (though apparently unsupported) expression. If Tk scripts 'will never (ever) work,' this is a moot point and the documentation is in error.

Tim

 

[rconn]

> That was one of the reasons behind my prior suggestion of an @tk
> function, to initialize the root Tk window and event loop as needed. I
> wasn't sure what to expect as the documentation provides no examples.
> I was just trying things to see what would happen, trying to guess and
> fill in the blanks about what may or may not be supported. The
> parameter I passed was a valid (though apparently unsupported)
> expression. If Tk scripts 'will never (ever) work,' this is a moot
> point and the documentation is in error.

Tk scripts *do* work (in build 28); they just don't work in the @TCL
function. You can run them from the command line, just as you do a Tcl
script. The documentation never says anything about running scripts in
@TCL, only expressions.

(You wouldn't really want a modal variable function that locked up
everything else in TCMD while a Tk script executed, would you?)

Rex Conn
JP Software

 

[TimButterfield]

Tk scripts *do* work (in build 28); they just don't work in the @TCL
function. You can run them from the command line, just as you do a Tcl
script. The documentation never says anything about running scripts in
@TCL, only expressions.

The documentation said @tcl supported Tcl/tk expressions. If not a script, what Tk expression is supported by @tcl? Perhaps the documentation should say it supports 'Tcl expression' and leave the Tk part out of it.

(You wouldn't really want a modal variable function that locked up
everything else in TCMD while a Tk script executed, would you?)

Given the 'documented' support for Tk, I would have expected 'set x=%@tcl[source test.tcl]' to act similarly to 'set x=%@execstr[wish test.tcl]' both of which would lock until the app exited. The expectation was not without precedent. I'll check again in 28.

Tim