top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

What is the difference between the window name and the widget command?

+1 vote
403 views
What is the difference between the window name and the widget command?
posted May 15, 2014 by Anshika Utadi

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

With vanilla Tcl/Tk, the widget access command is the same as the window name. If you create a button named ".b", then you use the command ".b" to access it.

With namespaces, this is not necessarily true. If a widget is created within a namespace, then its access command is protected by the namespace. Within the namespace, the access command is indeed the same as the window name. Outside of the namespace, however, you should use the complete namespace path to access the widget:

 namespace foo {
        label .x -text "X"
        .x configure -background red
    }
    foo::.x configure -relief raised

You can still use the window name ".x" as an argument to other Tk commands, regardless of the namespace context:

  namespace foo {
        set w [winfo width .x]
    }
    set w [winfo width .x]

    pack .x
    destroy .x

The namespace qualifiers are only needed in conjunction with the widget access command, which is always the first word on a command line.

Many existing Tk applications assume that the window name can be used as the access command. If the usual namespace rules described above were strictly enforced, many existing applications would break. For this reason, there is a "backward compatibility" mode in [incr Tcl] that makes the distinction between the window name and the access command much less of a problem. If an unknown command is recognized as a Tk widget, the unknown procedure automatically uses winfo command to find the access command for the widget. With the "backward compatibility" mode, the following code still works:

namespace foo {
    label .x -text "X"
    .x configure -background red
}
.x configure -relief raised

Although this works, execution is a little slower. In general, the following guidelines should be followed when using widgets within namespaces:

  • When a widget is created within a namespace, it is a signal that the widget is meant to be protected by the namespace. The widget should not be accessed directly outside of the namespace.
  • In bindings, the %q field should be used instead of %W as the widget access access command.
  • If a widget is meant to be generally available, it should be created in the global namespace. This can be accomplished from within a namespace like this:

    namespace foo {
        uplevel #0 button .b -text "Push Me"
    }
    

    or like this:

    namespace foo {
    button .b -text "Push Me"
    rename .b ::.b
    }

Library procedures can be written to operate on any window using the winfo command query.

answer May 16, 2014 by Aastha Joshi
Similar Questions
+2 votes

We develop embedded software for 32-bit micros using Windows as the development platform.

We are seeking a general purpose scripting language to automate certain tasks, like cleaning out certain directories of certain types of files in preparation for ZIP'ing, generating certain source files automatically, etc.

Selection criteria:

a)Should be able to compile the script interpreter as a monolithic executable (no .DLL dependencies, etc.) for easy versioning and distribution of the script interpreter. (Note that I'm not asking that the script be a single executable, just the interpreter. To run a script you'd need both the script and the interpreter. The script would be a text file, and the interpreter would be a single .EXE.)

b)Should be extensible, in that one could add commands or library functions to the script interpreter in C (for efficiency), and the whole script interpreter could again consist of a single executable with no other dependencies. (Note that I'm not asking that the script be a single executable, just the interpreter. To run a script you'd need both the script and the interpreter. The script would be a text file, and the interpreter would be a single .EXE.)

c)Should be able to spawn compilers and capture the output, do file I/O, and all the other minor expected stuff.

d)Graphical capability would be nice.

I know that Tcl/Tk would do all of the above, but what about Python or any other alternatives?

...