Custom dialogs that automatically resize, or perhaps have the ability to scroll the content, if it is bigger than the set size.
I'm not sure if it's the same on a Mac, but definitely on Windows.
This would stop the possibility of the end of messages being missed if the users dialog window is set to a small size.
Show Custom Dialog have been upgraded in 12 and then in 13 : first for the Validate checkbox on all buttons and after to be able to set a calc for button's label. It is still basic but it works in a lot of case.
It works just fine in WebDirect where create a new modal window is... you know...
At contrary, i would not use a popover as a replacement in most cases. It cost an object in every layout : often too much i think. It not behave correctly in many situation (like when an interactive container or webviewer is near)
Slide panel for a dialog ? In some exceptionnal situation, maybe...
Maybe we are moving away from custom dialog and more to popovers is BECAUSE of their limits. Thanks, Fred. They do have their value for sure, particularly if they will expand.
Thanks to YOU for your understanding and your vote .
And what about positioning the dialog. AND Field dimensions, AND more elements like checkboxes, radio buttons, sliders, AND correct handling of ESC key AND more buttons, AND... AND... (in short: a modern, well-behaving gem)
Indeed I'm not using this function because of the limitations erronuous behaviour. But in my opinion it is a necessary function. That's why I make use of a plug-in. Since they exist.
At a certain point, it is up to you to identify where a real layout is needed.
hbrendel a écrit:
AND more elements like checkboxes, radio buttons, sliders, AND correct handling of ESC key AND more buttons, AND... AND... (in short: a modern, well-behaving gem)
...and a calendar-control / date-picker, this is a feature, not even the dialog-plugins have got
If this is picked up by the developers, I would suggest that the button location remain constant (along the horizontal axis, at least).
I've previously encountered a situation (unrelated to FMP) in the SeaMonkey browser where if one dialog pops up right after another, the user can accidentally click the wrong button. (see Bugzilla bug 615687 – Variable-width cookie dialog boxes can cause accidental "allow" clicks )
I'm not sure if this will be as much of a problem in FMP since you can't have more than one dialog box up at the same time (right? or can you?), and therefore we wouldn't have to worry about one popping up on top of another.
In FMP, I can only see this being a problem if there are a series of dialogs that the user needs to click where they are of different size, and it would require a BOFH to create a solution that puts their users through that! AFAIK FMP developers and their users are usually on the same side...
- RG>
Easily falls into a category of something desired since FM6... something you inherently feel should just *BE* that way.
It would really be nice to get this one knocked out, so we aren't forced into using plug-ins or workarounds.
closing/cancelling a (modal) Custom Dialog box with ESC to behave like the PRINT dialog box would be desirable
It seems more and more we're moving away from custom dialogs, using instead popovers, sliders or modal windows to provide dynamic messages and data-input fields when we need to interact with the User.
I guess it would be nice for those that still use them though. :-)