Reusable Dialogs Revisit
Causing a user to make an explicit choice within your software really only happens from some sort of "locked-in" process. This process most typically happens within the form of a dialog box. It's the one roadblock you can stick in front of a user and expect input. Your software then uses that input to determine the output or direction.
While FileMaker Pro does have its own native dialog box, there are some limitations to the native Show Custom Dialog script step. The number one limitation is the lack of control with regards to size and positioning. Aside from that, the dialog box is pretty fixed in terms of how it looks and what it does.
Actually, the limitations on a dialog box are a good thing. It creates a sense of consistency across the whole notion of software itself. Users have seen dialog boxes and interacted with them. They know what they do and how to react to them. So, in order to gain a bit more control and flexibility, we use our own layouts to provide our own variation of a dialog box.
By using a FileMaker layout, we get to control how it looks and reacts to certain situations. This video and technique file revisits an early version which was released when Card Windows had just come out. If you enjoy using powerful and efficient methods of enforcing that "locked-in" process, then make sure to check this one out!
Comments
Couple of ideas ...
Thanks Matt. I always learn something from your videos. I am actually in the middle of implementing your original 2018 version, so your timing to revisit is great :)
Allowing the escape key to close card windows is a good tip, but if the idea is to replace FM's dialogs, I would argue that it's rarely a good idea to allow users to "escape" if you're prompting them for a response unless there's a specific "cancel" action associated with it. Dialogs typically ask users to make a choice, and unexpected things could happen if they just closed the window without choosing something.
It wouldn't be hard to implement, but there could be an "escape" override option added to the parameters. For instance, if it's okay for a user to cancel (such as if it's one of your buttons), then the escape key would run whatever script is attached to the cancel button's action, which would presumably include a close window step. But if you don't want users closing the prompt without first making a choice, then it shouldn't allow them to escape out of the card.
I've done something similar using the enter/return key, so that pressing either will trigger whatever script is set for the "default" button, saving them from having to use the mouse, while also mirroring common dialog behavior.
In this video, you also checked whether the front window was already a card and had it switch layouts and refresh. However, in something like a card window "wizard", I wouldn't want to navigate away when I need to prompt the user for something. As you point out, you can't have a card on a card, so when I detect that the current window is already a card, I scripted it to create a modal "Dialog" window on top instead. This allows me to still force the user to make a decision before continuing while not losing my card context and having to worry about taking the user back.
Very good points!
Yes. If you don't want the user to get out of the dialog box I would add a parameter of something like "escapable". There are a few different types of dialogs. Some, which can be answered with "you must answer this now" vs. "you can answer later if you want".
The enter/return key option is a great way to handle the default option too. You can also make it work when a default button is active. I think I'll add that feature in thanks to your great suggestion!
On the topic of a wizard like function I typically opt for a List view with variable Subsummary parts for those longer processes as it allows me to manage the whole process within one single layout instead of multiple.
These are all great topics and suggestions. Thanks for posting!
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Calling it from a card window style
Hi Matt,
It is a great one. Really love it.
But, I have a question: can this dialog be called from a card window style ? It seems does not work, or did I made a mistake on my solution.
I just want to make sure if it can or can't.
Regards
Very Interesting
I think I should be able to figure this out fairly easily. I use the global variables to display error messages on the screen using button bars and allow the user to clear the error from the screen by clicking it.
Similarly I wrote a script a couple years ago, and posted it on the official FM Forums, that would allow layout navigation by the Layout ID. In my case though, I used a couple tables so I could manage navigation from a layout and not need to change scripts.
Sadly, I moved on to a management role at a different company and my time to develop in FileMaker is limited anymore. Loving the videos though. Keep up the good work. I subscribed because I appreciate your work and feel you should be reimbursed for it.
This updated version fixed a problem I had
Hi,
I downloaded the old version months ago, and I was just to start integrate it in my application until I found a problem in the concept. Maybe it's my way of doing my script, but I wanted to create a loop sequence and use the warning dialog to tel user that he didn't fill up correctly the required info.
In the loop, was the call for the dialog, needed to pause, and since there's no script step for resume, but only trigger but single step button, and the perform script can't run one by name !! I was not able to display error message while keep running the script.
But now, this new version use a regular perform script button, I will probably make it work.
Thanks Matt for all the great ideas you share with us.
Missing options
I Completed the integration, but I was surprised that you remove the $anchor and $offset option.
I use the old file and and merge the 2 techniques so I can get the anchor back. I love to use the bottom center for warning alert dialog.
Also I will need to work on the % size of the window, the previous technique used a % to size the new dialog (with the custom function) Now it don't.
This is really good, but I found that this technique is missing something, in a script that you need to ask the user a question, A or B and based on the answer and IF statement in the script will do whatever you need.... this do no replace the dialog "AS IS" because you can't do it, unless you create a very complex script with parameter that are send back from the button and execute the same script and jump back to continue with a full load of IF, ELSE based on the script parameter. Unless someone have a solution to ease the process ?
Database Design Report
Hello,
regarding your thoughts about scripts with identical names... As far as I know Filemaker runs the script which comes first in the order. I think this is rather annoying and I would prefer an option "run script by ID".
How do you approach analysing a database if you work with internal scriptIDs, since the name of the script is not referenced in the database design report anymore? One might think that a script is not used anymore and delete it, although it is used by reference to a scriptID.
Any suggestions to avoid this?