1 2 Previous Next 17 Replies Latest reply on Nov 20, 2010 9:35 PM by RickWhitelaw

    Layout-level variables

    HowardRathbun

      Title

      Layout-level variables

      Post

      Mention was made in a reponse to one of  my posts about a "layout-level variable".  It sounds like it would be a big help to me if I can only learn how to do it.

        • 1. Re: Layout-level variables
          philmodjunk

          Do you know how to add merge fields to your layout?

          You can add a global field to a FileMaker 11 layout as merge text:

          <<$$GlobalField>>

          Scripts in your solution can then assign a value to this global variable with the set Variable step directly or indirectly via the Let function.

          Set Variable [$$GlobalField ; Value:  1 ]

          Let ( $$GlobalField = 1 ; )

          • 2. Re: Layout-level variables
            LaRetta_1

            Alright, I wanted to provide this before but I'm just wrapping up a software rollout and I've very tired.  But first example is of a list layout.  Normally two calculation fields would be required.  Instead, it is handled with conditional formatting and layout-level variables only - no script triggers at all.  The two fields to the right are only typed text as <<$name>>

            I have placed text underneath the two fields to the right.  The text underneath is named 'I declare variables' and it holds the Let() statement with ALL calculations I want for this layout (but don't want to create real calculations for.

            The fact that this 'I declare variables' is under the layout-level variables actually forces them to trigger and evaluate every time the data they reference within the Let() changes.  The 'I declare variables' will only display in layout mode (WindowMode < 4 will hide it).  It is hidden by setting the conditional format to 500 pt font.  The stacking order is important - select the 'I declare variables' and send it to the back (in Arrange).

            http://www.4shared.com/file/mw-u1Tly/VarDisplay.html

            You can use this technique in portals to create calculations which you never would have been able to create without additional table occurrences.  In portal, place the 'I declare variables' under the first row of the portal to force evaluation of the layout-level variables you place within.  This is a weak example of portal use for someone who needed a calculation in the portal and didn't even have the proper relationship to normally get the information and I didn't want them to have to create a calculation and another table occurrence just to get it so I used layout-level variable.

            http://www.4shared.com/file/e3w1Sqvf/PortalCalcs.html

            Third example using conditional information to display on a report that I created for someone as another example:

            http://www.4shared.com/file/Tbf9N8xe/LayoutVariable.html

            Again, $$ is not needed.  Global fields are not needed.  Scripts and script triggers are not needed (usually) ... they update by themselves.  And calculations you used to create which cluttered your field definitions and made life difficult and slowed your solution are no longer required.  I have one report with 30 calculations which only needed for one report.  Prior, I had 30 calcs in the table ... they have all been replaced with one 'I declare variables' and the calcs reside within the Let() within it.

            Layout-level variables are also much faster than calculations and redraw more quickly.  I realize the examples aren't perfect.  I realize I could have been clearer in my explanation.  I simply am short on time.  I hope this answers many questions about layout-level variables.  There are many people who think they know what they are and they don't have a clue to their real power nor how to use them.

            • 3. Re: Layout-level variables
              davidhead

              I believe the correct term for "layout-level variables" would be "merge variables".

              As Phil has indicated, variable values can be displayed on layouts in text objects using the standard merge field structure but using a global variable, <<$$variable>>, or a local variable <<$variable>>. The value of the variable can be set in a number of ways but most commonly through a script step.

              TS_Oz, FileMaker Inc.

              • 4. Re: Layout-level variables
                sunmoonstar.13

                Hi LaRetta,

                 

                Many thanks for your time and effort in providing these examples.

                 

                With the PortalCalcs example, I discovered, as you said, that the layout-level variable won’t work properly until the "I declare variable" object is moved INTO the first portal row AND put below the actual merge variable in the Arrange stacking order. The same obviously applies for List View layouts. The stacking order is crucial. If the "I declare variable" object is not at least one level below the actual merge variable in the stacking order, it won't work properly. I gather that, as a general principle, FMP evaluates and draws objects by starting from the back and then progessing to the front. I wasn't aware that FMP did that, so that's useful to know.

                 

                I found that the "I declare variable" object could also be hidden by setting the conditional formatting to the same colour as the layout background (which was white in most of your examples). Is there any reason why setting the conditional format to 500pt font would be better than setting it to the background colour?

                 

                So, in looking at the technique of layout-level variables, a number of things occurred to me:

                 

                Disadvantages

                 

                (1) It's a pretty advanced technique, certainly not for newbies. To set it up properly requires a fair bit of knowledge and experience with FMP, particularly with writing Let() statements.

                 

                (2) One has to remember the important step of putting the "I declare variable" object behind the actual merge variable in the stacking order. It would be easy to forget this step and then wonder why it wasn't working properly.

                 

                (3) Layout-level variables can’t be used with Finds and sorts.

                 

                  

                Advantages

                 

                (1) fewer calculation fields

                 

                (2) fewer table occurreneces and relationships (in some situations)

                 

                (3) faster calculation speed

                 

                To my mind, the advantages would only really become significant if a layout had LOTS of calcs (such as your example of 30 calcs in one layout). For a layout with only a handful of calcs, however, standard calc fields would appear to be easier and simpler to implement than layout-level variables, and the difference in calc speed would be negligible, I suspect.

                 

                In summary, layout-level variables is certainly a useful technique to have learned about. I’m not sure if it would be worthwhile for me to go to the trouble of implementing the technique in my own databases, but you never know, a situation may arise in the future where it would prove to be the best solution.

                 

                Thanks again, LaRetta :-) If there's something I've overlooked or misunderstood in what I've said above, please let me know.

                 

                Nick

                 

                 

                • 5. Re: Layout-level variables
                  LaRetta_1

                  Oz, I call them layout-level variables because that is what was first discussed in the other post when describing them and it fits better than merge variables (since the layout is where they occur; just as layout-level formatting).  I didn’t not coin the phrase – it has been used by many Developers on several forums.  I understand the 'correct term' according to FMI but FMI gets many things wrong so I don't live by what they say (and most Developers don’t).  FMI changed FMD (calling the Developer version Advanced and everyone still gripes about that poor, confusing name change).  And FMI gave us over 100 current bugs in the program.  FMI can learn many things from the developers who USE this program every day to earn their living.

                  As to whether using script is the most common way - script is most common way when triggering Refresh Window [flush cached] is required or for more advanced techniques, particularly when window switching and portlas but many times script is not required.  $$ is not required since, once it is drawn on a layout, it persists.  If you work in FileMaker 60 hours a week as a profession as I (and other Developers do), you will find you don't know it all. 

                  Hey, folks, I shared something I and many developers are using for many exciting solutions.  I am not here to argue nor defend any more than those that argue against or defend anchor-buoy.  I mentioned them once; I have provided a few examples over the months; and I was again asked to provide examples so I have.  I know what these techniques have done for us and how we are using them.  I shared a very SMALL piece of that information.   In the demo referenced in this link (by Comment and Mr. Vodka), this technique has replaced three calculations that only were necessary for displaying properly in one example (a hierarchical portal using filtered portals):

                  http://fmforums.com/forum/showtopic.php?tid/215217/tp/0/all/1/

                  As you use advanced techniques in this business, you will find yourself using them more and more often.

                  Howard, stacking order IS important.  I've made that clear in every post on the subject.  It isn't an advanced technqiue - only an unusual one used by the top Developers in this business and is very simple when you get used to it. Yes, you can color the 'I declare variables' to hide it.  But you will find that, even when you color it exactly as the background, there are times a faint hint of it can remain on screen (using Citrix for example) or depending upon resolution and monitor.  We've seen it several times and thus switched to the 500 pt method.  And if you end up changing the background, surprise - there it is.  By using 500 pt font, it will never show.

                  The advantages of using this technique far outweigh the disadvantages.  It doesn’t replace everything – nothing does.  It has its place just like every other technique and tool in this business but it is a life-saver in many instances.

                  Yes, if you need a calculation for sorting or searching then by all means create one.  But as you move ahead in this business, you will find yourself resisting the creation of a calculations whenever possible as well as resisting creation of needless table occurrences.

                  • 6. Re: Layout-level variables
                    LaRetta_1

                    Now see? I'm so tired, I didn't see that it was Nick who responded instead of Howard.  But there were a few other things I wanted to mention:

                    "I gather that, as a general principle, FMP evaluates and draws objects by starting from the back and then progessing to the front. I wasn't aware that FMP did that, so that's useful to know."

                    Indeed it is.  And that is why it works in portals and only evaluates on the rows visible (but as you scroll and additional rows and displayed, they evaluate).  Portal is drawn first row then second and so on and conditional format evaluates in same order.  That is why you can have conditional format evaluate and move down a page as it evaluates.  And because it is based upon layout level, it persists after it stops evaluating and will continue to display.  This sequencing can produce some incredible uses.

                    Disadvantages

                     (1) It's a pretty advanced technique, certainly not for newbies. To set it up properly requires a fair bit of knowledge and experience with FMP, particularly with writing Let() statements.

                    Let() statements are simple calculations which any intermediate (and even beginner) developer uses every day.  If you can create a calculation, you can use this technique.

                    (2) One has to remember the important step of putting the "I declare variable" object behind the actual merge variable in the stacking order. It would be easy to forget this step and then wonder why it wasn't working properly.

                     Yes.  But if it doesn't work, select it and send to back.  The advantages still outweigh the disadvantages in most aspects.

                     

                    Advantages

                     (1) fewer calculation fields

                    (2) fewer table occurreneces and relationships (in some situations)

                    (3) faster calculation speed

                    You nailed it.  These are MAJOR advantages.  They also can be created directly on the layout while creating the layout (thus why they are called layout level variables) without having to go enter the calc in field definitions and returning.  There are other advantages you will smile about while using them.  Once you understand and use them, you will be very glad that you learned their power.

                    To my mind, the advantages would only really become significant if a layout had LOTS of calcs (such as your example of 30 calcs in one layout). For a layout with only a handful of calcs, however, standard calc fields would appear to be easier and simpler to implement than layout-level variables, and the difference in calc speed would be negligible, I suspect.

                    I believe you are missing the bigger picture (although overall you've done a great job of studying the idea and providing a response).  As in the example of the Hierarchical Portal, this replaced three calculations for this ONE implementation.  Go to your next layout ... you need to display calculated result for a report (my second example) ... now you've saved four calculations.  Now you need a portal (you have now saved five calculations) ... and it goes on and on.  Pretty soon you have 20 calcs whose purpose is display and calculating only for display at the layout level.  Add to that a single complex report for Management and you can hit 50 calcs easily.

                    I appreciate your input a great deal, Nick. :^)

                    UPDATE: Added the red for clarity

                    • 7. Re: Layout-level variables
                      sunmoonstar.13

                      I understand what you're saying, LaRetta, and I see your point(s).

                       

                      I think I'd like to see FMI develop some new kind of object specifically designed for declaring layout-level variables. Using a text object with conditional formatting to declare the variables seems like a "back-door" way of doing it, almost like a "hack" in some ways, in the sense of making the program do something "out of the ordinary". I mean, did the FMI engineers ever imagine that someone would come up with the idea of declaring variables on a layout level using a conditionally-formatted text object? It's a clever and powerful technique, for sure, but even better, to my mind, would be a "native" way to do it, if you know you what I mean, some kind of native object that would declare the variables at the layout level, without having to use the "workaround" of conditional formatting on a text object to make it work.

                       

                      Nick

                       

                      • 8. Re: Layout-level variables
                        LaRetta_1

                        Nick said, "but even better, to my mind, would be a "native" way to do it, if you know you what I mean, some kind of native object that would declare the variables at the layout level, without having to use the "workaround" of conditional formatting on a text object to make it work."

                        I totally agree.  But hey ... we can't get them to fix the 100+ bugs nor make features truly useful (such as status toolbar).  We developers learn to be creative and cheat to get the job done.  In fact, here's an example by a fellow Developer.  This layout, using calculations (which would never be used again and are only needed for this one display) saved 120 calculations.  When first created as calculations, the redraw was terrible (it took roughly 14 seconds).  With layout-level variables, NO calculations were required and the display only takes 3 seconds (and there are several-hundred thousand records in multiple tables and several billion dollars being aggregated and displayed).

                        Few years back, they said they were working on 'layout calculations' and we were excited.  And this is the result.  It isn't quite what we had in mind ... we were hoping they would create TRUE separation so data is data and calculations resided in another upper level or was handled per layout like Access.  But hey, this is still saving us a lot of work.  We have to be able to cheat and use alternate techniques to work around the bugs, poor implementations of new designs, and incomplete features.

                        http://www.4shared.com/photo/bepH0ncx/chart.html

                        We must work with what we are given.  This technique is not an answer for everything ... nothing is.  But it is powerful.

                        • 9. Re: Layout-level variables
                          HowardRathbun

                          to PhilModJunk and LaRetta:

                          I just got around to trying your scheme for a "layout-level variable".  It worked just fine for a calculated variable which I previously had saved in a table.  So far so good.

                          Then I tried the same technique for a variable in a portal.  It partly works in that the value shown for the last row of the portal is correct but that same value is placed in all the previous rows of the portal.  I read through all these responses and realize I have to do something more when working in a portal.  I have to put an "I declare Variable" object in a 2nd window immediately below the layout variable in question.   But what is that?  Is it a text object?  If so, what do I put in that object?  I really could use some concrete examples.

                          Thanks

                          Howard

                          • 10. Re: Layout-level variables
                            LaRetta_1

                            The 'I declare variables' must hold the specified layout variable within a Let() within it and it must be placed under the first row of the portal and yes it is a text object.

                            Howard said, "I really could use some concrete examples."

                            I provided three examples (including using it in a portal) in the link above.

                            • 11. Re: Layout-level variables
                              RickWhitelaw

                              LaRetta,

                              I'm quite intrigued with this technique. However, as far as the files I've downloaded (your files I believe) are concerned, the merge field doesn't evaluate. The idea makes perfect sense but all I get on-screen is "<<details>>" etc. I'm on FMPA version 10.

                              RW

                              • 12. Re: Layout-level variables
                                davidhead

                                Hi Rick

                                Merge variables (as in <<fieldname>>) are a new feature of FileMaker Pro 11. So they are not supported in FileMaker Pro 10. A reason to upgrade? ;)

                                TS_Oz, FileMaker Inc.

                                • 13. Re: Layout-level variables
                                  LaRetta_1

                                  When you DO upgrade, Rick, be sure your layout-level variables include $, as in <<$details>>  :^)

                                  • 14. Re: Layout-level variables
                                    RickWhitelaw

                                    Thanks Laretta,

                                    It was, of course, a typo. I just upgraded and this technique works well. This was the info that pushed me to do the upgrade, although I'm sure I'll find much more in time.

                                    RW

                                    1 2 Previous Next