|
|
|
This is an important usability issue as the current behavior results in mystery meat validation errors that require additional user effort to decipher.
I've written in more detail about this issue on the following blog post: http://aralbalkan.com/1125 The workaround suggested above is better, but ideally the validation errors should display continuously and you should be able to see multiple validation errors at the same time. I've attached a screenshot, from the blog post above, demonstrating this. Mystery meat validation errors. This is how validation errors currently look in Flex.
Screenshot taken from my Validating Data Quick Start (http://www.adobe.com/devnet/flex/quickstart/validating_data/) Deferred for this release, but will be considered in the future. Thanks!
Can you please consider this ECR for Flex 4?
I doubt anyone will see this, but we need much more flexibility within Flex for displaying form errors. This behavior won't work for large/complex forms sometimes in applications.
Options should be: 1) Default Flex behavior 2) Permanent error tips, for all fields (optionally) 3) Temporary error tips, which show for a few seconds but revert to look like the Flex default after that time has expired (mouse-over should still show the field again like it does by default) 4) Permanent (or even temporary) error tips for the FOCUSED component only (this option would be compatible with both 1 and 3, and is what is asked for in this ticket) Using a custom ToolTipManagerImpl, I was able to force the error indicator to show when a component's "errorString" property is set.
The implementation was painful. Briefly, it involved: 1. Creating a CustomToolTipManagerImpl, inheriting from ToolTipManagerImpl and overriding various event handling bits. 2. Creating a custom application preloader which registers the single CustomToolTipManagerImpl class. e.g. Singleton.registerClass("mx.managers::IToolTipManager2", CustomToolTipManagerImpl); I'd also like to see this functionality become an optional feature of the flex framework. Agreed. This bug has been in here for 2 years? Come on Adobe. Just create a method on a TextInput, or someplace that will allow developers to simply "display" the error tip, if an error exists for that form item. I started digging into the code and really we just need a way to manually call the functionality contained within the "ToolTipManagerImpl.toolTipMouseOverHandler" and "ToolTipManagerImpl.toolTipMouseOutHandler" methods rather than you guys just hardwiring everything to the mouseout/mousein events.
Note that this is the sort of thing we expect to be easier with Spark. It's important that any adjustment here be especially careful of the performance implications of popping these error tips, you'll also want to validate that when multiple fields have errors the proper error tips are shown, that mouse and focus behavior continues to be correct (for example when the focus of a textinput ends the tip doesn't clear if the error hasn't been fixed if this property is set), etc. I encourage you to give this a try, but might be good to do a checkpoint to make sure you're on the right track and don't add so much code that we're going to reject.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
For me, after quite some time, I realized I can do it, but with my form I have to do both:
e.currentTarget.dispatchEvent(new MouseEvent(MouseEvent.MOUSE_OUT));
e.currentTarget.dispatchEvent(new MouseEvent(MouseEvent.MOUSE_OVER));
I call those when doing a focusOut event from my TextInput.
Not sure why the MouseEvent.MOUSE_OUT is required, but when I remove it, it doesn't work....