On popovers: did you know you can use GotoObject to accomplish that? Name the popover (not the popover button) in the Inspector.
On dialogs: this has been an oft-requested feature for many years. You may want to look into using a plugin for that - SimpleDialog from 24U is my recommendation.
A dialog is just a window...
One attraction for dialogs is that they are smaller and cool looking. I've used them in other programs and with popups that permit extra features but in the end it came down to the question of whether or not they were worth the extra effort just for my ego satisfaction. YES...
OK, you can create a modal dialog window with all the bells and whistles you want (except for hiding the darn scroll bars).
When you create a new window there is an option for Advanced Options which means that the engineer couldn't just expand the window and put those on that layout.
One Warning: be sure to include a close button if you uncheck the Close window control...
Using a little advanced calculations you can size this window and position it where ever you want such as in the middle of the current window.
There's your dialog window and all that's left is convincing FileMaker to do away with the phantom scroll bars on it.
1. In addition to posting here, which will have some community support, but it will be limited...make sure you make an official feature request. If you don't, this thread is for naught. Company | FileMaker
2. NightWing Enterprises - Screen Popovers Demo for FileMaker Pro 13 Gives you pretty much all the customize-ability that you can dream of.
That approach works only when you're on desktop. On FMGo any new window will be maximized without chance to make it different.
You can do that pretty easily with a paused script, some global fields and a second script attached to the three button you put on your layout to close the window and give a result, as the custom dialog step does.
What i find too bad, is the dialog advanced style of a new window leave a useless state bar on the bottom. Genuine dialogs don't have this.
Oh i will post a feature request now...
can be done with existing functionality. We got buttons here that open Popover (go to object..), have custom dialogs (even under FM11 with separte windows (desktop only).
YOu can have a popover window activated by a script (ie) that looks perfect on iOS, with buttons, whatever You like. I got even a built-in calculator in a FMGo App that sits in a Popover with all the needed buttons/functions
image.jpg 139.6 K
haha good one and a autosave record in case no commit has been done
would be great to have access to the "gyroscope" functions. Then we can add a OnPickup trigger as well...
Yes, I am aware of using GotoObject (and GotoField), but there are situations in which they don't work as I would like.
Ditto for using layouts as dialogs. While Mac users are perfectly happy with a main layout that doesn't fill the screen and any number of windows popping up on top of each other, this is not the usual experience for Windows users. They expect a single, full screen window, and (usually) one modal dialog open at a time.
I have had some success with using popover buttons in place of custom dialogs. The user opens the popover, fills in one or more fields, then clicks a button to close the popover and execute a script. But again, this is not ideal for every situation and seems unnecessarily cumbersome to setup in cases where all you really need is a dialog with a drop down list and a radio button list populated by a value list.
For several decades apps have been programed with dialogs that work like dialogs and do everything that dialogs do. FM understands this. That's why there is a custom dialog script step. But there is relatively little you can do to customize it. Users expect to see dialogs that look like the others ones for apps in their OS. They want to see drop down lists, radio buttons, etc. Like many of you, I get asked for this time and time again. It's something that would be genuinely useful, save me some time, and make my clients happy.
- custom dialogs are somewhat outdated (too simple, no use of $/$$ Var, etc)
- the window behavior under Win is less than perfect
BUt one can deal somewhat with extsting functions (Win)
- don't max the window, set it to a fix size that fills almost the screen (screen size could be examined for different sizes)
- this way, separate windows will work
- We check before creating a new window if it already exists. If so, close it first
- using popovers, I don't have *this* problems, but I got only OSX and iOS under V13
I don't say that all is fine - but I don't believe in feature requests... (not bad at all, but results -if any- will not be available soon)
(if just one kind soul could tell the web-Heini's that this two-letter-Caps is really annoying on iPad, every new paragraph...)
That's what I like about Ray's demo. You can easily fill the window with pop-over button, which essentially becomes modal ( except the 5 px around the outside edge ). And you can customize it to be transparent, or opaque, or whatever.
Ton's of options. And fully customizable with all of the layout tools.
Yes, but those not-quite-but-almost approaches drive many Windows users crazy. When FM is clearly going all out to try to give users what they have come to expect in an interface, online and off, to me it doesn't seem unreasonable to ask that developers be allowed to make a solution for Windows users that looks and feels like other Windows apps. (Full screen, not x number of pixels short around the edges. When I try to do stuff like that, it's all some people notice. And, what they take away from the experience is that FMP isn't up to par with other apps, or that their developer just doesn't know how to do it.) They did this for the FileMaker Pro application window. Why not let us build solutions with real Windows dialogs with controls that can be bound to fields and value lists in a database? Now, that would be something.
Allegro Data Solutions
FileMaker ships a version for Windows and a Version for Macs. Then both versions try to create a big compromise where one app can write code and create layouts for 3 platforms and unknown browsers and use Java or something else to do a lot of the work and produces a far less than satisfactory experience in all platforms.
I think that there needs to be a separation of Server from user appl. Let the server just do server stuff and not get involved in offering up something to run in FileMaker Pro. Now let a Windows division create a windows Pro file maker and a Mac division create a Mac Pro file maker and an IOS division create an IOS file maker.
Very few of the commands have anything to do with server except to ask for data. Everything else has to do with layout stuff.
I think that Pro is getting to overloaded with compromises trying to create one layout, one script, etc. that does everything for everybody. Doesn't work well. And by well I mean as good as it could.
One that opens on Mac and WIndows and IOS or three files, each minimized and maximized for that OS. Much better. Get rid of the compromised popovers and such.
And yes, I am aware of what that means and how it will affect developers... But if the engineers didn't have to compromise the code so that it almost worked well on three platofrms and instead could create layouts and goodies that worked really great on each platform...
OK, just a thought.
On IOS if you drag the popover to be larger than the window size, FileMaker will shrink to fit. Just anchor your goodies top and left. You can size those to fit within the appropriate boundaries of the popover.