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.
GuiGlobals.getInstance().requestFocus(null);
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.
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);
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.
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
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
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
commandMap.runCommands(ListAction.Down/Up);
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:
if(event.hasAncestor(rootNode))
executeCommand();
Should work, right? And would reduce the number of checks by a whole load.
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!
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.)
Regarding this if you want to customize the way the cells are rendered you have two options:
create your own custom cell renderer and set that on the ListBox. Whether from scratch or just extending DefaultCellRenderer.
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”.
