I have a fairly straightforward container control - one DesktopListbox, a couple of buttons, and a DesktopTextField. Via the Language Reference for Xojo 2021 Release 3.1 for the DesktopTextField I stumbled on DesktopUIControl.KeyDown which says this below. What does it actually mean ? Can someone decode the gibberish to plain english ?
I just want to intercept the ASCII key codes for DELETE, RETURN and ENTER when these were pressed in the field and use these to trigger events. Any other keycode I donât care.
There is no âAllOtherControlsâ event or property anywhere⊠though I am tempted to create one for the parent window (which is a DesktopContainerControl)âŠ
NB the DesktopContainerControl is a custom class and I have already created a boolean âIgnoreAllEventsâ in other to do exactly what that impliesâŠ
TextField and TextArea Returning True means the key is intercepted, preventing the key from actually reaching the control at all. This would be useful if you want to override the behavior of the tab key for example. Returning False means the key reaches the control.
All Other Controls Returning True prevents the KeyDown event on the parent control (usually the window) from executing. Returning False results in the execution of the KeyDown event of the parent control.
You probably found that description in the DesktopUIControl docs, right? Many desktop controls inherit from that class, TextFields as well as buttons.
In text-editing controls a keydown will usually result in the key being displayed inside the control (or its action executed). So returning True here means you did all that yourself.
Other controls donât necessary have a keydown handler: Some may react in some way, others not. Returning True here means you intercepted the standard behaviour, whatever that might be.
In your case, so, simply intercept the keys you are looking for and return true if you do not want the standard behaviour to follow, otherwise return false and the fields will react as usual.
Talking about the inheritance: I did not notice the parent classes are not that clearly visible in the new docs. It would be nice to have them listed in their hierarchical order at the docâs top, not just under âSee alsoâ at the bottom.
Had dinner and revisited my code (all sorted), but the question regarding the documentation remains⊠the âAll Other Controlsâ part is totally opaque.
@Geoff_Perlman: I think thatâs a good proof for missing clear superclass information in the docs. Especially as it would help new users comprehend Xojoâs class hierarchy and class inheritance in general a bit easier.
Would it be possible to add such a line?
The superclass is listed as the first time in the See Also section on every class page. Itâs there because most users donât actually need to know the class hierarchy. They are using the control they are looking at and the page listed all the class members all the way up the class hierarchy.
By the time you need to know class hierarchy, youâre a reasonably sophisticated user (not a new user) and youâll know where to find that info.
Remember that we have balance things. More information isnât always better because the user has to wade through it all. The docs need to provide enough so that the user can easily find what they are looking for of course but too much can be a bad thing as well because it can impede the user finding what they need and it can make Xojo feel more complicated than it is.
That is so unbelievably wrong, I would never be as fluent as I am in Xojo if I wasnât aware of the class structure. PLEASE stop assuming that just because you donât need something the rest of the world doesnât.
Can you give me an example of something a user starting out would be confused by if they didnât know that a particular member of a particular class comes from a parent class?
Tim, thatâs not what Iâm assuming at all. I have spent quite a bit of time helping those new to Xojo. So I know the kinds of questions they ask. Iâm honestly trying to come up with a situation where a new user would need to know that a class member is inherited.
If you have one, please reply because Iâm struggling to think of one.
Another thing that seems to be missing is an explanation of the Xojo event model. Before rewriting my app in Xojo, it had been implmeneted as a mixture of PHP and JavaScript. I bought one of those 1000 page books on javascript, and what most repaid my efforts was reading up the DOM/javascript event model, which object gets an event, what happens to the event next, how an object prevents or allows the event to pass up or down the object hierarchy, and so on. A long explanation but worth reading in detail before floundering around too much. And if that takes 10-20 pages of text, then so be it. Iâve not found anything similar in the Xojo docs for events.
Same should apply for the class heirarchy and subclassing.
I agree. The event model in Xojo is different enough that it deserves a lengthy explanation. The main difference being that method calls are resolved bottom up, whereas events are dispatched top down. Wrapping your head around that can be challenging for a newbe. It is a very powerful model and deserves a clear and prominent explanation.
Tim - thank you for that pearl, it is exactly what the documentation should say, but doesnât.
I came from an environment where events are passed UP the class hierarchy and ultimately to the application if nothing handled it lower down - IMHO that had its merits too especially when it came to handling exceptions gracefully without crashing the app - especially important where the app might be running in a kiosk in public areas, or a museum - in some cases for many years.
But in Xojo this event model forces us to check for nil objects at the leaf level of the class tree - ie. in every method, or use âTry⊠Catchâ and the exception handling, which I find very, very tedious.
Regarding inheritance ⊠something that bugs me a bit is inconsistencies where I find one control implements an event, yet others do not. For example DesktopCanvas and DesktopListBox have a DoublePressed event, but buttons do not. The end result over several years is that Iâve replaced almost all of the Xojo controls with my own based on Canvas, or subclassed and in containers.
I donât understand this statement. Iâve never had an issue. What the Xojo model does do is allow you to have custom functionality in the super class and raise the event in the subclass at just the right time. Eg.,
Function SomeEvent as Boolean
dim handled as boolean
'do some stuff
handled = RaiseEvent SomeEvent 'raise it in the child
if not handled then
'do some more stuff
end
return handled
End Function
The inverse is with a method like Constructor, where you can do some setup, call the Superâs Constructor, and then do some more stuff.
