(Sorry: replying to the wrong message here, but my newsreader somehow managed
to miss the former post...)
> On Mar 7, 9:40 am, Jani Hakala <jahak...@iki.fi> wrote:
>> > After reading the docs and seeing a few examples i think this should
>> > work ?
>> > Am I forgetting something here or am I doing something stupid ?
>> > Anyway I see my yellow screen, that has to count for something :)
>>
>> I have been using the following scheme:
>> - Pass the root object to the thread object when creating the object
>> - Define a event_handler: root.bind('<<SomeEvent>>', evt_handler) in
>> the main thread.
>>
>> - When the thread has done something that the GUI part should now
>> about, signal an event in the thread:
>> root.event_generate('<<SomeEvent>>') (no other arguments)
>>
>> - Call a method of the thread object in the event handler e.g. to get
>> some data from a queue object.
>>
>> This ensures that only the main thread accesses Tkinter-related things.
Are you sure about that? Last time I check, doing:
root.event_generate('<<SomeEvent>>')
without any other argument called the binding directly, in the context where
it is done, so in the secondary thread. To actually switch to the thread where
the bind was done, you had to do:
root.event_generate('<<SomeEvent>>', when='tail')
to force the event to get into the event queue... Maybe it has changed in the
latest tcl/tk version (I checked this quite a long time ago on tcl/tk 8.3).
BTW, with the newer tcl/tk versions this time, be sure to compile them with
thread support ('configure ... --enebale-threads' on Unices and 'nmake ...
OPTS=threads' on Windows) if you plan to do such things. We had a lot of
problems with this trick on a tcl/tk 8.5 version not compiled with thread
support, especially when a lot of events happened in a very short time:
crashes, weird errors apparently caused by memory corruption, and so on...
--
http://mail.python.org/mailman/listinfo/python-list
