I noticed an oddity in my chatbox. With this window, once activated I would like to keep keyboard focus. This normally works, but when I have a ComboBox attached to the same screen, and I call anything that might invoke ComboBox.pack(), the combo will steal the keyboard focus. It looks like a bug in Menu, and so far the only solution I have is to comment out …
[java]
@Override
public void controlScrollHook() {
highlight.setY(scrollableArea.getHeight()+scrollableArea.getY()-(currentHighlightIndex*menuItemHeight)-menuItemHeight);
// if (getCallerElement() != null)
// screen.setTabFocusElement(getCallerElement());
}
[/java]
No doubt this breaks something. Here is the full trace from pack() if it helps …
[java]
at tonegod.gui.core.Screen.setKeyboardElement(Screen.java:2411)
at tonegod.gui.controls.text.TextField.resetTabFocus(TextField.java:951)
at tonegod.gui.core.Screen.resetFocusElement(Screen.java:2397)
at tonegod.gui.core.Screen.setTabFocusElement(Screen.java:2359)
at tonegod.gui.controls.menuing.Menu.controlScrollHook(Menu.java:766)
at tonegod.gui.controls.scrolling.ScrollArea.scrollYTo(ScrollArea.java:335)
at tonegod.gui.controls.scrolling.VScrollBar.setByThumbPosition(VScrollBar.java:408)
at tonegod.gui.controls.scrolling.VScrollBar.scrollYTo(VScrollBar.java:334)
at tonegod.gui.controls.scrolling.ScrollArea.scrollThumbYTo(ScrollArea.java:320)
at tonegod.gui.controls.lists.ComboBox.pack(ComboBox.java:285)
[/java]
RR
I think the issue is that pack() re-selects the first?? item to make sure it has a selected index.
I’m in the process of compiling my todo list atm and will get on this. I have 2 thoughts about how to stop this, however… until I am able to test the ideas… no telling if either will work properly or which one is the better solution.
Solution 1:
Only update the selected index if the end result no longer contains the current index or the control is just being initialized.
Solution 2:
Check where the focus call is coming from (internal/external) and only steal focus if it is user driven or does not have a current selected index.
However, either way I still think I can limit the focus to certain actions. I think…
@t0neg0d said:
I think the issue is that pack() re-selects the first?? item to make sure it has a selected index.
I’m in the process of compiling my todo list atm and will get on this. I have 2 thoughts about how to stop this, however… until I am able to test the ideas… no telling if either will work properly or which one is the better solution.
Solution 1:
Only update the selected index if the end result no longer contains the current index or the control is just being initialized.
Solution 2:
Check where the focus call is coming from (internal/external) and only steal focus if it is user driven or does not have a current selected index.
However, either way I still think I can limit the focus to certain actions. I think…
Thanks for the pointers. Re: solution 1, is this roughly what you mean? It seems to work 
[java]
public void pack() {
if (selectedIndex == -1) {
setSelectedIndexWithCallback(0);
}
else {
if(DDList != null && selectedIndex > DDList.getMenuItems().size()-1) {
int rIndex = DDList.getMenuItems().size()-selectedIndex;
float diff = rIndex * DDList.getMenuItemHeight() + (DDList.getMenuPadding()*2);
DDList.scrollThumbYTo(DDList.getHeight()-diff);
refreshSelectedIndex();
}
}
}
[/java]
I wondered if it was possible to avoid the call to scrollThumbYTo() by testing if it was already at the required position, but I couldn’t find a good way to determine how much a ScrollArea has actually been scrolled.
Seems I spoke to too soon, the above hasn’t fix it. This is a bit odd, but it seems to be having an effect on flycam too.
Say I’m holding down the W key to move forward through my scene. When it hit a certain location (a boundary of a tile actualy), I have some code that will then adjust the combo box’s selected value (it doesn’t adjust layout or contents of the list). This causes the combobox to get focus and seemingly “take over” the keyboard input.
Now if I release the W key, the flycam thinks I am still pressing it and I continue to move forward, even after removing focus from the combobox. After this point, the flycam is completely confused, movement becomes hard, with keys somtimes sticking, and sometimes unstick themselves.
Any ideas? In general, I wouldn’t expect any programmatic manipulation of any control to grab focus. Is there a good reason it does?
@rockfire said:
Seems I spoke to too soon, the above hasn't fix it. This is a bit odd, but it seems to be having an effect on flycam too.
Say I’m holding down the W key to move forward through my scene. When it hit a certain location (a boundary of a tile actualy), I have some code that will then adjust the combo box’s selected value (it doesn’t adjust layout or contents of the list). This causes the combobox to get focus and seemingly “take over” the keyboard input.
Now if I release the W key, the flycam thinks I am still pressing it and I continue to move forward, even after removing focus from the combobox. After this point, the flycam is completely confused, movement becomes hard, with keys somtimes sticking, and sometimes unstick themselves.
Any ideas? In general, I wouldn’t expect any programmatic manipulation of any control to grab focus. Is there a good reason it does?
I should be able to fix this… just need to know if you are using Form for tab control between elements.
Awesome 
In this case, yes, although it is a small form of currently 2 controls.
@rockfire said:
Awesome :) In this case, yes, although it is a small form of currently 2 controls.
It may be the use of Form that is jacking your keyboard input. I’ll see what I can do about getting this to play nicer. Hopefully just fix it… but, let me have a look. Currently, I’m rewriting the ScrollArea control (ScrollPanel) which is FAR MORE USER FRIENDLY than the existing… easy to place elements/text and has both vertical and horizonal scrolling. As soon as I finish up the draft of the new control, I’ll try and get this sorted out.
@t0neg0d said:
It may be the use of Form that is jacking your keyboard input. I'll see what I can do about getting this to play nicer. Hopefully just fix it... but, let me have a look. Currently, I'm rewriting the ScrollArea control (ScrollPanel) which is FAR MORE USER FRIENDLY than the existing... easy to place elements/text and has both vertical and horizonal scrolling. As soon as I finish up the draft of the new control, I'll try and get this sorted out.
Thanks! You got it, it’s the the Form causing the problem. I do use Form in quite a lot of places (keyboard navigation is important to me), but at least I know what the symtoms and how to work around it now.
Great news on the scroll improvements, I’ll comment in the other thread.