4 Replies Latest reply on Jun 18, 2017 2:28 PM by gofmp15

    Card vs Dialog


      It's a bit dangerous to use any technique without testing it thoroughly, almost as bad as using a screwdriver for everything.


      CARD works great with IOS if you follow one tiny rule. Make the layout narrower than what FileMaker suggests. For instance, I find 280 works far better than 320 for the iPhone due to problems with scroll bars. You can use any width but I prefer my layouts to now sroll to the right...


      CARD has noticeable problems with Windows 10 and I assume the same happens with Macs.


      The problem for me is that CARD works in relation to the window it is called from, which is how it is described and that window can be moved before the card window is opened. This means that if I move a window to the lower right before clicking on the button, the card window may be truncated and cannot be adjusted. Moving the window  to the left means that the close button may be hidden and the user suddenly confronted with a modal dialog they do not know how to close.


      Card Problem.PNG


      Yes, the frozen window dialog can be closed using Command+W and the window dragged into a better location, but your user isn't going to be happy.


      Using a Modal Dialog solves the problem in Windows 10 and probably Macs.


      Card Problem Solved.PNG


      The dialog is nicely centered on my screen (with a few script techniques) no matter where the original window is.


      DIALOG overcomes these problems and I can open a modal dialog (the same thing) and center it on my screen exactly where I want with none of these problems...except I have to think and add about 6 script steps for variables, etc. Of course I learned these techniques 20 years ago using 4D...


      Window Types

        • 1. Re: Card vs Dialog



          do you have a test file that I and others can work with to see the issue an try a few things ? Both my computers run on Windows 10.

          • 2. Re: Card vs Dialog

            No need for a demo, just create a script and try it. Drag the window around, etc.

            • 3. Re: Card vs Dialog

              So I gave it a try.


              When the Layout calling the card is entirely visible on the screen, the card look pretty much centered on the parent Layout. If I move the parent Layout down to the right, then the card is only partially displayed, and that's an issue because the button that closes the card is outside the screen. The only way out is to kill the application .


              I would first say that bringing the parent Layout where it's barely displayed serves no purpose, but customers can do weird things. Then is it a problem ? I would say yes. Does that prevent developers from using cards ? I would say no.


              Applications need to be customers proof. In this case, my suggestion would be: before executing the New Window that will bring the card, check if the calling Layout is completely displayed. If not, then cancel the script and optionally display an error message to the user.

              • 4. Re: Card vs Dialog

                A valid idea to check conditions before proceeding.


                This however diverges from the idea that FileMaker is easy to use when you have to do more work to make simple things work correctly.


                If however you ignore the cards (whose own benefit is in dimming the parent layout) and use a dialog you can center it in the window and ignore these problems, complaints and looking foolish.


                The new window dialog can be centered in the window easily and FileMaker failed by not providing something as simple as a checkbox to do this for us.


                But, I was doing this 20 years ago in 4D so I know how to do it.