Windows focus and multiple proc
Fernando Quinones
I have to start saying that TCL has open a new world for me, from
launching simple programs to automation. I am a beginner and like to
learn by examples better than by reading a book, so please bear with me.
Now to my questions..
1. I have a parent window that launch a child window from a proc. The
behavior that I want in this window is that when the focus is on either
window both of them will be at the top. Right now if I have the parent
window on focus my child window might be minimized or under 5 windows.
So basically I want to have both on top, no matter if the focus is on
the child or the parent. Now if this can’t be done I will probably have
to assign a number to the parent window title and have that same number
on the child window title. What is the best way to do this? Use the
process id number? How? The problem I have is that I might have to open
3 or 4 of this windows at a time and it is very hard to identify which
child windows belongs to what parent window.
2. I have a automation script in which I have multiple proc. Now all
these proc have the same information on it:
proc ticket {} {
echo ticket
}
proc load {} {
echo load
}
And it goes like that for about 11 items. So I figure it out that I
could just do:
set screen_names “ ticket load pillow bat ball”
foreach screen $screen_names {
proc $screen {} {
global screen
echo screen
}
}
If I try to launch any proc all I get executed is the proc which name is
the last on the “set screens names” line. How can I define all those
proc with out having to actually type the complete 11 proc?
3. The same problem as before, now what I want to do is define another
bunch of proc that have paired names. Like ticket is the proc and apples
if the related item, load is the proc and floppy is the related item,
and on and on for about 12 times.
proc ticket {} {
echo apples
}
proc load {} {
echo floppy
}
How can I do that....
Any help will be greatly appreciated.
Fernando Quiñones
Cameron Laird
Fernando Quinones <fern...@carolina.rr.com> wrote:
.
.
.
>2. I have a automation script in which I have multiple proc. Now all
>these proc have the same information on it:
>
>proc ticket {} {
>echo ticket
>}
>
>proc load {} {
>echo load
>}
>
>And it goes like that for about 11 items. So I figure it out that I
>could just do:
>
>set screen_names “ ticket load pillow bat ball”
>
>foreach screen $screen_names {
>
>proc $screen {} {
>global screen
>echo screen
> }
> }
>
>If I try to launch any proc all I get executed is the proc which name is
>the last on the “set screens names” line. How can I define all those
>proc with out having to actually type the complete 11 proc?
.
.
Is
proc $screen {} "
"
}
what you're after?
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Cameron Laird
>could just do:
>
>set screen_names “ ticket load pillow bat ball”
>
>foreach screen $screen_names {
>
>proc $screen {} {
>global screen
>echo screen
> }
> }
>
>If I try to launch any proc all I get executed is the proc which name is
>the last on the “set screens names” line. How can I define all those
>proc with out having to actually type the complete 11 proc?
>
>3. The same problem as before, now what I want to do is define another
>bunch of proc that have paired names. Like ticket is the proc and apples
>if the related item, load is the proc and floppy is the related item,
>and on and on for about 12 times.
>
>proc ticket {} {
>echo apples
>}
>
>proc load {} {
>echo floppy
>}
.
.
foreach {proc item} {ticket apples load floppy} {
proc $proc {} "echo $item"
}
What you might enjoy more, though, is something like this:
set item(ticket) apples
set item(load) floppy
...
foreach key [array names item] {
proc $key {} "echo $item($key)"
Fernando Quinones
> .
> .
> Is
> foreach screen $screen_names {
> proc $screen {} "
> echo $screen
> "
> }
> what you're after?
> --
>
> Cameron Laird <Cam...@Lairds.com>
> Business: http://www.Phaseit.net
> Personal: http://starbase.neosoft.com/~claird/home.html
Cameron,
Glad to hear from you again. Well what i am after is to save myself some
typing and make it easy to add proc to thei script.
Probably you remember the button pad that I was trying to make some months
ago, well this thing have grown bigtime. The combination of expectk, and tk
is killer!!!. I just wish I knew more, time will take care of that.
This group is very helpful...
Fernando...
Cameron Laird
I began:
.
.
What I meant to conclude was that the *really* interesting way
to do this, if you're just after a bunch of simple commands
accessible to your users, is to make an associative array as
above, and, rather than define lots of [proc]s, let [unknown]
resolve everything. <URL: http://wiki.tcl.tk/unknown > ex-
plains more.
Fernando Quinones
> What I meant to conclude was that the *really* interesting way
> to do this, if you're just after a bunch of simple commands
> accessible to your users, is to make an associative array as
> above, and, rather than define lots of [proc]s, let [unknown]
> resolve everything. <URL: http://wiki.tcl.tk/unknown > ex-
> plains more.
> --
>
> Cameron Laird <Cam...@Lairds.com>
> Business: http://www.Phaseit.net
> Personal: http://starbase.neosoft.com/~claird/home.html
Cameron,
Sorry I misunderstood you. My English is not too good, as you probably have figured
it out already. Anyway, I probably should have give a little more background on
what I am doing. I use a script to launch a telnet session, that script also have a
proc to launch a button pad to interact with the telnet. I am naming multiples proc
on that script to do different things on the telnet session. Basically these proc
are a bundle of commands and control codes specific for this application, that way
intead of remembering all this commands and control codes all my users need to do
is click a button on the button pad. Some of these proc have the same name of the
command that will be sent. That is why I rather have a list of 11 commands and use
some sort of a lop to automatically define those procs and the command. Now I tried
your example and it will not work for me if I am trying the commands, it does fine
if all I am doing is echoing text. Probably I should have place a more real example
of what I am trying to do. So these are my real procs and my actual try to make the
loop. This is not the complete script, since it is over 1000 lines but is the part
that we need, I think:
proc ticket {} {
exp_send "\033\[26~"
expect "jump to"
exp_send "nma_ticket"
exp_send "\033\[26~"
}
proc monitor {} {
exp_send "\033\[26~"
expect "jump to"
exp_send "nma_monitor"
exp_send "\033\[26~"
}
proc browse {} {
exp_send "\033\[26~"
expect "jump to"
exp_send "nma_browse"
exp_send "\033\[26~"
}
proc alarm_scan {} {
exp_send "\033\[26~"
expect "jump to"
exp_send "nma_alarm_scan"
exp_send "\033\[26~"
}
This is what I tried to replace the above:
set screen_names "ticket monitor browse alarm_scan"
foreach screen $screen_names {
proc $screen {} "
exp_send "\033\[26~"
expect "jump to"
exp_send "nma_screen"
exp_send "\033\[26~"
"
}
The script exit and I get this error:
Error in startup script: extra characters after close-quote
while compiling
"proc $screen {} "..."s
("foreach" body line 2)
invoked from within
"foreach screen $screen_names {
proc $screen {} "
exp_send "\033\[26~"
expect "jump to"
exp_send "nma_$screen"
exp_..."
(file "/tnmhome/gwyrtmc/bin/menu/nma_log_ticket_new.exp" line 681)
Probably the "" on the exp_send and expect line are messing this up so I tried:
set screen_names "ticket monitor browse alarm_scan"
foreach screen $screen_names {
proc $screen {} "
exp_send \033\[26~
expect jump ;# I rather have the "jump to" since is
more accurate
exp_send nma_$screen
exp_send \033\[26~
"
}
If I click any of the others procs I have on the script they work ok but I get the
following message when I click on any of the buttons that call the proc defined on
the "set screen_name" line:
Error on tcl Script
Error: missing
Close-bracket
Now if I used your exact example I get no error!
Any help?
Fernando Quinones
--
Nandy
http://home.carolina.rr.com/fernandoquinones/
Cameron Laird
.
.
I think I'd do this:
proc atom {keyword phrase} {
exp_send "\033\[26~"
expect $phrase
exp_send "nma_$keyword"
exp_send "\033\[26~"
}
foreach {keyword phrase} {
ticket ticket
monitor "jump to"
browse browse
alarm_scan alarm_scan
} {
proc $keyword {} [list atom $keyword $phrase]
}
OK, actually the idea of using [unknown] continues to intrigue
me, but this should get you going for now.
Cameron Laird
Fernando Quinones <fern...@carolina.rr.com> wrote:
>Hello group:
>
>I have to start saying that TCL has open a new world for me, from
>launching simple programs to automation. I am a beginner and like to
>learn by examples better than by reading a book, so please bear with me.
>Now to my questions..
>
>1. I have a parent window that launch a child window from a proc. The
>behavior that I want in this window is that when the focus is on either
>window both of them will be at the top. Right now if I have the parent
>window on focus my child window might be minimized or under 5 windows.
>So basically I want to have both on top, no matter if the focus is on
>the child or the parent. Now if this can’t be done I will probably have
>to assign a number to the parent window title and have that same number
>on the child window title. What is the best way to do this? Use the
>process id number? How? The problem I have is that I might have to open
>3 or 4 of this windows at a time and it is very hard to identify which
>child windows belongs to what parent window.
.
.
Other people know this far better than I.
Start with
proc all_top_levels {} {
set list .
foreach child [winfo children .] {
if {-1 == [lsearch $list $child]} {
lappend $list $child
}
}
return $list
}
Anyone know of a better way to write this, in the absence of
8.4a4's [wm stackorder ...]?
Next up:
proc raise_all {} {
set focus [focus]
foreach toplevel [all_top_levels] {
if [string compare normal [wm state $toplevel] {
wm deiconify [$toplevel]
}
raise $toplevel
}
focus $focus
}
This doesn't preserve stacking order, although it leaves focus
invariant. I don't know how to get at stacking order, before
8.4a4. Its action *is* idempotent, though, so I don't think it
has any severely annoying GUI consequences.
I *think* you should only need
bind . <Visibility> raise_all
or something with a conditional, but <Visibility> apparently doesn't
do what one wants under Windows. I got closer with
bind . <Any-Enter> raise_all
bind . <Any-Leave> raise_all
I welcome correction. I have a lot to learn about windowing events.
Cameron Laird
I advised:
>In article <3CD4095A...@bellsouth.com>,
>Fernando Quinones <fern...@carolina.rr.com> wrote:
> .
> .
> .
> proc atom {keyword phrase} {
> exp_send "\033\[26~"
> expect $phrase
> exp_send "nma_$keyword"
> exp_send "\033\[26~"
> }
> foreach {keyword phrase} {
> ticket ticket
> monitor "jump to"
> browse browse
> alarm_scan alarm_scan
> } {
> proc $keyword {} [list atom $keyword $phrase]
> }
>OK, actually the idea of using [unknown] continues to intrigue
>me, but this should get you going for now.
.
.
This was bogus.
That is, I believe there's a far simpler solution for
what Fernando *really* wants.
I conclude that from an abstract principle: whenever
application programmers use [eval] (with one exception),
create [proc]s dynamically, or use most of the [info]
subcommands, there is a simpler implementation lurking
nearby.
I suspect this is what's happening in the current case:
Fernando writes his buttons as
button .mybutton1 -text "Push me" -command ticket
then correctly observes this leaves him with the problem
of defining [ticket]. He's right; the fragments above
properly define [ticket], [browse], and so on.
HOWEVER, it would be better all around to write
button .mybutton1 -text "Push me" -command {
atom ticket ticket
}
and so on. In fact, he's likely to parametrize this:
foreach {keyword phrase} $big_configuration_list {
button .buttons.$keyword -text $phrase -command {
atom $keyword $phrase
}
}
Fernando, are we making progress?
marc Thirion
cla...@starbase.neosoft.com (Cameron Laird) writes:
> foreach {keyword phrase} $big_configuration_list {
> button .buttons.$keyword -text $phrase -command {
> atom $keyword $phrase
> }
button .buttons.$keyword -text $phrase -command \
[list atom $keyword $phrase]
> }
--
Marc Thirion | Ramonville Saint-Agne, France
Projet Internet et Citoyenneté : http://www.le-pic.org/
Marc.T...@ISOscope.com : http://www.ISOscope.com/
Pérennité des logiciels et des systèmes
Cameron Laird
marc Thirion <thi...@mipnet.fr> wrote:
>In article <D829ED7D1D437BB7.74089E70...@lp.airnews.net>,
> cla...@starbase.neosoft.com (Cameron Laird) writes:
>
>> foreach {keyword phrase} $big_configuration_list {
>> button .buttons.$keyword -text $phrase -command {
>> atom $keyword $phrase
>> }
>
> button .buttons.$keyword -text $phrase -command \
> [list atom $keyword $phrase]
>
>> }
.
.
Vous avez raison!
Why *did* I blunder so ...?
Richard Suchenwirth
<D829ED7D1D437BB7.74089E70...@lp.airnews.net>,
cla...@starbase.neosoft.com (Cameron Laird) writes:
> foreach {keyword phrase} $big_configuration_list {
> button .buttons.$keyword -text $phrase -command {...
A note on robustness: widgets names may be just about any string, but _not_
begin with an uppercase letter. When I generate widget names like this, I
therefore prepend a lowercase letter just to make sure:
foreach {keyword phrase} $big_configuration_list {
button .buttons.b$keyword -text $phrase -command {...
--
Best regards, Richard Suchenwirth
Donal K. Fellows
> I think I'd do this:
> proc atom {keyword phrase} {
> exp_send "\033\[26~"
> expect $phrase
> exp_send "nma_$keyword"
> exp_send "\033\[26~"
> }
That's wrong according to the spec, you know... :^)
> foreach {keyword phrase} {
> ticket ticket
> monitor "jump to"
> browse browse
> alarm_scan alarm_scan
> } {
> proc $keyword {} [list atom $keyword $phrase]
> }
I'm a big fan of interpreter aliases for this sort of thing:
proc telnet_interact {keyword} {
exp_send "\033\[26~"
expect $phrase
exp_send $keyword
exp_send "\033\[26~"
}
foreach {keyword phrase} {ticket monitor browse alarm_scan} {
interp alias {} $keyword {} telnet_interact nma_$keyword
}
However, this gets particularly neat once you get into creating lots of
templated procedures that take arguments because you can make the bits that
change between procs into leading arguments to your common implementation (which
is actually one of the things [interp alias] is designed to do...)
On a slightly different point, I would (as part of the business of writing code
to be virtually self-documenting) actually do the above like this:
proc make_interactor {keyword} {
interp alias {} $keyword {} telnet_interact nma_$keyword
}
make_interactor ticket
make_interactor monitor
make_interactor browse
make_interactor alarm_scan
Shorter? No. Faster? Probably not. Clearer? Well, *I* think so...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- Short attention span since- ooh! Shiny thing on the floor!
-- Chad R. Orzel <orz...@earthlink.net>
Donal K. Fellows
> I *think* you should only need
> bind . <Visibility> raise_all
> or something with a conditional, but <Visibility> apparently doesn't
> do what one wants under Windows.
Maybe also watch <Circulate> events? (And it wouldn't surprise me if that is
yet another kind of event that Windows cannot deliver, alas...) Oh, and when
watching for <Visibility>, be aware that you also get told when windows become
completely unobscured, which is probably not a good time to be doing lots of
raising of everything. Watch out for those detail fields.
Fernando Quinones
been swamp!!! I am reading all your responses and will give them a try next week at
work if things are not as hectic as this week.
Thanks for all the help.
Fernando
PS - Cameron, yes we are making progress, every time I get in this news group I
make progress!
Fernando Quinones
the script for the focus. I will try to work on that before going on vacation.
Thanks everybody,
Fernando