>
> The real goal is to start the gui in a different thread, and have the
> main thread regain control. That seems like a feasible thing to be
> able to do, though I have been unsuccessful ... if anyone would like
> to suggest something without being covertly insulting, I'm all ears.
AFAIK some t
On 10/5/07, Shafik <[EMAIL PROTECTED]> wrote:
> My apologies for not supplying more info, I am at work and I am
> technically not allowed to surf the web for anything.
>
> I am using Python 2.5.1, the latest wx version (2.8.xx, I dont recall
> exactly). This is running under windows XP under the l
My apologies for not supplying more info, I am at work and I am
technically not allowed to surf the web for anything.
I am using Python 2.5.1, the latest wx version (2.8.xx, I dont recall
exactly). This is running under windows XP under the latest version of
cygwin (that could be the source of th
Since the observed behaviour is clearly undefined,
I forgive you for the poorly specified behaviour
description: asking for a close description of random
behaviour is just ridiculous.
The most obvious point is that wx is not re-entrant
or thread safe: you have to make it so by using
wx.CallAfter()
On 10/4/07, Shafik <[EMAIL PROTECTED]> wrote:
> Hello folks,
>
> I'm having an issue with mixing wxPython and threading ... I realize
> multi-threading always introduces subtle bugs, but the following
> scenario is just odd:
>
> I start a dummy thread, that does nothing but increment a counter and
Hello folks,
I'm having an issue with mixing wxPython and threading ... I realize
multi-threading always introduces subtle bugs, but the following
scenario is just odd:
I start a dummy thread, that does nothing but increment a counter and
print its value to the screen, then afterwards, I start th
