Hello, I have a button with an Action event MsgBox("button was pressed") and a listbox.
The GreatPushButton.Enable=False code is triggered from the Lisbox LostFocus event handler.
On OS X, works great.
On Windows, the code inside the button will not run, even though it looks in the UI like I pressed it. At appears that in the background the button is de-enabled before the code can run.
Does anyone else see this? And if so, is there a workaround other than putting the enable=false code in every other element in my UI?
On Windows, if you click on a button, the focus go to it, raising a listbox.LostFocus that disable the button.
It’s probably not a good idea to put this code in the LostFocus event.
[quote=322540:@FranoisVanLerberghe]On Windows, if you click on a button, the focus go to it, raising a listbox.LostFocus that disable the button.
It’s probably not a good idea to put this code in the LostFocus event.[/quote]
Indeed. On macOS, unless the user activate full keyboard control, buttons cannot be focused. I think this does explain the issue very well.
The obvious solution is to place the enabled false at the end of the button’s Action event itself.
Actually, what the OP seems to want to do, is to push the button, and then disable it. That is akin to what Xojo provides in Web with auto disable. The button gets disabled after the Action event has executed. Hence the obvious solution to disable the button at the end of it’s own Action event. That way, you are absolutely sure it takes place where and when it should.
That way he won’t have to worry about platform differences, or if the Mac user activated full keyboard support, which BTW would trigger exactly the same difficulty as described in the OP.
By accident, I activated years ago and I never was able to desactivate it. I also saw some screen shots done with the full keyboard support activated
So, when I just have to press a single Tab, sometimes I have to use the mouse (to avoid many Tab key presses ).
Conclusion: beware before activating this.
Also: this is a bad UI. Why ? Because you can have a button with the focus and another button who is the default button in the same window (or dialog or )
Don’t forget full keyboard support is essentially meant as assistive support, for instance for people who cannot use the mouse/trackpad (blind, lack of motor control, etc.).
So it is not a bad UI in itself.
To deactivate it, go to Keyboard preferences, shortcut tab, and push the radio button “Text boxes and lists only”.
[quote=323420:@Matt Peel]@ Here is the sample App. On Mac OS X, if you press the button, you get the message box; on Windows, you don’t. Dropbox link
Matt[/quote]
I tried to advise before, but seems it was not noticed.
You should never expect the order of events to be the same between platforms, or even between versions of Xojo. What happens is that obviously lostFocus occurs earlier in Windows.
Don’t disable the button in the ListBox LostFocus. Do that in the button itself, at the end of the Action event handler. It will then work identically on both platforms. And it will be a whole lot more logical. Not to mention better OOP.
To quote an authority in the matter :
[quote=108763:@Norman Palardy]Controls get their open event before the window
Thats about all you should rely on[/quote]
[quote=322630:@Emile Schwarz]Also: this is a bad UI. Why ? Because you can have a button with the focus and another button who is the default button in the same window (or dialog or )
[/quote]
Remember - Focus and “Default” are not the same thing. If you have full keyboard traversal on, the highlight tracks the focus, but any “Default” button is still the default is you hit ENTER.
This is also why Tab Indexes are so important.
And remember, just because you don’t like the feature, there are a lot of users who either need it for assistive reasons or simply appreciate not needing to grab the mouse every time they need to interact with the app,
