Re: Exitfield
Scott Raney wrote: > But if you ask me, doing validation on closeField is bad technique and > results in abominations like the MacOS "memory" dialog box (where you > usually end up with an error message when trying to increase the > partition because it focuses the "minimum" field before the > "preferred" field, one of my top 10 examples of bad UI design, > dragging a disk to the trash to eject being #1 on that list). > Instead, I'd recommend doing validation on the entire form just before > going to another one. Easier for you for you to develop, and easier > and more convenient for the user. The Memory control panel is indeed an abomination, but only because it chooses a validation form that conflicts with the form's overall needs. But this exception aside, there is a good argument for the immediacy of notifying users of errors in context. -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 1.7: Publish your database on the Web ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Exitfield
At 11:26 am -0600 20/10/01, Scott Raney wrote: >On Fri, 19 Oct 2001 "Raymond E. Griffith" <[EMAIL PROTECTED]> wrote: >Note that if you do "go card x", you *will* end up on card x, >regardless of what the closeField or exitField handlers do. If you >want to force the field validation to occur before the "go" is >executed, you'll need to focus some other control and then check some >sort of status variable or property to see if the check succeeded >before doing the "go". The command "focus me" in a button script is >the easiest way to do the first part, but you're on your own for the >status variable part. > >But if you ask me, doing validation on closeField is bad technique and >results in abominations like the MacOS "memory" dialog box (where you >usually end up with an error message when trying to increase the >partition because it focuses the "minimum" field before the >"preferred" field, one of my top 10 examples of bad UI design, >dragging a disk to the trash to eject being #1 on that list). Careful, Scott. You're starting to sound like those "UI experts" on the slashdot forum. Illogical design doesn't necesarily mean bad design. How quickly people get accustomed to something may be a better criterion. Despite having a "logical" alternative, most Mac users drag disks to the trash from day 1, and very few grumble about it. >Instead, I'd recommend doing validation on the entire form just before >going to another one. Easier for you for you to develop, and easier >and more convenient for the user. For a simple form, perhaps. But imagine a form with umpteen date entries requiring a particular date format. A user wouldn't be too happy after entering a load of dates only to be told they need to use a different format. I've generally opted for validation with closeField and a further check in the navigation button before closing the card. But where two fields depend on each other, you're probably right that it's best to wait. Cheers Dave Cragg PS My own #1 example of bad UI design are settings dialogs that have a close box in the title bar. It's never clear whether clicking the close box will ignore the new entries or accept them. OK and Cancel buttons should be the only ways out of such windows. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Re: Exitfield
On Fri, 19 Oct 2001 "Raymond E. Griffith" <[EMAIL PROTECTED]> wrote: > I have discovered something that, while not a bug, has proved to be > inconvenient. > > I have in certain fields on a card an exitfield handler. The problem comes > when going to the next card. > > The problem occurs when I click on a button that checks out whether certain > fields have been filled in. It makes the determination. If a field is not > filled in, it stops the process of going to the next card. If all required > fields are filled in, then I go to the next card. > > But I receive an error message. The exitfield handler in a field (the > unlocked field with the lowest layer) appears to be activated by going to > the next card. What is worse is that the exitfield handler is being handled > *after* going to the next card, so MC has its references mixed up. > > Generally speaking, I would expect all exitfield or closefield handlers to > be handled before the card closes. They are, at least in my testing: The closeCard message *is* sent after the closeField message. > If anyone has a light on the situation, I would appreciate it. Note that if you do "go card x", you *will* end up on card x, regardless of what the closeField or exitField handlers do. If you want to force the field validation to occur before the "go" is executed, you'll need to focus some other control and then check some sort of status variable or property to see if the check succeeded before doing the "go". The command "focus me" in a button script is the easiest way to do the first part, but you're on your own for the status variable part. But if you ask me, doing validation on closeField is bad technique and results in abominations like the MacOS "memory" dialog box (where you usually end up with an error message when trying to increase the partition because it focuses the "minimum" field before the "preferred" field, one of my top 10 examples of bad UI design, dragging a disk to the trash to eject being #1 on that list). Instead, I'd recommend doing validation on the entire form just before going to another one. Easier for you for you to develop, and easier and more convenient for the user. Regards, Scott > Thanks, > > Raymond Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
Exitfield
I have discovered something that, while not a bug, has proved to be inconvenient. I have in certain fields on a card an exitfield handler. The problem comes when going to the next card. The problem occurs when I click on a button that checks out whether certain fields have been filled in. It makes the determination. If a field is not filled in, it stops the process of going to the next card. If all required fields are filled in, then I go to the next card. But I receive an error message. The exitfield handler in a field (the unlocked field with the lowest layer) appears to be activated by going to the next card. What is worse is that the exitfield handler is being handled *after* going to the next card, so MC has its references mixed up. Generally speaking, I would expect all exitfield or closefield handlers to be handled before the card closes. If anyone has a light on the situation, I would appreciate it. Thanks, Raymond Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to <[EMAIL PROTECTED]>, not this list.
