Re: [lmi] Untimely "save" dialog [Was: wxmsw-2.9.0 regression: crash when a messagebox should appear]

[Greg Chicares]

[Here I reply to the parts I hadn't replied to yet. Making sure I
give an answer to every point makes it more likely that someone will
notice any flaw in my thinking.]

On 2009-03-09 20:23Z, Vadim Zeitlin wrote:
> On Mon, 09 Mar 2009 13:55:43 +0000 Greg Chicares <address@hidden> wrote:
> 
>  However the prompt still arises in the case when an error happens during
> the document opening. I am however not sure if this is a problem at all in

I don't think it is a problem, at least not since 20090314T0432Z HEAD.

> this case: after all, the user did enter some data which you don't want to
> lose (this is the reason for calling Modify(true) in the first place) so

We no longer call Modify(true) there. AFAICT, the modification flag is
now handled correctly in all cases.

> maybe he should be given the possibility to save the .ill file even if
> opening it failed? I'd like to hear your opinion about this. If you think
> this is useful we should do at least 2 things:

Yes, that's useful.

> 1. Show the error message before the prompt for saving the file (as it's
>    very confusing otherwise)

That is now the behavior. It was indeed confusing previously.

> 2. Remove the "Cancel" button from the dialog as closing the view can't
>    be cancelled in this case

I believe that is now unnecessary. Now, IllustrationView::OnCreate()
returns 'true' iff a view has been created. If 'true', then the view
exists, and "Cancel" works correctly. If 'false', then no view exists,
and none ever did; returning 'false' to wx was correct, so there's
no problem. (Returning 'false' to wx when a view did exist was a
real problem.)

> And if you don't think this is useful we need to decide whether it might
> still be useful in some other situations, in which case the dirty flag
> would need to be reset in LMI itself, or whether it can never be useful at
> all in which case it would make sense to handle this at wx level.

I now think I was wrong to look for any solution in wx when the
problem AFAICT was in lmi. IOW, lmi should be robust enough
that it doesn't care what wx does about escaping exceptions.

> GC> Click "OK". An MDI child window has opened; it has no apparent
> GC> content, and its title is still "Loading document...".
> 
>  This is fixed by http://trac.wxwidgets.org/changeset/59455: now the window
> is closed if the view creation fails.

That's fine with me. The problem was that previously lmi could tell
wx (via the OnCreate() return code) that view creation had failed
when it actually didn't fail: what failed was a later step after
the view had been created. That problem has been removed from lmi.

> Notice that an alternative could be to move Run() inside try/catch clause
> instead but it seems inconsistent to catch only some exceptions and not all
> of them, even if now (i.e. with my latest changes to wx) catching them or
> letting them escape shouldn't change the observable behaviour.

lmi HEAD consistently traps all plausible exceptions in OnCreate().

I'm not planning to try to prevent every possible lmi exception,
everywhere, from escaping: too much work to solve no observable
problem I know of.

>  The only situation when it might be better to move Run() inside the
> try/catch clause would be if we decide to keep the save prompt.

I've moved everything that I suppose could fail inside the try-block.
Now, the 'save' prompt occurs only when the view is closed, as is
proper. No untimely 'save' prompt occurs any longer AFAICT.