7 Replies Latest reply on Feb 6, 2012 4:19 PM by BruceRobertson

    New Window Command Feature Request

    BruceRobertson

      I would like to see a "New Window" command that gives us more options.

       

      The existing GTRR command comes close but has some limitations.

       

      The Go to Related Record command (GTRR) allows us to specify the window name, location, size, and layout.

       

      It also allows us some control over the found set of related records that will be selected in the new window.

       

      Limitations of existing GTRR command with new window option:

       

      You must be in browse mode.

      You can only go to layouts that are based on related table occurrences.

       

      Limitations of existing new window command:

       

      It duplicates the exisitng window

      It may trigger on record load script triggers

      There may be performance issues including from the display of summary or related data.

       

      Ideally you would be able specify in a single new record command:

       

      Layout

      Window name

      Status bar status (show, hide, locked, unlocked)

      Window location and size

      View state (form, list, table)

      Mode (Browse, Find, Preview)

       

      Being able to specify the found set would be nice but we have control over that with scripted finds.

       

      It is possible to get part way there by using the GTRR command by turning on error capture, going to a self-related table occurrence, and using the calculation method for selecting the layout name or number. The layout name/nunber by calc method does allow you to use a variable.

        • 1. Re: New Window Command Feature Request
          BruceRobertson

          Attached is a basic example of using GTRR to go to a random layout in a TO that is not related.

           

          EDIT: in the original request that should be "... in a single new window command"  not new record. I think everybody understood that but still wanted to clarify.

          • 2. Re: New Window Command Feature Request
            BruceHerbach

            HI Bruce,

             

            You bring up a good point,  I hate using New window command for the reasons you mentioned.  My way of getting there is to GTRR to a  new window/  blank layout, same table for the record I am on and usually at -10000 pixels vertical/of screen.  This should be error free as long as I am on a record.   Then change to the layout/table I want to work with and do a find for the records I want to work with.  If I want the user to interact with new layout/window then place it on screen.

             

            It's not perfect,  but get's me to the new window/new layout with out kicking off any On...load scripts.  Catch if there is one if that I have to make sure I don't add any of these scripts to my blank layout.

             

            Bruce

            • 3. Re: New Window Command Feature Request
              beverly

              Bruce

              "You can only go to layouts that are based on related table occurrences."

              First you said GTRR would not go to a layout that was NOT related, then you showed an example of how!

               

              Is it your argument that GTRR is a better method to go to a new window than "New Window"?

              Does the GTRR bypass the "duplicate current layout"? I looked at your example, but couldn't tell.

               

              Thanks,

              Beverly

              • 4. Re: New Window Command Feature Request
                RayCologon

                BruceRobertson wrote:

                ...Ideally you would be able specify in a single new record command:

                 

                Layout

                Window name

                Status bar status (show, hide, locked, unlocked)

                Window location and size

                View state (form, list, table)

                Mode (Browse, Find, Preview)

                 

                Being able to specify the found set would be nice but we have control over that with scripted finds.

                 

                Hi Bruce,

                 

                I fully agree, and that would be a *great* improvement over the current situation.

                 

                Have you submitted this as a suggestion at <http://www.filemaker.com/company/contact/feature_request.html>?

                 

                Cheers,

                Ray

                ------------------------------------------------

                R J Cologon, Ph.D.

                FileMaker Certified Developer

                Author, FileMaker Pro 10 Bible

                NightWing Enterprises, Melbourne, Australia

                http://www.nightwingenterprises.com

                ------------------------------------------------

                • 5. Re: New Window Command Feature Request
                  DavidZakary

                  More control would be a good thing, but it isn't difficult to add these things. What I do is have a script to create a new window with passed parameters for size position and names. One parameter is for triggers on or off and if there is an on layout load trigger associated with it the trigger script checks to see if the script should run or not.

                   

                  It's not perfect but  can accomplish most everything I need.

                   

                  Is is the kind of thing that has been part of my standard toolkit for a while.

                  • 6. Re: New Window Command Feature Request
                    RayCologon

                    DavidZakary wrote:

                    ...but it isn't difficult to add these things...

                     

                    Hi David,

                     

                    I'm not sure I agree with you.

                     

                    Let me give an example. Presently, a new window inherits the Status Toolbar state of the current window, whereas you can specify its size within the New Window [ ] step. While you can use a subsequent Show/Hide Status Area [ ] step to ensure the appropriate state of the toolbar, *if* the toolbar state changes the window *size* will also change, and you'll then have to call a further Move/Resize WIndow [ ] step to restore it to the desired size, at which point you no longer have a smooth transition but instead have treated the user to some ugly/unnecessary window flickering.

                     

                    Even if you use Get(StatusAreaState) to pre-calculate an adjusted window height, which potentially eliminates one of the possible two undesired new window resize 'events', there's no way to avoid the remaining one for all cases unless the solution is one in which you have the luxury of locking the toolbar (in either shown or hidden state) for predictability - and this has its own issues.

                     

                    A similar problem arises with layout selection - as things currently stand, a new window inherits the current layout, so the scroll bars and layout are apt to flicker into view, then disappear as a subsequent script step selects the desired layout. Not the seamless transition one expects in modern software. There are work-arounds (building the window off-screen then moving it into view etc) but it shouldn't have to be so hard...

                     

                    As I see it, Bruce's suggestion would provide the ability to "pre-flight" all the main attributes of the window, so it can be drawn once on the screen in its final/desired 'form', which has the potential to be quite a bit simpler and cleaner.

                     

                    Regards,

                    Ray

                    ------------------------------------------------

                    R J Cologon, Ph.D.

                    FileMaker Certified Developer

                    Author, FileMaker Pro 10 Bible

                    NightWing Enterprises, Melbourne, Australia

                    http://www.nightwingenterprises.com

                    ------------------------------------------------

                    • 7. Re: New Window Command Feature Request
                      BruceRobertson

                      Thanks Ray. I have not yet submitted a feature request; I wanted to get some feedback first.

                       

                      Bruce