On Mon, 30 Aug 1999, Ruediger zu Dohna wrote:
> Claude Lemmel wrote:
> >I need to check the datas entered in these field. I perform this
> >check "on closeField".
>
> Scott Raney answered:
> >The basic problem is that doing data validation checks on closeField
> >is a bad technique in general. There are too many ways (like this
> >one) that you can get screwed up.
>
> Not if you could stop the mouseUp or whatever message to be sent.
> HyperCard did that when you did an exit to HyperCard.
Actually you probably can do this with the flushEvents function.
> >It's also very frustrating to the user because they may want to fill
> >out the form in an order different than you had envisioned. For
> >example, I curse Apple every time I try to change the partition size
> >of a MacOS app by setting the "minimim size" and it opens a dialog
> >telling me I can't set the minimim size larger than the recommended
> >size. I want it to let me set them both, then tell me if I got it
> >wrong when I close the dialog
>
> This is a completely different matter! And what message would you
> call then? closeCard has exactly the same problem.
Whatever message initiated the card change. The only cases were you
don't actually have to script the card changes are if the user closes
the stack in which case you can use the closeStackRequest message to
do this, or with arrow keys, which you can just handle and not pass.
> >(probably even better would be if it would just change the preferred
> >size if I set the minimum size too big).
>
> ... which you would do in a closeField handler.
Possibly. You might want to explicitly notify the user about the fact
that you'd done it, though. I don't mind a dialog opening so much as
the fact that it undoes your changes.
> >So, what you should do instead is create a "validateFields"
> >function, and call it before doing anything that would close the
> >current card. If validation fails, select the text of the offending
> >field and return false. If the function returns false, abort the
> >card-closing
>
> Anything?!? There can be quite a number of ways to leave a card. And
> some may be generic like the navigation palette. I can see several
> alternatives:
No real application is going to use the navigation palette unmodified.
> 1. "exit to MetaCard" cancels any messages that would be sent. This
> could break some existing stacks.
>
> 2. A new "exit all" or similar command.
I don't like either of these. Throwing away all pending messages
should be something you have to do explicitly (as with flushEvents).
> 3. A "closeFieldRequest" and a "closeCardRequest" messages that
> behave analoguous to the "closeStackRequest" message, i.e. they
> cancel everything when not passed.
>
> Propably the last option is the most metacardish.
It is certainly the best of that lot. But I still can't think of any
applications where you'd have to trap more than a few messages to get
equivalent behavior, so this would be at best a minor convenience.
Regards,
Scott
> Regards
> R�diger
> --------------------------------------------------------------------
> | Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
> | PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
> --------------------------------------------------------------------
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
