Summary

Button action is unreliable in List View

Product

FileMaker Pro

Version

12

Operating system version

OSX

Description of the issue

Buttons on a list view cannot be relied upon to act when clicked. Based on my experimentation, the rules appear to be these. If the button belongs to the current record, or if the record is fully scrolled into view, then the button will do what it is programmed to do. Otherwise, the effect of clicking the button is that the owning record becomes the current record and it is scrolled into view.

I imagine that this seemed like a good design decision at the time it was made, but it isn't. Consistent behavior of user interface elements should take priority over the other concerns that motivated this design decision.

A workable alternate solution, if you're really set on preserving something like this, has two parts:
1. If a button isn't going to act, then it should not highlight on mouse over. The way it currently highlights is false advertising.
2. Provide an opt-out for developers like me who have good reasons to need a button to do its thing even when the whole record isn't in view.

(In my case the buttons are for insertions and order changes at the boundary between two records, so the user is focused on the boundary and is not interested in seeing the upper record in its entirety. The button's scrolling effect is quite disorienting and the user has a hard time telling whether the insertion or order changed happened. Very bad user experience.)

Steps to reproduce the problem

Make a simple table. Edit its layout to have a button on it that beeps, and make each form fairly tall, e.g. 1/4 of screen height. Go to List View. Experiment with clicking the beep buttons. You'll find that when a non-current record is scrolled off the top, its beep button fails to beep.

Expected result

All beep buttons should beep.

Actual result

When a non-current record is partially scrolled off the top, its beep button fails to beep, and instead selects the record and scrolls to it.

Workaround

A big problem with this bug is that there is, as far as I know, no way to compensate for the behavior in scripting. FM heads off the button action before I can do anything about it.

I cannot reproduce this behavior on my windows systems and as I use buttons a lot in list view, I'd have reported this a long time ago if I did experience this. It seems odd that no other Mac user has posted this issue much earlier.

Have you tried this in a small brand new, created from scratch text file to see if you get the same behavior? Perhaps there is a problem with your file.

Thanks for your reply, Phil. Interesting that it doesn't happen on Windows. I can replicate the problem when I quit and restart FM Pro 12 Advanced and build a fresh file. I'd share the database file, but I don't see a way to do that in this forum, so here's a screen shot. In the screen shot, only the middle two "beep" buttons will beep on first click. The top and bottom ones don't beep: instead the owning record becomes current and scrolls into full view.

As an additional experiment, I made a copy of one of my list view layouts, made the buttons several rows of text taller and made the body taller to increase space between the buttons as well, then scrolled the window to make sure that the bottom row button was only partially visible. When I clicked this button, it still worked normally.

What happens if you specify a different style when the button is pressed? In my OS X solution the button displays a blue border when pressed and it seems to work fine. The list still moves but the action assigned to the button is executed.

I have just confirmed the issue. It happens when the window has just been resized and the buttons are clicked rather briefly. If I hold the mouse button a little longer the action assigned to the button seem to execute more frequently but not reliably.

I resized the window so that the button at the bottom of the window was partially visible. I rapidly clicked the button and noticed the the button scrolled fully into view before the script performed by the button when ahead and changed layouts correctly. Since I'm testing on a windows platform, this could be platform specific if we can only get it to happen on mac systems.

The other thing that might be worth checking is the type of layout object set up as a button and what options are selected for when the button is clicked. Mine is performing a script.

Phil, I have tested it on a Mac. The problem is that this issue cannot be re-created consistently. Sometimes the script is executed and sometimes the list simply moves. The easiest way to confirm the issue is to make the windows smaller and move the slider just before clicking on the button. The good news is that I haven't been able to reproduce the issue after deselecting the 'change to hand cursor over button' option. Hopefully Chris can confirm this workaround.

OK, now I see what it is. The button performs a select-and-scroll on mouse-down, and the button action on mouse up. If scrolling moves the button out from under the mouse, then mouse-up doesn't happen and the action doesn't fire.

You can actually get the action to fire if you keep the mouse button pressed and get back over the button before you release the button. CodeCruncher's comments inspired me to try this.

Regarding the hand cursor over button setting, I've had that deselected all along. Selecting it makes no difference in click response behavior that I could detect.

Now that I see the mechanism, I'm thinking this was probably not a conscious choice by FM implementors--just an unintended consequence of the event handlers used.

It's nice to put in an issue report and get such prompt attention. I don't recall having this experience with Apple, for example. I gather that you're on FileMaker's QA or dev team, CodeCruncher? And PhilModJunk, I read somewhere that you are a private citizen and a leader in this community. Thanks to you both!

So, it's helpful to better understand what the problem is, and I look forward to seeing it fixed in FMP13. Meanwhile, I don't see a lot of options for workarounds. For example if I could get list view scrolling to snap to a record boundary at the top, that would prevent users from seeing buttons they can't click (because in my particular case, the critical buttons are right at the bottom of each form). Or if I could catch the mouse down event I could prpobably do something useful. Got any ideas? At this point I'm figuring I may just have to explain the behavior to my users.

Chris,
While PhilModJunk is the real deal I am merely a dude with a laptop who likes crunchy cereal in the morning. Codecruncher simply sound more grandiose than cerealcruncher...

To work around your problem you can create an invisible button underneath a virtual button. The invisible button should cover the entire height of your record row. Give this button an invisible border and simply change the color of the invisible border in the 'pressed' state (the border is still invisible although the color display will change in the inspector). This will ensure that the invisible button will not change in any way when it is being clicked upon. Attach your script to the invisible button. The only downside is that you cannot change the state of the virtual button above the invisible button to indicate when it is being pressed. After all the virtual button is not a real button but merely looks like one.

Wait...I ran out of milk this morning so you have to excuse my incoherent rambling. I have attached a screenshot to show the setting of your border of the invisible button. The border is not invisible but has 'none' selected in the drop down menu of the 'Line'. Simply change the color in the 'pressed' state.

Hi CC. Thanks for the idea. I also thought about a tall invisible button to catch the upclick, but I anticipate a couple deal-breaking problems. One is that these buttons do rather major operations that should never be triggered by clicking in what looks like empty space: the only thing worse than the visible button not doing it when you expect would be an invisible button doing it when you don't expect. Second, it's a fairly packed layout with many interactive objects; the invisible button would have to weave under a lot of other things, greatly diminishing its effectiveness.

I hadn't really focused before on the ability to edit other object states, though, so appreciate that pointer.

Ok, we've nailed this one down to the point where it is easily reproducible. The window scroll on MouseDown action was the key detail. If you click anywhere in the body of the layout--not just the button of the record that is only partially visible on the layout, the window will scroll to display the entire record.

Once I specifically positioned my mouse so that the window scroll moves the button out from under my mouse, I could reproduce this in Windows. With a narrow button and lots of space between the bottom button and the bottom edge of the Body layout part, even very quick mouse clicks fail to perform the button's specified action.

A quick test in FileMaker 11 in Windows XP shows that this behavior exists there as well. I looks like either buttons should be triggered by MouseDown instead of MouseUp events, the code should somehow "remember" the mouse down coordinates before scrolling the window or the button action should be processed before the current record action that scrolls the window.