Prev: subclassing a widget?
Next: Tiny url
From: tomk on 12 Jan 2010 11:12
kk,

If you want to modify tk widgets or combine tk widgets into mega
widgets then I would recommend you use the Snit package (it's a pure
tcl package). Here are some links to information on Snit.

http://docs.activestate.com/activetcl/8.5/tcllib/snit/snitfaq.html#section14
http://docs.activestate.com/activetcl/8.5/tcllib/snit/snit.html#8

The Snit package is one of the packages in the tcllib bundle which can
be downloaded at

https://sourceforge.net/projects/tcllib/

Tom K.
From: kk on 12 Jan 2010 15:49
On Jan 12, 4:12 am, tomk <krehbiel....(a)gmail.com> wrote:
> kk,
>
> If you want to modify tk widgets or combine tk widgets into mega
> widgets then I would recommend you use the Snit package (it's a pure
> tcl package). Here are some links to information on Snit.
>
> http://docs.activestate.com/activetcl/8.5/tcllib/snit/snitfaq.html#se...http://docs.activestate.com/activetcl/8.5/tcllib/snit/snit.html#8
>
> The Snit package is one of the packages in the tcllib bundle which can
> be downloaded at
>
> https://sourceforge.net/projects/tcllib/
>
> Tom K.

Thanks Tom, Pat and Arnd. Will be back for more!
From: Donal K. Fellows on 13 Jan 2010 05:22
On 12 Jan, 15:55, kk <girishbhat6...(a)gmail.com> wrote:
> A newbie to tcl/tk, but really excited about the elegance of the
> prefix notation. :)

There are a few other things to learn, as we'll see...

> Question: Is there anyway to do what is known as subclassing in MFC
> terminology?

There are ways, but that doesn't make it a good idea. If you're
subclassing to add to the Controller (using MVC terminology) then you
don't need to do that. Just add custom bindings. It only really makes
sense if you're changing the Model or the View, yet even with the View
it is easier to make minor adjustments without subclassing (through
changing configuration options for classic widgets or the style for
themed widgets). Do you really want to do change the Model? Or make
major updates to the the View? If so and as noted, there are ways; we
just want to confirm that this is what you *really* want as 99% of
uses (or more) don't need the complexity of subclassing...

> I can refer to the above specific button as .b. But can I put multiple
> instances of the above .b button in the same geometry manager?

No, since you have to give each instance a different name. But
otherwise that's trivial. :-)

> I should not have any problem putting them in different geometry
> managers right?

As long as you fix the naming issue, you can do anything you want.

> Can the code inside the -command find out the calling
> widget hierarchy?

No, but you can generate the command with knowledge of where it is
like this:

set w .b ;# Arbitrary legal name for a widget
button $w -text "mybutton" -command [list printMessage $w]
proc printMessage theWidgetName {
puts "Hello there from $theWidgetName"
}

With the widget name, you can discover everything else via the [winfo]
command. (Always use a procedure for doing the bulk of widget
callbacks; it's *hugely* easier to make it all work right first
time...) If you wanted to use many identikit buttons, you might do it
like this:

for {set i 1} {$i <= 5} {incr i} {
set w .b$i
button $w -text "mybutton" -command [list printMessage $w]
pack $w
}

(Those are all going in the same geometry manager, the packer attached
to the '.' widget. They're just getting added incrementally.)

> And is that the only soln? Namely wrap each button in a different
> manager before placing all the managers on the screen/widget

This indicates a misunderstanding somewhere, so hopefully my
explanations above will help. If not, keep asking!

Donal.
 | 
Pages: 1
Prev: subclassing a widget?
Next: Tiny url