11 Replies Latest reply on Aug 13, 2015 4:07 PM by user19752

    repetition by window name


      This one's a bit difficult to explain.


      For various and sundry reasons, we use a number in the window name to fetch a repetition from a global. We use this, for instance, to update and retrieve help text that can follow a user through a process in one window, while not affecting the help text following another process in another window.

      Please note: I know of many other ways to accomplish the ultimate goal, and I'm sure this group could come up with more, but that is not what I'm asking for. I need to figure out whether and how this particular method is broken.


      It appears that there's some sort of behavior change between 13 and 14. Download both attachments, and open the interface file. (I'll wait. ).


      If you open this in 13, and look at the text and image on the left, it works. At worst, it requires a refresh, which I could deal with.


      If you open this in 14, and look at the same, it does not appear to work, and I can't figure out why. The only way I can find to get this to update is to go into layout, then back into browse (not practical).


      Note that I'm getting the window number appropriately. Also note that if I use a set number (the entry field, on the right) I can use that. I just can't seem to use the number I got from the window title as a repetition parameter. I honestly don't recall ever seeing an instance in FM where I could calculate a value, but not nest it into a function.


      Am I missing something? Is this a known behavior change? Is this a bug that I should report?

      And of course, is there some change I could make that would allow the repetition to properly update based on the window name?


      Chris Cain


        • 1. Re: repetition by window name

          Instead of Calculation, define window_number (in Data) as number. Global.


          Add a 4th line to the set_window_title_to_number script:


          set Field [data::window_number; Get(WindowName) ]



          It will work even without refresh.

          • 2. Re: repetition by window name

            Unfortunately, it will also change in all windows. The purpose of this is to show text and such for each window separately.

            • 3. Re: repetition by window name

              Haven't look at the examples but perhaps an easy fix is not try and parse the number form a window but just use


              Code( Get(WindowName))


              as your repetition?

              • 4. Re: repetition by window name

                I'm getting the window number with no problem. What's challenging here is that I just can't seem to use it as the repetition parameter.

                • 5. Re: repetition by window name

                  It seems when refreshing, window name in repetition calc is got from data.fmp12 window.

                  • 6. Re: repetition by window name

                    I think in the past I sometimes resorted to the GetRepetition Function instead of [] notation.


                    In any case it's a FM14 issue.  I have update issues as well with portals.  Same solution works fine in FM13, but in FM14 I have to add extra record commit and window refresh before data is displayed.  In FM13 a simple refresh object is enough.


                    So a bug.

                    • 7. Re: repetition by window name

                      Hello Chris,


                      I believe that user19752 has correctly identified the underlying reason for this behavior, and it is certainly interesting to note the subtleties in behavior with respect to an object displaying a text/number field versus an object displaying binary data:


                      Case 1:  Render a Text/Number Field


                      When FMPA 14 renders the window_number field, as an un-stored calc, the calc formula is evaluated.


                      At that moment of evaluation, Get( CurrentWindow ) returns the name of the current window from the interface file.  This is as planned, and the outcome is as desired and expected.


                      Case 2: Render a Container Field:


                      When FMPA 14 renders the image_current_by_window_number field, also as an un-stored calc, the formula is evaluated.


                      The difference:


                      At the moment of this evaluation, Get( CurrentWindow ) returns the name of the the window of the data file. This can be checked by renaming the window of the data file to '3', and seeing your interface file display data from the third repetition (it might take a Window Refresh to see this result).


                      Additional Note:


                      I played around with variations on this, using WebViewers to display the target data, and global variables to capture the data, and I found that the result was similar to the container field case.


                      In Summary:


                      It seems to be the case that FMP uses different Window contexts when evaluating the same un-stored calc from an external file, depending on whether the layout object that renders the data is a text/number field versus a container or WebViewer layout object.  I wouldn't know whether to call this a bug or whether to simply call it a fuzzy area of subtlety where things are not well defined.  What I would venture to say, is that the inconsistent behavior is the output of Get( WindowName ) -- not the ability to extract a target repetition from a repeating field.


                      I do see a potential workaround, which I will mention below, however I feel that both the original solution (which I adore for the cleverness of it) and the workaround have reached a point where it feels a little too fragile for my comfort.  This is, of course, opinion -- someone else may see the scenario you present as a bonafide bug which, when corrected, would result in a solid technique with a dependable outcome.



                      The workaround:


                      Modify the calculation for window_number:


                      Though Get( WindowName ) is sometimes producing an unwanted result, the WindowNames function still reliably returns a list of window names, the first of which will be the desired name of the topmost window at the time of evaluation, i.e. the very value that we would desire Get( WindowName ) to return.


                      Sample code:



                          ~target_file_name = "Image_Issue_Interface";

                          ~window_name_list = WindowNames( ~target_file_name );

                          ~frontmost_window_name = GetValue( ~window_name_list; 1 )


                          GetAsNumber ( ~frontmost_window_name )



                      I'll attach an archive with a modified version of your files to illustrate.


                      Kudos to user19752 for calling out what I believe is the correct diagnosis.


                      HTH & kind regards,




                      Addendum p.s.:  Note that I have not tested the suggested workaround on Windows platform -- only on OS X Yosemite with FMPA 14.

                      • 8. Re: repetition by window name

                        Nice work Steve. 


                        What still concerns me is that in the original file there is a difference between FM13 and FM14.


                        Very helpful the evaluation debugging you did. :-)

                        • 9. Re: repetition by window name

                          Thank you VERY much! I tried your workaround, and so far it seems rock-solid. I simplified it just a bit by using "GetAsNumber ( GetValue ( WindowNames ; 1 ) )". So far (fingers crossed) I can't break it.


                          I'm still going to monitor this closely during development before I release this into the wild. Like you, I'm concerned about fragility.


                          This is definitely some sort of (unintended?) behavior change between 13 and 14. This worked quite nicely pre-14. I've reported it as a bug, and I'm hoping that this is one of those cases where the complexity of the issue is unrelated to the complexity of the fix, and maybe we can get this back to being as stable, and "non-workaroundy" as it was in 13.


                          Many, many thanks. I hope that in some way this method ends up being useful for you.


                          Chris Cain


                          • 10. Re: repetition by window name

                            Hi rrrichie,


                            Thank you and Chris both for the comments.


                            I do agree that the difference between v.13 and v.14 is a cause for concern.  In fact, after reading both of your replies I am now more hopeful/inclined to think of this as a bug that will be addressed in an update.


                            @Chris -- I am glad to hear that you filed a bug report.  It will be interesting to see what the response is.  Perhaps it will be acknowledged and fixed, thus leading to being able to keep this cool technique in the toolbox with confidence.


                            Best and thanks to both of you,



                            • 11. Re: repetition by window name

                              I agree that this is a bug, the function Get(WindowName) should return "the window on which the script is acting", not be affected calculation context.

                              Changing mode from layout to browse works, but there is no script running. Hmm, this function NOT return empty while no script is acting. So the defintion of function is the root bug?