9 Replies Latest reply on Jun 5, 2017 9:50 AM by Benjamin Fehr

    Bug: Setting field object as a button prevents fill and other formatting attributes from being specified


      FileMaker Advanced, MacOS Sierra 10.12.5, MacBook Pro




      Converting a field to a button by selecting it in layout mode and attaching a script using the Format > Button Setup menu item prevents you from being able to change the fill attributes. 


      How to replicate

      In layout mode, click on an edit box field. Select Format > Button Setup and attach a script to it. In inspector, the objec type will change from "Edit Box" to "Group". Then try to change the fill on the field. It is locked, and the fill cannot be changed. It also prevents you from selecting the "Hover", "Pressed", and "In Focus" states in the Inspector to change the attributes of those states. It still has those states, and in browse mode will obey whatever formatting has been specified for them previously, but will not allow you to access them to change them so long as a script is attached to the field object with "Button Setup".


      Workaround (if any)

      Make a note of any script parameter on the field. Change the button definition to "do nothing". Change the fill attributes and states you need to change. Then reassign the button and reenter the previous script parameter.


      I feel that defining a field as a button should not prevent you from being able to change its visual formatting or the attributes of its hover, pressed, or focused states.





        • 1. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified

          In FM16, you are expected to use the new Layout Object Explorer (LOE) to make formatting changes like those you've noted.  I think that was a foolish expectation, but that's just my personal opinion because I find the LOE to be very slow and something I have no patience (or screen space) for keeping open.


          Anyhow, the workaround for your issue is to use the LOE...



          There is a keyboard shortcut you can use if you prefer not to open the Layout Object Explorer.  You can click on the layout object you know to be a grouped object, and then use the tab key to tab through the group's contained objects.  In the case of a field or text object formatted as a button, you would assume there is only one object in the group (i.e. the actual field or text object), so selecting the object and then hitting the tab button once should land you on that field or text object and allow formatting.



          1 of 1 people found this helpful
          • 2. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified

            Actually, this is not a bug.


            When you make something a button, you are actually creating a group with a new object that is a (old-style) button.  The button object becomes the parent object, so when you select (the whole group) you are mainly dealing with the button object.


            As Howard suggests, you can use the new Layout Object Tree feature to focus/select individual objects regardless of grouping (I would suggest this is the preferred method for this specific case).  Or a workaround is to ungroup the button+field, which will destroy the button, make changes to the field object, then re-group the field into a button+field.   Another workaround would be to start with a (new-style) button object, and use the "merge field" syntax for the title of the button object, which can display the (text) contents of the field as the title of the button.


            Hope this helps!

            2 of 2 people found this helpful
            • 3. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified

              Thanks for the helpful replies. I see what you guys mean, but this is so idiosyncratic and counter-intuitive, even once explained, I have a hard time imagining this functional change was intentional. I understand that in v16 a single object with a script attached to it with "Format Button..." is now treated as a group of objects, but I don't see why that should be.


              Converting a single object to a group just because a script is attached on click makes no sense from a UX perspective when it is still a single object, for a number of reasons:

              1. A field that runs a script when it is entered doesn't magically become a "group"; a field that runs a script triggered when you exit it doesn't magically become a "group"; so why should a field that runs a script when you click on it magically become a "group"? Clearly things don't have to become a group to have a script attached.  While it stands to reason a Grouped object should be able to be defined as a clickable button, there isn't a functional reason why, conversely, a clickable object /must/ be a Group when other means of running scripts, including single native Button objects, aren't. Why should a clickable Button object remain ungrouped and formattable after a script is assigned but not a clickable Field object? It seems arbitrary.
              2. There is in fact no other such thing as a single-object group in FileMaker, outside of this one peculiar instance that behaves only somewhat like one - not even when using the actual "Group" command, which ought to encompass all Grouping functionality. If you select a single object, the "Group" command (or the equivalent keyboard command shortcuts) aren't even available. So it should stand to reason that there is no such thing as a one-object group. And yet, assigning a script on click (but not through the script trigger UI's onObjectEnter, which functionally is almost identical), which really doesn't seem connected with object grouping feature from a UX perspective, creates a "one-object group".
              3. If I recall correctly through the mists of time, the only reason for the use of Grouping in conjunction with single-object buttons at all is a throwback to decades ago, before there were no native Button objects and buttons had to be built of combined text and graphic objects. When native Buttons were introduced, they kept the "Ungroup-to-unassign-script" behavior, already a counterintuitive behavior at that point, and other than that, native objects formatted with "Format Button..." stopped behaving like groups in any other way. So, why are we now reverting to FM3 behavior? And only for one method of triggering scripts via object interaction, and not the other?


              Functionally, I don't see how you can say "Format Button..." is grouping an old-style button with or over the field you're attaching the script to. That's not how it behaves in any way. You don't get the Button object formatting options in the inspector, either for the group as a whole or for its (in this case single Field object) sub-object, nor does anything about it have most of the other features of Button objects. And it doesn't behave like a Group in any way either, except, impractically, that it for some reason can't be formatted without hitting the "Ungroup" command first. I know the Layout Object list calls it a "group", but should Layout Object list terminology determine object behavior, rather than the other way around? Either way, they could have kept the pre-v16 behavior that they'd always had, that still didn't really have to impact the Layout Object navigator. I'm really not clear on why either change necessitated the other.

              If all that detail bogs you down, here's a bird's eye take on it: I understand, from the perspectives of FileMaker's programmers, what's happening here. But, what if a new user asked you, "What is a 'Group' in FileMaker's layout mode?" The answer to that question used to be simple: "A Group is several layout objects joined together to be moveable or resizeable as one. A script can be assigned to them and they can be ungrouped to be moved or resized separately again." What's the answer now? It starts with "A Group is one or more layout objects..." Which means, the word "Group" in FileMaker now means something different than the word "group" in English. IMHO that's either poor UX design, or a bug.


              So, on a practical level, the tip of hitting the Tab key actually is a usable workaround - thanks for that. But the new behavior, while making layout work harder, makes no meaningful sense.


              In the age of script triggers, it just seems odd to me that one way of assigning a script from an object, but not the others others, as of v16 requires that object to now be treated in every way as a group of multiple objects. Why should you have to call a single field a "group", and be unable to format it, or choose a new source field or table occurrence for it, just because there is a script attached to it through for one particular action, and not for when they're attached by all the other actions that can trigger them for the same object? It seems like an unnecessary change, making simple changes more difficult in v16 without providing any additional benefit over the previous way of doing things. I just can't see any advantage or good reason for the new complications in v16's behavior. That really looks like a bug to me.


              I should point out, I posted because it became a practical issue. I'm working on a legacy solution where many field objects were formatted as buttons in a previous version of FileMaker. Going forward with new development it will be easier to avoid this pitfall, but working on large legacy databases is a common need.  Deleting and redefining complicated parameter calcs just to apply formatting to the fields became a pain after we upgraded to v16. Hitting "tab" isn't a pain, but it's still an extra step, and not in any way an intuitive one, so I'd be very curious to know, if this really isn't a bug, what advantage we're gaining for having to jump through an extra hoop. What was the thinking behind this?


              I know FM Inc. staff read these and occasionally respond - I'd love to hear whether this new behavior was indeed intended or not, and if so, what advantage it provides. It seems really idiosyncratic.


              The funny thing is, I've realized since, it's possible to completely restore the old behavior. Just assign the script with an "onObjectEnter" trigger instead of "Format Button...". Then, have the script exit with a value of False. Violá, you now have something that is in every functional way identical to how "Format Button..."-ed fields worked in v15 and before, and still formattable with the field formatting options, including Hover, Pressed, and Focus states, with nothing "group"-y about them. This shows the new forced-"group" behavior wasn't necessary.


              Note: someday I'm going to figure out how to write short posts on here. (Applications for position of personal forum post editor currently being accepted. No pay, but perks negotiable.) Until then, as always, thanks for all respondents' time and consideration.

              • 4. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified

                Ok, I found another drawback that none of the above solutions solves.


                The legacy solution I'm working on allows users to upload related videos. Each record has a large number of container fields, each of which has a script attached so when the user clicks it, it prompts them to choose a video file to insert into that field. It uses a single script, and passes a unique parameter to the script so it knows which field called it, rather than having dozens of separate scripts. 


                The thing is, the fields are all formatted to display JPEGs, not interactive content. So, no problem, right? I selected them all, went to the Inspector to change the fields to Interactive and.... I couldn't. I had to select each field individually, hit Tab, change the type in the Inspector, then repeat for the next field... many times.


                In FM15, I could have selected them all and changed them at once... a single drag and one click to change all the fields, instead of now two clicks and one keypress /per field/. So this new  v16 behavior is definitely a decrease in usability, for no apparent benefit. 's


                I still think this is a bug, can't see why it would be introduced intentionally. It's not in the v16 release notes or behavior changes documentation.

                • 5. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified
                  Benjamin Fehr

                  I wouldn't agree to call this a bug. It's a change of design, - the way you have to go to achieve a result you did differently in the past.

                  I can't see any of the issues described above which couldn't be solved with the newly introduced 'Objects Editor Window' (LayoutObjectEditor).

                  • 6. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified

                    Agreed. NOT a bug. Objects turned into buttons have always been grouped. Different method of viewing/editing these is better.

                    Script Triggers are attributes for an object. So Field is not 'grouped' if it has a trigger.

                    Great discussion, though.


                    Sent from miPhone

                    • 7. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified
                      Benjamin Fehr

                      seems like the folks have to learn and appreciate the new opportunities with the new LayoutObjectEditor

                      Bildschirmfoto 2017-06-05 um 12.18.46.png

                      • 8. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified

                        1) Layout Object Editor does it all? I disagree that the Layout Object Editor solves all the problems noted by kupietz.  In particular, I've found that I am unable to select multiple "button-enclosed" objects at a time, presumably because they are each enclosed under separate buttons.  I believe this is a bug, though TSGal suggests that I should specially request as a new feature such behavior that was so simple in 15: Can't format multiple buttons


                        2) Button vs Trigger: And then efficientbizz and kupietz seem to disagree on whether buttons should:

                        • a) retain their old "button group that behaves as a single object" (as in prior to 16), or
                        • b) have the new "button group that functions like a one-item group" (as in 16), or
                        • c) behave like a script trigger, where buttons are just an object (text, field, rectangle, whatever) with a new "onClick" trigger.

                        The least disruptive and most obvious to me would be (c) because it fits into the newer trigger model, would avoid these artificial groupings, and would better follow the web javascript model.


                        3) Layout Object Editor Disadvantages: What do I have against this new feature in 16?  It's slow.  Dead-ass slow.  On any kind of complex layout with multiple popovers or tabs/panels, there seem to be too many objects for LOE to handle.  I find myself selecting an object and then having to wait 3-4 seconds for the LOE to adjust to my selection.  They'll eventually fix that, I'm sure, but this and the screen space it takes prevents me from keeping it open.  Also (again presumably because it is a still-in-development v1 feature), it lacks much functionality beyond acting as an object selector; I still have to go back and forth between the LOE, the Inspector and even the menus (seems to now be the only way to edit a button definition for a field, text or other buttonized non-button object).

                        • 9. Re: Bug: Setting field object as a button prevents fill and other formatting attributes from being specified
                          Benjamin Fehr

                          I just take the new LOE as it is: Well thought, but not yet finished.


                          What do I have against this new feature in 16?  It's slow.  Dead-ass slow.

                          Déja vue: Scriptwork Space, Data Viewer, Debugger, …