SegmentedControl fails to trigger focus change

I notice that in both Desktop and Web editions, clicking on a SegmentedControl fails to remove the focus of a field that has focus, unlike a Button, where the latter does indeed remove the focus of a field that has it. Is this expected behavior? I have filed a Feedback Case 46930 on it, but now wonder if this is expected.

This has the undesirable effect of the field that has focus not getting its LostFocus event handler fired when clicking on a SegmentedControl.

A simple test showed me that a Button doesn’t cause a TextField to lose focus and trigger LostFocus here on Mac with Full Keyboard Access set to “Text boxes and lists only”

Ok. I just tested both Web and Desktop editions on a Mac and notice that, indeed, the Desktop edition fails to remove focus from the TextField when pressing a Button, but the Web edition does remove focus from the WebTextField when pressing a WebButton. In both editions, the SegmentedControl fails to remove focus from a text field when clicked.

Right - its not necessarily supposed to get focus on a click
Nor do pushbuttons

[quote=315100:@Norman Palardy]Right - its not necessarily supposed to get focus on a click
Nor do pushbuttons[/quote]

Though SegmentedControl has a GotFocus event handler.

With Full Keyboard Access on Mac set to “All controls” you can tab into a Segmented Control.

Sure - there ARE ways to move the focus to it - clicking a segment isn’t one

In a desktop app a click may move focus but it also may not (the web may move focus but I’m not 100% sure - @Greg O’Lone could say better than I could)

On OS X turn on full keyboard access (as Tim described)
Then press tab
Eventually it WILL get focus - and the got focus handler will be executed
As will lost focus

You can manipulate the control entirely with the keyboard this way

If you have that OFF then no it wont get focus - and clicking doesn’t put focus on it
It just executes the “Action” event

Exact same as a pushbutton in this regard

Dont mistake clicking an item (like a pushbutton) for ALWAYS moving focus - thats not true

And if you’re relying on “LostFocus” to do some handling of values in text fields etc then you need to rethink since a person could edit text, push a button and there wont be a “lostfocus” so you need to deal with the value as it exists right now in whatever code you have

Been there done that and that was actually one of the very first bugs I fixed in the old IDE’s way way back when
You could change a value in the inspector, press run and that new value was NOT used as entered but as it existed before you edited it

[quote=315105:@Norman Palardy]Dont mistake clicking an item (like a pushbutton) for ALWAYS moving focus - thats not true

And if you’re relying on “LostFocus” to do some handling of values in text fields etc then you need to rethink since a person could edit text, push a button and there wont be a “lostfocus” so you need to deal with the value as it exists right now in whatever code you have.
[/quote]

Well, this is certainly an eye opener. I have been relying on the fact that clicking a WebButton does indeed cause an active WebTextField’s LostFocus event handler to fire.

The situation where I rely on this is a sort if spreadsheet layout where the user enters numerical values for each day of the current week and they see a total for the week update on the screen. Each time they leave one of those 7 Day WebTextFields, the WeekTotal WebTextField updates its value. I had initially thought I would need a Refresh button to accomplish this, but even with slow connections, there is almost no latency during these updates, so I went with a more automatic way of updating the WeekTotal WebTextField.

When the user is ready to save the data on the screen to a database file, they press a SaveData button. Right now, even if a field is still active (has focus), the SaveButton removes that focus and triggers that field’s LostFocus even handler.

Sounds like I need to rethink this, especially since a WebButton removing focus of an active field may not be considered desirable behavior by Xojo engineers (because that doesn’t happen on the Desktop), and they may change that later.

I’ll edit my comments as I should have prefaced them with “This is certainly true on the desktop and may also be true on the web”
Greg could answer that better than I can

As I said relying on “lost focus” may not work in any event - certainly not in a desktop app
Suppose a person edits some data and presses save and that doesn’t cause a lostfocus ?
You’d have trouble

As I said this was one of the first bugs I fixed in the old IDE way way back when

[quote=315124:@Norman Palardy]As I said relying on “lost focus” may not work in any event - certainly not in a desktop app
Suppose a person edits some data and presses save and that doesn’t cause a lostfocus ?
You’d have trouble.
[/quote]

I imagine I am better off relying on TextChanged instead of LostFocus for this. That event handler seems to happen pretty fast.