Hi again
(another question; it is so, I have collected that questions for some
weeks an post them now at once).
I have a MessageDialog (or Box).
then I press yes or now (i think, the messagedialog must be closed now,
(i also tried with close and destroy, but it didn't help)
... then a
subprocess with Popen is called (it takes some time to perform a
certain task)
SO: only then this POpen task is finished, then (not before that) the
messagedialog (-box) is closed.
(Additional Info: The pressed button in the dialog is seen the whole
time) Why isn't it closed immediatly after the user input?
Also seen on gtk
Hi again
(another question; it is so, I have collected that questions for some
weeks an post them now at once).
I have a MessageDialog (or Box).
then I press yes or now (i think, the messagedialog must be closed now,
(i also tried with close and destroy, but it didn't help)
... then a
subprocess with Popen is called (it takes some time to perform a
certain task)
SO: only then this POpen task is finished, then (not before that) the
messagedialog (-box) is closed.
(Additional Info: The pressed button in the dialog is seen the whole
time) Why isn't it closed immediatly after the user input?
Also seen on gtk
The actual closing and destruction of a dialog is implemented as a
message in most of the underlying frameworks. So when the dialog is
closed a message is sent and needs to be processed to do the actual
closing/destruction of the window object. If you are starting a long
blocking task in the same thread as the ui right after you call
Close/Destroy the system will not have been able to process the
message yet as the control flow will be blocked on your subprocess
call.
Hi again
(another question; it is so, I have collected that questions for some
weeks an post them now at once).
I have a MessageDialog (or Box).
then I press yes or now (i think, the messagedialog must be closed now,
(i also tried with close and destroy, but it didn't help)
... then a
subprocess with Popen is called (it takes some time to perform a
certain task)
SO: only then this POpen task is finished, then (not before that) the
messagedialog (-box) is closed.
(Additional Info: The pressed button in the dialog is seen the whole
time) Why isn't it closed immediatly after the user input?
Also seen on gtk
The actual closing and destruction of a dialog is implemented as a
message in most of the underlying frameworks. So when the dialog is
closed a message is sent and needs to be processed to do the actual
closing/destruction of the window object. If you are starting a long
blocking task in the same thread as the ui right after you call
Close/Destroy the system will not have been able to process the
message yet as the control flow will be blocked on your subprocess
call.
I see. Is there no way to force to quit the dialog before? Without a
thread?
The easy way is to have a nap after the dialog close or destroy call, so
gather the data from the dialog, close or destroy it then call
time.sleep(0.2) before starting your processing this will give the OS a 200
millisecond gap to catch up. You may have to play with the time a little
but your users are less likely to notice the pause than a hanging dialog
Gadget/Steve
Hello Gadget/Steve thank you for your interesting tip, but that does not
help either. No matter, if I set the time to 0,5 or 20 seconds.
After that I had another idea, and it works
wx.Yield() # not before now everything is updated
time.sleep(0.1)
wx.Yield()
I must call wx.Yield two times, else a gray field stay visible that
time.
I see. Is there no way to force to quit the dialog before? Without a
thread?
You could put the code to start/run the subprocess into a function,
then after calling Close/Destroy on the dialog use either CallAfter or
CallLater to start subprocess function. This way the events for
closing the dialog will get a chance to get handled and your long
blocking function wont' get called until a later iteration of the main
loop.
The easy way is to have a nap after the dialog close or destroy call, so
gather the data from the dialog, close or destroy it then call
time.sleep(0.2) before starting your processing this will give the OS a 200
millisecond gap to catch up. You may have to play with the time a little
but your users are less likely to notice the pause than a hanging dialog
This will cause exactly the same problem. sleep is a blocking call so
sleeping will block the control flow of the thread the same as the
subprocess call.
Cody
···
On Thu, Aug 5, 2010 at 2:12 AM, <GadgetSteve@live.co.uk> wrote:
I see. Is there no way to force to quit the dialog before? Without a
thread?
You could put the code to start/run the subprocess into a function,
then after calling Close/Destroy on the dialog use either CallAfter or
CallLater to start subprocess function. This way the events for
closing the dialog will get a chance to get handled and your long
blocking function wont' get called until a later iteration of the main
loop.
Thank you Cody, a good tip.
The easy way is to have a nap after the dialog close or destroy call, so
gather the data from the dialog, close or destroy it then call
time.sleep(0.2) before starting your processing this will give the OS a 200
millisecond gap to catch up. �You may have to play with the time a little
but your users are less likely to notice the pause than a hanging dialog
This will cause exactly the same problem. sleep is a blocking call so
sleeping will block the control flow of the thread the same as the
subprocess call.
But I have accomplished it that way. See my other posting.
wx.Yield()
time.sleep(0.1)
wx.Yield()
Its surely not the style, one should take by reading this.
···
On Thu, Aug 5, 2010 at 2:12 AM, <GadgetSteve@live.co.uk> wrote:
The easy way is to have a nap after the dialog close or destroy call, so
gather the data from the dialog, close or destroy it then call
time.sleep(0.2) before starting your processing this will give the OS a 200
millisecond gap to catch up. You may have to play with the time a little
but your users are less likely to notice the pause than a hanging dialog
This will cause exactly the same problem. sleep is a blocking call so
sleeping will block the control flow of the thread the same as the
subprocess call.
But I have accomplished it that way. See my other posting.
wx.Yield()
time.sleep(0.1)
wx.Yield()
Its surely not the style, one should take by reading this.
No this is quite different to just using sleep (though just the same
the above sleep will accomplish nothing but cause the thread it was
called from to hang for 0.1 seconds).
Yield will block and step into a nested event loop that will try to
empty out and dispatch any pending events that are in the applications
event queue. If used improperly this can lead to a recursive stack
overflow if the same event handler that the Yield is getting called
from gets called again as part of the events that the previous call is
dispatching. So some care is needed when using Yield.
Using CallAfter/CallLater to start your long running task
asynchronously to the scope of where you are closing the dialog would
be safer since it will just cause an event to get put at the back of
the queue after the dialog closing events and will allow the event
loop to continue its natural course and will start your long running
task when the event created by CallAfter/Later is processed.
Cody
···
On Thu, Aug 5, 2010 at 9:57 AM, FranzSt <franz.steinhaeusler@gmx.at> wrote:
[...]
No this is quite different to just using sleep (though just the same
the above sleep will accomplish nothing but cause the thread it was
called from to hang for 0.1 seconds).
Yield will block and step into a nested event loop that will try to
empty out and dispatch any pending events that are in the applications
event queue. If used improperly this can lead to a recursive stack
overflow if the same event handler that the Yield is getting called
from gets called again as part of the events that the previous call is
dispatching. So some care is needed when using Yield.
Using CallAfter/CallLater to start your long running task
asynchronously to the scope of where you are closing the dialog would
be safer since it will just cause an event to get put at the back of
the queue after the dialog closing events and will allow the event
loop to continue its natural course and will start your long running
task when the event created by CallAfter/Later is processed.
