5 Replies Latest reply on Jun 28, 2010 3:18 PM by Steve Wright

    Initial Window Size.



      Initial Window Size.


      Wasn't sure whether to start a new post here since this also relates to this thread


      I'm new to FMP and bearing in mind that FMP has an autoresize facility, how do others decide on the size of the main database window if the dBase is to be used with both earlier versions of FMP (8 & 8.5) as well as Mac and Windows platforms each of which has a different approach to window sizing?


      EG Do you design it to look optimum on (say) a 1280 x 1024 monitor and then use the resize option to cover other larger sizes on the basis that there probably aren't many smaller monitors left in use.  


      My initial thoughts are to design for around a 1000 x 700 initial window (should be OK 'as with FMP8) and allow autoresize to cope with any larger monitors, but before diving in I wondered what approach experienced FMP Devs use.


      Thanks for any advice.

        • 1. Re: Initial Window Size.



          I'm sure that approaches vary all across the spectrum on this one, so let me tell you what I use and let others relate what they use.  Perhaps a consensus will emerge, perhaps not.


          I design for the smallest screen I think is likely to be used so that all can use the Dbase effectively.  I then use Get(Screenwidth) to see if it a widescreen and either adjust the zoom level or switch to another layout that has "extra" buttons on the side.


          Note that I typically build only for in-house use, I am not a 'hire-out' developer (insert proper term here...I dunno...freelance?) and I have a pretty good feel for what size screens I'm working with.  The "extra" buttons also add a little momentum for the folks with 6year old CRT monitors to request an upgrade...


          I'm sure there are many, many other approaches...this is mine, quick and easy.  I can't say I've spent much time thinking about what the optimal approach would be.

          • 2. Re: Initial Window Size.
            Steve Wright

            I designed my solution to work as low as 800X600, although since that is probably in the minority these days, I use 75% Zoom to accomplish this, allowing for better quality (100% Zoom) for pretty much all other scenarios.

            On that note, it would have been nice to have smaller steps in the zoom rather than it suddenly using 50 increments, 25 all the way would have helped.


            My solution is a vertical market solution (shrink wrapped / off the shelf) so it has to cater for as many configurations as possible.  The introduction of dynamic resizing helped, but its not perfect, we could have done with more control with horizontal resizing, such as when you group 5 fields and resize them manually. If only that ability could be leveraged..


            Due to this, to keep my solution looking at its best I have duplicated a number of the main layouts (but not all) so I have a standard aspect and a wide aspect which also make use of dynamic resizing.

            75% of the screens cater for both


            On startup, I check the screen size then set a variable such as $$aspect = "W"

            During scripting / layout changing, I use go to layout [$$aspect & "-layoutname"]


            Its extra work, but I feel its worth it, since FM9's release when we adopted this we have yet to have any complaints.  Before hand, we used to fix the window size (via a plugin) but windows users like that maximise button, so a fixed window was not very welcomed.


            Sizes I use are : 

            Standard = 994px wide X 640px height

            Wide =  1230px wide X 640px height



            Whilst there's not a great deal of difference, its enough to allow me to make things look in proportion, rather than having a single field stretch, I can resize most of them just enough.. but it also helps with various screen resolutions too.


            Another thing I do, depending on the screens of course, is use a calculated repeating field to display data (not edit it)  for example :


            A calculated repeating field to display values from 4 different fields, displayed horizontally with auto resize containing the calculation



            Get (CalculationRepetitionNumber) = 1 ; table1::Field1 ;

            Get (CalculationRepetitionNumber) = 2 ; table1::Field2 ;

            Get (CalculationRepetitionNumber) = 3 ; table1::Field3 ;

            Get (CalculationRepetitionNumber) = 4 ; table1::Field4 



            This allows you to achieve otherwise impossible results for display purposes, whereas natively, only 1 field could resize horizontally, making it soon look rather strange, this allows as many fields as you want to resize horizontally, keeping a consistent look at any screen width.  Of course, this only works if the fields are meant to be next to each other and are similar widths by default.


            I have to thank John @ Seedcode for this one, it did not even cross my mind until I set my eyes on his new calendar solution which uses a similar technique and allows the entire calendar to stretch both ways.






            • 3. Re: Initial Window Size.

              You can use the get function get(applicationversion) for the script to determine what to do.

              • 4. Re: Initial Window Size.

                I too wish FM would create more zoom options - 25% increments up to 200% would be nice, with perhaps a 110/115% together with (say) an 85% for smaller adjustments.  These, together with an opening script to set the size would do a lot of jobs nicely.


                Although I'm new to FMP I have played with dynamic resizing which seems a bit of a mixed blessing.  Works fine with horizontal resizing but in my experience trying to resize a portal in both directions upsets other design elements.  


                Like the idea of using a calculating field to display values together with auto resize containing the calculation.  A neat trick which I would never have thought of.


                Thanks for all the suggestions - plenty to think about. 


                • 5. Re: Initial Window Size.
                  Steve Wright

                  Just another note on portals & dynamic resizing..


                  Theres two ways a portal can resize vertically.


                  1. If you anchor ALL of the fields / objects within the portal to the top the portal will increase the number of available rows

                  2. If you don't anchor ALL objects to the top (even if you anchor all but one to the top), the portal row height will expand, leaving the same number of rows