5 Replies Latest reply on Feb 5, 2012 4:34 PM by cortical

    Created on Mac, Testing on Windows




      I've created my filemaker solution with FM Pro Adv 10 on a Mac.

      I'm about to start testing the same solution on Windows.


      Could anyone give me a few pointers on what I should be looking for

      when testing, i.e. what changes will I need to make, are there any

      major/minor gotcha's or known issues?





        • 1. Re: Created on Mac, Testing on Windows

          Fonts may not look the same and have different space requirements. Also check printouts.

          • 2. Re: Created on Mac, Testing on Windows

            Most common, if you have not already planned for these, are popup windows, screen flashing, and font display issues.


            Because FileMaker on PCs appears inside an application window, the size of the application window can constrain the size of the internal window.  On the opposite side, if the application window is maximized, a popup window can cause the main layout window to resize in an ugly manner.  If this becomes a major issue, there are some plugins and other window management tools you can find.  I try to design with this in mind from the beginning, as it is a pain to fix later.


            Screen flashing can occur for a variety of reasons, some of which you can control.  For example, a refresh window on a PC will always cause a flash or flicker for the user, so if you can avoid script steps that cause the flash, the user experience is much better.  A very common cause of screen flash is a video card on the PC which has a default graphics acceleration set to maximum, useful for gaming, I think, but most people can turn it way down to eliminate flashing.  If you have tested without flashing, but a user reports this issue, that's an early troubleshooting step.


            Last but not least, PCs display fonts different than Macs.  The same font (assuming you are using a standard such as Verdana or Tahoma that exists on both platforms) will display slighter taller and slightly wider on a PC.  This can cause your field labels to be cut off if the text box isn't large enough, and can also cause print layouts that are supposed to be one page to need two.  Check all your layouts carefully, and it is a good idea to align the text at the bottom so that it will not "snap" to the text size when modified.


            I am sure there are things I have missed that others will list.  Hope this gets you started!


            Warm regards


            • 3. Re: Created on Mac, Testing on Windows

              A typical gotcha that I found when I first started testing, is the apparent font sizes may not be the same. I have learned to make my fields and labels slightly larger  to prevent crowding.


              Another gotcha is to test for platform - if calculating a path for saving exported files or finding files for import. "desktop" path is different in the way its called. The FMA help makes this suggestion.


              IIRC, the help and user guides make other suggestions when designing X-platform.


              -- sent from my iPhone4 --

              Beverly Voth


              • 4. Re: Created on Mac, Testing on Windows

                Thank you all for your suggestions. Much appreciated!





                • 5. Re: Created on Mac, Testing on Windows

                  Test for paltform is mandatory


                  When using a print/save to path calculated as a variable  e.g.  get deskptop path +  a calculated filename, include the forward slash (mac) or backslash (win)



                  PLT = Get ( SystemPlatform )


                  If( PLT = 1 ; Get ( DesktopPath )  & "/report.pdf" ;   Get ( DesktopPath )  & "\report.pdf" )



                  What looks perfectly fine re refreshes and pop windows on  a mac, can become a complete ugly pita on win.


                  WIth a maximised parent layout on win, raising a popw will lose the parent maximise display setting. It is really an issue that should have been dealt with years ago, but no-one has come up with a solution that I have seen; other than avoiding pop windows altogether on win.


                  As indicated by others, screen flashing can be a real UGLY and highly annoying issue to win users; test early to get the idea. Testing under Virtual is not really appropriate either as this seems to mask the true extent of the flashing. Some design approaches you take for granted on mac are just plain ugly in practice ( i.e execution), on win.


                  Win users often have a thing for working maximised, Mac users take for granted being able to see the desktop. This one I only became aware of recently. Wether to re-arrange layout objects to occupy the otherwise unoccupied blank space at the right on win then becomes a consideration.


                  Win users commonly have the system task bar displayed, eating up even more vertical real estate, than does the window in window header bars.


                  Knock up some simple blank layouts of defined sizes, and get them tested on the clients hardware, so they can specify what size works best for them. Yes this will change in time when creens are upgraded, but that is down the tarck, they are usually concerned with what is in front of the here and now, and scrolling to see the lower contents of the layout due to win in win header and taskbar lost real estate is to be avoided.