What about internally wrapping commands, something like:
button .b -command "vTcl:cmd {%top.MyListbox insert end "item"}"
(of course you would not see the 'vTcl:cmd' stuff in visual Tcl but
it is how it would be stored in memory and saved in the project file)
vTcl:cmd would translate special macros such as:
%top
the actual toplevel path
%widget
the actual widget path
So this would allow easy copy/paste and, providing that you use these
macros, copying/pasting toplevels with aliases would still work. I am
thinking, too, you could use the toplevel name as a namespace to
store data for the window. For example:
set %top::some_data some_value
...
if { $%top::some_data == "some_text"} { ... }
CG
|--------+------------------------------------->
| | Rick Macdonald |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | eforge.net |
| | |
| | |
| | 03/30/2001 07:57 AM |
| | Please respond to vtcl-user|
| | |
|--------+------------------------------------->
>-----------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Fax to:
|
| Subject: Re: [vtcl-user] Several instances of toplevel
|
|
|
>-----------------------------------------------------------------------------------------------------------|
Yes, exactly. A few years ago I too started to change the hardwired .top17
to $base but realized that since I use aliases heavily (vTcl's "widgets"
array) it just wasn't going to work anyway. I never have tried to think it
through to come up with ideas on how to handle it. I just let it go when I
realized it wasn't simple. It may be that we'd have to access the %W
substitution variable for bound events, and manually pass this to callback
procs, etc.
Maybe iTcl makes this easier?
On Fri, 30 Mar 2001, Cristian Chaparro wrote:
> Thats right! I had the habit of creating the interface with vtcl and
editing
> the code afterwards... although I'm correcting this now with vtcl 1.5.1 :
-)
> I manually corrected the source and changed -command {.top...} by
-command
> "$base...". Actually in vtcl I declared the command for scrollbars as
being
> '$base.text.. yview' and afterwards just changed the {} into "'s. I'm
almost
> sure I got an error message stating that $base was an unknown variable,
but I
> ignored it and the command was put in the source anyhow. I had no menu's
on
> the toplevels so I did not see this.
> Looking into some 1.5.1 code I see this is corrected but still... what
> happens with aliasing in such a case? Do toplevels created like this get
an
> automatic alias, and if yes, how do I now what it is? Is it a recommended
> practise to instance copies of toplevels like this or should I avoid it?
>
> Cristian.
>
> Rick Macdonald wrote:
>
> > On Fri, 30 Mar 2001, Cristian Chaparro wrote:
> >
> > > Hi all,
> > > I have some code where I use different instances of one toplevel by
> > > calling
> > > Window show .top17 .top18
> > > Window show .top17
> > > Thus creating a toplevel .top18 based on the same code as .top17.
> > > I created this code with vtcl 1.2...
> >
> > Really? I thought that feature didn't work? Doesn't it generate some
> > hardwired references to ".top17" in the "proc vTclWindow.top17"? For
> > example, in menubuttons and scrollbars? Maybe it was fixed in a later
> > version?
> >
> > menubutton $base.fra34.cpd17.03 \
> > -anchor w -background grey85 \
> > -font -Adobe-Helvetica-Medium-R-Normal-*-*-120-*-*-*-*-*-* \
> > -foreground black -highlightbackground grey85 \
> > -menu .top17.fra34.cpd17.03.04 -padx 4 -pady 3 -text Edit
-width 4
> >
> > scrollbar $base.fra38.fra33.cpd18.02 \
> > -background grey85 -borderwidth 1 \
> > -command {.top17.fra38.fra33.cpd18.01 xview} \
> > -highlightbackground grey85 -highlightthickness 0 -orient horiz
\
> > -width 10
> >
> > ...RickM...
> >
> > _______________________________________________
> > vtcl-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/vtcl-user
> ���������������������������������������ǫ?��?x%?�o����ǫ�X������y�+?
��z�m�?��X������y�+?��z��?�l�X��)ߣ��r_�
>
...RickM...
_______________________________________________
vtcl-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/vtcl-user
_______________________________________________
vtcl-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/vtcl-user
