Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

binding activating toplevel window?

51 views
Skip to first unread message

Juge

unread,
Jul 17, 2015, 4:24:52 AM7/17/15
to
I have a Tcl-Program that interacts with another commercial application.
I would like to do a quick refresh on my app if I make changes on the main application. Normally this means that when I use the main application its window is active and my tcl program is not the topmost window anymore. Now I would like to call a proc when I return to my own GUI to check that the dialogues are still actual.

How can I bind this?

I have tried
bind . <Activate> { puts Activated}

here I get no reaction (I am mainly using Linux, but want my app to support Windows as well)

with
bind . <Visibility> { puts Activated}

I get reaction however it works only when window is obscured by another window so it's no go.

I also tried Button-1 but it causes no reaction if I click on title bar - only when I click on the GUI area so it does not necessarily capture the focus change.

I think Activate should be actually right but I just do not seem to get it right...

Alexandru

unread,
Jul 17, 2015, 5:22:42 AM7/17/15
to
I don't know if this is working but I would give it a try with the <FocusIn> binding.

Rich

unread,
Jul 17, 2015, 9:13:42 AM7/17/15
to
Did you read the documentation on Activate:

Activate, Deactivate
These two events are sent to every sub-window of a toplevel when
they change state. In addition to the focus Window, the Macintosh
platform and Windows platforms have a notion of an active window
(which often has but is not required to have the focus). On the
Macintosh, widgets in the active window have a different appearance
than widgets in deactive windows. The Activate event is sent to
all the sub-windows in a toplevel when it changes from being
deactive to active. Likewise, the Deactive event is sent when the
window's state changes from active to deactive. There are no
useful percent substitutions you would make when binding to these
events.

The events are "sent to every sub-window of a toplevel". The wording
literally says "not sent to the toplevel". Dot (.) is a toplevel. So
the docs say that . will not be sent an <Activate> event, which is why
your test did nothing.

Try binding on <Activate> on a sub-window of the dot (.) window. Or
try binding on <FocusIn> or <Enter> events on dot (.).

Juge

unread,
Jul 17, 2015, 9:35:12 AM7/17/15
to
Yes it works fine for me. I think it also launches an action when deactivating the window but that does not matter. Thanks!

Juge

unread,
Jul 23, 2015, 4:54:52 AM7/23/15
to
On Friday, July 17, 2015 at 3:13:42 PM UTC+2, Rich wrote:
FocusIn was just fine, for a start - now, however, I landed to another problem with a tablelist. When I start edit in the tablelist the FocusIn is also triggered - at the same time I have an action to delete table contents and actualize the contents. If I want to avoid this I think I need to check whether the content need update or just leave it be. Any other way of detecting if my guy window got activated simultaneosly to FocusIn
0 new messages