Re: [lmi] wx-2.9.2: undesired change in behavior of MRU list

[Greg Chicares]

On 2011-07-19 12:37Z, Vadim Zeitlin wrote:
> On Tue, 19 Jul 2011 10:17:43 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> In 'illustration_view.cpp', IllustrationView::OnCreate() can return false 
> in
> GC> a situation that isn't actually an error--namely, when the user begins to 
> open
> GC> a file, and then cancels. With wx-2.9.2, this produces an unwanted effect 
> that
> GC> was not observed with earlier versions.
[...]
>  Without changes to wx the only possibility I see is to intercept all menu
> events corresponding to the MRU menu items and handle them in LMI itself,
> i.e. copy wxDocManager::DoOpenMRUFile() logic without the removing-file-
> from-MRU-if-it-failed-to-open part. I can make a patch doing this can be
> useful.

I don't think it's serious enough to justify throwaway work in lmi before 2.9.3 
.
It took me a few weeks to notice it.

>  So finally I think that we should modify wx to:
> 
> 1(a) Not remove the file from MRU if it just failed to open.
>  (b) Call a virtual function if a MRU file doesn't exist any longer. This
>      function would remove the file from MRU by default but could be
>      overridden to never do it or ask the user if he wans to do it.
> 
> Alternatively we could do
> 
> 2. Just always call some virtual function when the file from MRU couldn't
>    be opened, whether it was because it was not found or some other reason
>    (and pass the flag indicating its existence, or not, to this function).
> 
> (1) is somewhat simpler while (2) is maximally flexible -- but maybe too
> much so? What do you think?

Both those solutions would let me do exactly what I want, but I feel they're
special-purpose tweaks that tend to make wx too...well, rococo, so let's
think about what else could be done.

Any messagebox is obtrusive; is one really warranted here, or would it be
better to remain silent, whether or not the MRU entry is removed?

Removal from the MRU is desirable in some cases, but not in others, so is
there some way to choose the behavior in a virtual function that wouldn't
seem so odd? For instance, if we want the test to be
  if(!fexist(file))
    remove_from_mru(file);
then it might not be too unnatural to provide a virtual fexist() in the
doc-view or file-history class. Or an OnCreateFailure() virtual would
provide the hook we want here; that seems unremarkable, whereas an
OnFailureToOpenFromMRU() function seems awfully exotic.

wxView::OnCreate() returns bool. Should it instead return an enumerated
type that could include wxCREATION_CANCELLED_BY_USER, in which case the
file wouldn't be removed from the MRU?

Another idea: add a flag to control whether the file is removed from the
MRU, perhaps in the 'long flags' argument to wxView::OnCreate(), though
it might be better to add a 'flags' argument to the wxFileHistory ctor
for this purpose.