Re: [lmi] wxProgressDialog resists interruption with Cancel

[Vadim Zeitlin]

On Thu, 14 Nov 2013 15:32:33 +0000 Greg Chicares <address@hidden> wrote:

GC> I should more clearly explain the scope and limits of my objective.
GC> 
GC> I don't dream of reaching through this chain:
GC>   wxExecute() --> CMD.EXE --> java --> fop
GC> to abort an external process. Once wxExecute() has been called to
GC> transform lmi data into a PDF file, I don't hope to interfere:
GC> that file is going to be written.
GC> 
GC> But I do want Cancel to mean "Don't call wxExecute() again".
GC> IOW: let any already-launched external process complete, but stop
GC> the loop so that no more are launched.

 OK, sorry for misunderstanding you. Of course, in this case the problem is
that it's supposed to work without any extra YieldFor() calls because
wxProgressDialog::Update() is called between the calls to wxExecute().

GC> >  IMO this would be the right thing to do here, synchronous wxExecute()
GC> > should only be used for (very) short-running child processes
GC> 
GC> Is a one-second process longer than you have in mind?

 I'd say it's the (acceptable) upper limit. The generally accepted numbers
for the maximally accepted delays are 0.1s for the immediate action
feedback, 1s for avoiding interrupting the user flow of thought and 10s for
keeping them from switching away from the program (see e.g.
http://www.nngroup.com/articles/response-times-3-important-limits/).


GC> Anyway, we're left with a puzzle: why does revision 5830 work?

 Right now I don't know, I'd need to debug this to understand what's going
on. Could you please explain to me what exactly should I do to see the
problem (of course, only if you want me to look into this further, if
you're happy with the current solution, there is no need for that)?


GC> The loop looks like this:
GC> 
GC>   wxProgressDialog progress(...);
GC>   for(i = 0; ...)
GC>     {
GC>     // calling YieldFor() on this line here is ineffective
GC>     do_something_within_lmi();       // step 1: takes ~0.75 seconds
GC>     call YieldFor(wxEVT_CATEGORY_UI) // step 2  (this works)
GC>     wxExecute(...);                  // step 3: takes ~1.00 seconds
GC>     progress.Update(...);            // step 4
GC>     }
GC> 
GC> It seems clear that a Cancel event issued during step 1 gets recognized
GC> in step 2; but without step 2, Cancel gets lost--it is not recognized in
GC> step 4. My hypothesis is that wxExecute() eats pending Cancel events.

 This seems like a reasonable explanation, except that I don't see at all
how could this happen (which doesn't mean that it doesn't, of course).
Perhaps wxExecute() actually _dispatches_ this event, instead of eating it,
while it runs -- but does this while the progress window is still disabled?
But I'm really just guessing at this point...

 Please let me know if you'd like me to look at this further, thanks,
VZ