onRecordEditStart vs application usability

[siavash.roozbehan]

Hi All,

We have encountered a problem in our application in regards to onRecordEditStart event getting triggered inappropriately.

I have two forms open in two windows next to each other and a combobox in one of them. I click on the combobox and select a value from the list. The click will call onRecordEditStart, which is fine. After I chose the value from the list, I don’t do anything else on this form and click on my other form that is open in another window.
I have a onFocusLost function on the combobox that saves the data. So when I switch to the other form, the focus is gone and the data is saved. All good so far. Now I click on the title bar of my first window with the combobox. At this moment the focus goes back to the combobox and the onRecordEditStart event gets triggered again.

The problem is that my form with the combo has a toolbar with action buttons and when onRecordEditStart is fired, my buttons switch into editing mode - so navigation buttons get disabled and save/cancel buttons come forward.

The user is very confused at this point because they didn't edit the record and they want to go next or previous record in the foundset or maybe add a record or do whatever the toolbar should allow them. But they cannot, because they need to save or cancel now - and, again, they didn't change anything. This is when the user goes in panic mode.

Long time ago we requested to change the behaviour of onRecordEditStart to be only fired if the user changed a value, not just clicked in the field. Servoy refused to do so. Now this behaviour really lacks logic and we would like to bring up this issue again.

We already had to simulate the standard 'interactive change' event, available in FoxPro, but somehow not in Servoy. However, we could only do that on text fields with the help of the key listener plugin; simulating that on comboboxes, radios, etc. is harder because Servoy doesn't provide a mouse listener plugin. Overall, we'd be much happier if we just had the proper Interactive Change event or have onRecordEditStart only fired when data is changed.

The user experience is paramount in making an application usable, and at this point we continue to have a significant difficulty creating a usable application.

Could someone from Servoy, please, comment on this issue and perhaps look into the possibility of implementing the requested changes.

I have attached a sample solution to show this behaviour.

[jcompagner]

When you focus the field the form goes into edit, and ask the system if it can go into edit (if others have locked it or not)
so that a user gets warned as soon as possible that the edit he is going to do is going through or not.

So thats why we do it as soon as possible.

What you can try is to really focus something else when you save data (so focus the form or a button thats on the form that doesn't trigger a edit start)
But this could be hard to do because you don't really know where the user did go to i guess.

But why does the focus lost of a combo already save the data? If you would move that to be automatic or through a "save" button then this would not be a problem at all.

To change the behavior of onRecordEditStart (when it is called) is not an option, that would break all kinds of solutions that really depend on this.

[david]

What you can try is to really focus something else when you save data (so focus the form or a button thats on the form that doesn't trigger a edit start)
But this could be hard to do because you don't really know where the user did go to i guess.

For what it's worth, we used to do this all the time to control "focus" in weird situations like this. Even fire another method on the destination object to split UI code up. Sort of like a UI callback function

[maria.kyselova]

When you focus the field the form goes into edit, and ask the system if it can go into edit (if others have locked it or not)
so that a user gets warned as soon as possible that the edit he is going to do is going through or not.

So thats why we do it as soon as possible.

What you can try is to really focus something else when you save data (so focus the form or a button thats on the form that doesn't trigger a edit start)
But this could be hard to do because you don't really know where the user did go to i guess.

But why does the focus lost of a combo already save the data? If you would move that to be automatic or through a "save" button then this would not be a problem at all.

To change the behavior of onRecordEditStart (when it is called) is not an option, that would break all kinds of solutions that really depend on this.

Thanks, Johan.

We don't use focus lost to save data, it's just for the demo solution.
The point was not the saving. The point was that onRecordEditStart triggers the save/cancel buttons on our tools panel in each window. When we were editing the form with the combobox, then hit save in the same window, go to another window and return to the first one again - focus returns to the combo and triggers save/cancel buttons. The user didn't change anything but save/cancel is there, so they are extremely confused.

We understand that changing onRecordEditStart is too big of a job (although the initial design of its behaviour remains in question).

If we set the focus on a dummy label upon saving or cancelling, that seems to work. It is the idea of having to invent workarounds that bothers me. In our app, we fix infrastructure if we are convinced that the current implementation is wrong rather than working around the problem it might be causing. You know, the snowball grows bigger as it rolls..

[maria.kyselova]

What you can try is to really focus something else when you save data (so focus the form or a button thats on the form that doesn't trigger a edit start)
But this could be hard to do because you don't really know where the user did go to i guess.

For what it's worth, we used to do this all the time to control "focus" in weird situations like this. Even fire another method on the destination object to split UI code up. Sort of like a UI callback function

David, I'll invite you to look at our product when we finally release, so you can see how many things we already simulate because they're not available as native behaviour This is why I am so resistant to workaround, they undermine the stability of a software piece.

[david]

how many things we already simulate because they're not available as native behaviour This is why I am so resistant to workaround, they undermine the stability of a software piece.

You're about 7 years late to this discussion

[maria.kyselova]

how many things we already simulate because they're not available as native behaviour This is why I am so resistant to workaround, they undermine the stability of a software piece.

You're about 7 years late to this discussion

Yeah, I'm glad I am, Servoy has made huge progress since then and I've only been watching it for the last 5 years