Skip to main content

Namespace export-import, aliases and rename

 
    Namespaces are really useful in Tcl as they permit commands and variables to be conveniently grouped together. This means that common command names can be reused within specific contexts, and that variables can be 'hidden' away from errant command calls. All this extra security does come at a cost, a lost of unecessary and respetative typing. Using the gnocl:: namespace prefix is useful if, lets say, there is a need for mixed Tcl and Gnocl programming. But, if there isn't this need what can be done to alleviate the typing burden, albeit with some risks when coming to readability and portability between applications? Variables and commands embedded within a namespace can undergo export-import process or they can be renamed.

The following code example shows how this can be done. When exporting and importing between namespaces its possible to have a naming conflict in the importing namespace. Tcl will pick this up and result in an error. Fortunately this only applies to a handful of instances and in most cases (e.g. list and listStore) command synonyms are built into the gnocl core.

 
# !/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

package require Gnocl

# what namespaces are present?
puts [namespace children ]

# export all gnocl command and widge names
namespace eval ::gnocl {
    namespace export application listStore button menu window
    foreach class [widgets] { namespace export $class }
    foreach class [commands] { namespace export $class}
}

foreach class [gnocl::widgets] {
    if { [catch { namespace import gnocl::$class } err] }  { puts WIDET-$err }
}

foreach class [gnocl::commands] {
    if { [catch { namespace import gnocl::$class } err] }  { puts COMMAND-$err}   
}

set x 200 ; set dx 400
set opts "-y 400 -width 300 -height 200"

# EXAMPLE 1) create app from and array
array set app [application]

$app(topLevel) show


set lst [listStore -columns 2 -types {string string}]
$lst add [list [list a b] [list b c] ]
$app(container) add $lst -fill 1 -expand 1
$app(topLevel) configure -x [incr x $dx] {*}$opts

# EXAMPLE 2) using aliass
interp alias {} g_window {} gnocl::window
g_window -child [gnocl::text] -x [incr x $dx] {*}$opts

# EXAMPLE 3) renaming commands
foreach class [gnocl::widgets] {
    rename gnocl::$class gcl::$class
}

gcl::window -child [gcl::button -text hello]  -x [incr x $dx] {*}$opts




Comments

Popular posts from this blog

gnocl::calendar

Given this module some attention today. Added some of the more package wide options to the module and created customised handler for setting the month. (For some odd reason months are are counted 0-11 whereas days are 1-31.) There's still a little more to do to this one including the addition of code to store diary details. Here's the working test script to show the range of options at work. The percentage substitution string item %e explores something that I've been toying with, the name of the signal/event that initiated the call. Ok, a script can keep its own internal trace but who knows, it might prove useful. #--------------- # calendarTest.tcl #--------------- # Author:   William J Giddings # Date:     07/05/09 #--------------- #!/bin/sh # the next line restarts using tclsh \ exec tclsh "$0" "$@" #--------------- package require Gnocl set cal [gnocl::calendar] $cal configure -day 8 -month 7 -year 1956 $cal configure -rowHeight 1 -colWidth 1 $ca

Simple Runtime Debugging Message Dialog

At times it's useful to see what values variables hold, or offer some pause point before the code goes elsewhere before causing havoc. Its possible to write output to the terminal but this can get lost in copious forms of other outputs, besides, there's no pausing the script execution either. The following proc creates a custom dialog which displays ad message along with the point in the calling script from which it was invoked. ## simple runtime debugging feedback dialog, alternative to console based gnocl::msg # @param msg message to display # @returns none # proc xxx::msg {txt} { set frame [info frame -1] append msg "Message:\n\n" append msg " $txt \n\n\n" append msg "Called from:\n\n" append msg "Proc:\t[lindex [info level -1] 0]\n" append msg "File:\t[file tail [dict get $frame file]]\n" append msg "Line:\t[dict get $frame line]\n" gnocl::dialog \ -type info \ -text $msg

Gnocl Dashboard

Over the past few programming sessions I've been working on producing a central point, a dashboard, around which it's possible to see the various Gnocl widgets and commands in operation. In many ways like the demo script which shipped with the earlier releases of Gnocl but offers much more. The introspection functionality provides details of the various options and sub-commands of each Gnocl procedure which are displayed under the associated tab. Sample scripts are included for each item which offers newcomers a clearer insight into how make the most of what's on offer.