Re: [lmi] [lmi-commits] master 9bed27ea 1/2: Revert "Remove unnecessary variable from IllustrationView::OnCreate()"

[Greg Chicares]

On 6/16/22 13:21, Vadim Zeitlin wrote:
> On Thu, 16 Jun 2022 12:31:07 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 6/16/22 00:46, Vadim Zeitlin wrote:
> [...]
> GC> > However if we have to accept it even in this case, then I think the
> GC> > view should show something indicating that it's invalid -- maybe even
> GC> > the error message itself? -- as showing just a blank window doesn't
> GC> > seem very user-friendly.
> GC> 
> GC> We don't just show a blank 'view' window: we also show a
> GC> messagebox. If you're suggesting we copy the messagebox text
> GC> into the view,
> 
>  Personally I'd prefer showing the error only in the view, because I hate
> modal message boxes and find them infuriating as a user, but I know that
> you, if not love them, then don't see anything wrong with them, and so I
> was not even going to speak about replacing the message box and, indeed,
> was proposing only to show the same error in the view too.

These error messages belong in the dialog. Ideally, they'd all
appear there, and only there. I think we can agree on that point.

Given that (for whatever reasons) it's inconvenient to show them
in the dialog, the question is: where should we show them instead?

Today, we show them in messageboxes. Although users don't welcome
that, it's simple and it works.

Suppose we undertake to show them in the view. That's not simple.
The view is no longer just an MVC View: now it displays errors
from the Controller. Separation of concerns has been violated.
There are functions that write a View to a PDF file; should they
now write the text of the error message into the PDF file?
Then some end user who blithely ignores warnings will send that
PDF to a customer, who will be furious. It's far, far worse to
infuriate a customer than an end user.

Suppose, instead, that we intercept the attempt to write the
error-message-bearing View. Then we need to add superstructure
to maintain an error state for the View, and construct links
to other code that can print to a PDF, to a printer, etc.

Now suppose we've done all that, and the user corrects the
erroneous input. Then we need to add code to remove the error
message that we had intruded into the view. If it's not
flawless, then a customer might get an otherwise valid PDF
file that contains a stray error message, like
  "-1000 is too low: 0 is the lower limit."

Those are just a few thoughts that occur to me immediately.
Long experience tells me that there'd be many other issues.

Then, the same users who disliked messageboxes could
legitimately complain that, where we had two channels for
error messages:
 - the dialog's static text control
 - messageboxes
we've now added a third, and actually made things worse.

And if we ever decide to address the root cause, we have to
spend time undoing the inferior workaround that it had seemed
expedient to introduce.

> GC> I'd be firmly opposed: we shouldn't spend time
> GC> and effort duplicating information that's already provided
> 
>  I promise I won't argue after this,

I'll make the same pledge.

> but as you had written yourself in one
> of the previous messages, the problem is that once the message box is
> closed the information is not provided any longer.

Simple:
  Ctrl-E
  OK
Now the messagebox that you improvidently closed reappears.