DesktopUIControl.KeyDown

Xojo 2021 Release 3.1.

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…

You missed the sentence above the one you cited:

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.

@Geoff_Perlman

1 Like

Must have been having a “blonde moment”.

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?

2 Likes

It means any control which is not a TextArea and which is not a TextField.

Simples.

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.

3 Likes

I so disagree with this Geoff. When starting out you really need to understand what’s inherited and what’s not. You can’t assume anything.

2 Likes

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.

It might be more helpful if the parent class reference were worded slightly differently. I initially found it hard to comprehend. Instead of

See also: xyz parent class; abc; def

A subtle change would make it more friendly

See also: xyz (parent class); abc; def

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.

1 Like

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.