Disable auto keyboard control for buttons in 1.9.1?

With version 1.9.1 of Lemur there’s been a change that adds keyboard commands as default:

Upated TextEntryComponent to hook up some standard keys to focus actions for single line text fields.
Tab = Next, Shift+Tab = Previous, Enter = Next, Up = Up, Down = Down.

That’s great and all, but I’ve found that the binding persist even after the container of buttons is detached from the uiNode and the player can still unknowingly press buttons without realizing.

This sounds like a general bug that needs a full solution, but I’m on a tight schedule and would just turn off the whole thing for the time being. Any simple way to do that (while keeping textbox inputs)?

Simple work around I think would be to make sure the text field doesn’t have the focus anymore before removing it.


When the GUI elements are removed from the screen they are supposed to clean themselves up (to include relinquishing focus) so I’m not sure why that doesn’t happen.

That’s a good workaround for now :slight_smile:

If it helps for debugging: it happens on Containers with SpringGrid filled with Buttons. If a button is clicked (and gets focus) it can be activated by pressing space bar even after uiNode.detachChild(container);

If you think about it and want to be super-cool-helpful, can you file a problem report in the Lemur project?

Else I will try to remember to do it myself.

Filed. :slight_smile:

Btw, I saw you have this ticket there:

Docs:ListBox content documentation

Which reminds me I wanted to ask some things about the ListBox since I can’t find much info on it.

  • How to access the style for the embedded text labels? I can’t find a way to set the text color and size manually.

  • Is it possible to add scrolling to it via mouse wheel in some native lemur way or do I need to make an analog listener and do it there?

I can make a new thread if you think it’s best.

The ones created by the cell renderer?

Lemur doesn’t yet have native support for the mouse wheel. There was another thread on why but basically JME provides no way to query the current state. It’s on my todo list. You can put another issue in if you want to track it.

I put an issue in to track this:

I’ve just committed a fix for this to master. It will go into the Lemur 1.10 release when I cut it.

Basically, I now check the current focus every frame to see if it’s still connected to the scene graph. Not elegant but effective.

1 Like

That may be the thing yes. So I presume I have to pass in a custom cell renderer?

Eh, it’s not really an issue since I can add an analog listener just fine. I was only checking so I don’t overcomplicate things :slight_smile:

Hmm, yeah I guess there really isn’t a way to check this without editing the core Node class. I was thinking that changing parents may trigger the recursive updateGeometricState, but I checked the source and there doesn’t seem to be anything at all :confused:

Another followup for the mouse wheel, I’m having serious trouble trying to get the listbox shift up or down in code (e. g. without any mouse inputs). My guess was that calling


does the job, but it was conveniently locked down as much as possible so I had to copy over the entire ListBox and GridPanel to get access. Turns out, calling that doesn’t quite do anything at all. Does it require a refresh or something?

Had another idea for this, maybe you could just do the check before executing the keyboard commands in the listener itself. Something like:


Should work, right? And would reduce the number of checks by a whole load.

Which of potentially dozens of root nodes should do this?

The check I’ve added is very fast and doesn’t require the toe code to know what the tip of the nose code is doing.

I don’t think running this will do anything for you. For one thing, these are listeners that you would have registered if you cared about the events. For another, they are are “mouse button up” and “mouse button down” and have nothing to do with making the list go up and down.

That’s controlled by the scroll bar. If you want the list to go up and down then you’d grab the Slider’s model and move the value.

Alright yes, that was more of a pseudocode anyway. The gist of what I meant was that it would be better to have the very fast check run fewer times by putting it in the main listener instead of the update loop.

I was just trying to think of an alternative since you said it wasn’t elegant.

:chimpanzee_facepalm: Of course, I am complicating yet again. Thanks, works now! :smiley:

It’s not elegant but at least the inelegance is where it needs to be.

Doing it down where the text is processed means that every component that ever did anything based on focus would have to always check for 'am I still focused?" all the time.

Sometimes it’s too bad we don’t have access to a Spatial’s refresh flags because then I could at least skip the check if the flags weren’t set. (App states run before spatial updates… though it occurs to me that’s a frame too late. I’d have to do the check in render() instead.)

Anyway, this is what it is and seems to work.

Regarding this if you want to customize the way the cells are rendered you have two options:

  1. create your own custom cell renderer and set that on the ListBox. Whether from scratch or just extending DefaultCellRenderer.

  2. use the styling system to change the style of the default cell renderer that ListBox already uses. If everything is using the default element IDs then it should be “list.item”.