Re: [lmi] wxProgressDialog resists interruption with Cancel

[Greg Chicares]

On 2013-11-16 22:54Z, Vadim Zeitlin wrote:
> On Sat, 16 Nov 2013 15:55:37 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2013-11-15 19:24Z, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  The important thing, however, is the other bug or, if you want, a
> GC> > peculiarity of wxMSW implementation. For a lot of complicated reasons,
> GC> > wxMSW creates a dialog window, positioned off screen, so it's never 
> visible
> GC> > to the user, while looping in wxExecute(wxEXEC_SYNC). And so any events,
> GC> > whether normal keyboard ones or mouse ones, such as are generated when
> GC> > clicking on the button, are actually sent to this hidden dialog and not 
> to
> GC> > the progress dialog, where they are simply ignored. So this is, just as 
> you
> GC> > surmised, the case of wxExecute() "eating" all the events, although it 
> does
> GC> > it in the rather indirect way. And, because of the previous bug, lets 
> Esc
> GC> > key events through.
> GC> 
> GC> Then isn't wxEXEC_NODISABLE the perfect solution?
> 
>  I'm a bit ashamed of not thinking about this one myself but you're right,
> this should indeed work (I didn't have time to test it myself though).

We'll take care of testing it. Committed as revision 5835.

> Usually using wxEXEC_NODISABLE would be a very dangerous idea, but as all
> the other windows are already disabled in this case, it is fine here.

lmi calls wxExecute() only through system_command(), which is used elsewhere.
As an example of a potentially dangerous operation, I tried:
  File | New | Illustration
  OK
  File | Print preview
Before it could spawn my PDF viewer, I immediately clicked the close button
on the illustration window. This is not something that an end user would do,
but it worked as expected.

Aside from invoking apache fop, system_command() is also used at startup--in
authenticate_system(), which DWISOTT. This continues to work fine AFAICT.
It's an interesting test, because it's called early in OnInit(), when there's
no top window, no statusbar, and perhaps not even an event loop; but it works.
(I noticed that some useful diagnostics weren't printed, so I fixed that in
revision 5836, which we'll also need to test here (in the US).)

> GC> >  Now that we understand what is going on, a more interesting question is
> GC> > what can we do. The minimal change I'd recommend would be to put
> GC> > reflect_progress() call before the call to wxExecute() and remove the
> GC> > explicit calls to YieldFor() from system_command_wx(), please see the
> GC> > minimal patch below [*].
> GC> 
> GC> I tested this; it doesn't work well in practice.
> 
>  This is strange, it did work for me. The only difference I can see is that
> I configured the fop command to actually be just "sleep 2" as I don't have
> fop installed here, but I don't see how could it change anything here.
> 
> GC> That example was overly simplified. What actually happens is this:
> GC> 
> GC>   wxProgressDialog progress(...);
> GC>   for(i = 0; ...)
> GC>     {
> GC>     // calling YieldFor() on this line here is ineffective
> GC> !   do_a_little_housekeeping();      // step 0: takes a few milliseconds
> GC> !   // calling Update here, as in your patch, is almost ineffective
> 
>  For me the calls here, i.e. run() + PlusEq() take noticeable amount of
> time (in the seconds range). I can measure it more precisely if necessary
> but it probably isn't, as wxEXEC_NODISABLE provides a solution in any case.

IIRC, you used a non-optimized debug build; that probably explains this. I
instrumented an optimized build with a nanosecond timer, and run() + PlusEq()
took only 57 milliseconds.

> GC> >  Another thing which would help would be, perhaps surprisingly, 
> upgrading
> GC> > to a newer MinGW version and running the program under Windows Vista or
> GC> > later. [...] Of course, this would only help users under Windows
> GC> > Vista and later, so if LMI is still used under XP, this isn't as
> GC> > interesting.
> GC> 
> GC> I'm using XP. I wouldn't be surprised if some end users in remote
> GC> offices are, too.
> 
>  Using a newer MinGW version with task dialog support would still improve
> the UI responsiveness for the people running under later Windows versions
> even if it doesn't change anything for the XP users, so it still might be
> worth doing...

Noted. But they don't care about the responsiveness of wxExecute(). In fact,
we just inserted a ten-second delay between files sent to the printer, and
they'll welcome that because it'll make their printouts come out in the
order they expect. If they have to print ten illustrations, they take a
coffee break; if a thousand, they go home.

If we wrote PDF files with a tool less balky than fop, they'd welcome that;
yet in that case we wouldn't be using wxExecute() at all. But that's a
discussion for another day.