There is no native way to enlarge the size of the dialog to fit the contents.
You can either use a modal window with a layout and buttons in place of a dialog, or use a plugin like troi dialog that supports it.
I want avoid plug-ins type!!
Because This solution is distributed to large no. of users around the city who may then use it on several computers.
I don't want to be the responsible for installing those plug-ins in each of these cases!
Anyway, thanks for the suggestion, mikebeargie
plugins can be installed, updated, and checked via script on login, so there is no reason to be so plugin-phobic. Plugins are powerful and allow you to do great things as a developer.
That said I DID state the option of making a modal window that serves as a "large" dialog box, I'd suggest you look into that.
Mike - This seems like a very easy issue for Filemaker to fix and I've not run into this sort of issue in other development systems. Just wondering why something like this isn't addressed by making the dialog resize to fit the text? I know every time a client sees this and I have to explain that they need to resize, they always ask why it doesn't resize automatically. I have no answer.
The dialog text is done via the calculation engine. What would happen if someone dropped 12 pages of content in there? What happens in iOS? WebDirect? There are other considerations that I'm sure FileMaker is making when they do or don't do something so I try not to finger point if there are solutions around it.
If I have a message that's going to be longer than one or two sentences (such as an EULA or log file), I use my own utility modal window. This is just a single modal window, with a layout that has a scrolling global text field, and buttons with merge variables. I can then use this window and layout anywhere in my system, set the global text with any length of message I want, and even control the text and actions of the buttons. In my opinion, this is BETTER than a custom dialog.
The FileMaker Custom Dialog Function is unusable. It sucks big time, and that since v1. Use a plug-in, it's not that hard.
It's perfectly fine for a LOT of uses, like a login dialog, password masked entry, or even quick notes about scripts being done for debugging.
Tossing in casual insults isn't productive.
Once the plug-in is installed, I can use it all the time.
Tossing in casual "insults" gives air to my grief...
In the past I have used a series of dialog boxes to display a longer message. Pretty much just a script calling one after another with each of them displaying only as much text as would show without expanding the box. I would add a NEXT button to indicate that there is more to read.
Nowadays I go with the modal window as Mike described or with a popover if that is appropriate for the situation.
Maybe the control does not work exactly the way you want but their are other ways to provide a custom dialog experience.
Please remember this is not a chat room but a place for people to go for help
First of all, one should always check the buttons and make sure they are all needed and worded properly.
In your case, the presence of 2 buttons only confuses the user.
This being said, and the modal window alternative also being said, you can set up a popover appearing for example at the top of your interface, under an "i" symbol. This popover only contains a merge field (a $$global) and an ok button (which only does the "close popover" script step). You will be dimensioning it big enough from the start.
The popover itself (not its popover button) is named "LastInfo".
When you have a message to display, you set the $$global and you do a go to object("LastInfo").
Pack it elegantly in a DisplayInfo [info] script that does
and call it with DisplayInfo [info], parameter: whatever text you want.
Should people press on the "i" button on their own initiative, they will see the last info they had. (Which might be handy, too).
I too have used the technique of multiple dialog boxes, with n–1 of them having a "Next" button and the nth one having an "OK" button. IMHO, this is a kind of kludgy workaround to accommodate an inherent limitation of native FileMaker Pro. Like Suresh, I'd rather have a custom dialog that expands automatically to display the desired text. Mike Beargie's concern that this might run on to multiple pages is something that FileMaker already knows how to handle, as when a layout is too big to fit on the available screen: Use scroll bars.
However, I agree that this is a subject best addressed under "Feature Requests". I cut Suresh some slack for not having done so, because he was obviously wondering if it was some feature he was missing in the program or, if not, what a reasonable workaround might be.