Hello, me again :D.
I think there are 2 problems with the drop down list boxes in the gui:
- add one to a scrollAreaAdapter and it is moved correctly, but the part you click to have it show it’s content is not hidden, clipped, or something when out of the scroolAreaAdapter display area (I mentioned it already… just a reminder).
- add one to a scrollAreaAdapter, add the area to the window, add the window to the screen. When you remove the window from the screen, the cleaning of the combos throw an exception:
Apr 5, 2013 4:08:01 PM com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.NullPointerException
at tonegod.gui.core.Screen.removeElement(Screen.java:288)
at tonegod.gui.controls.lists.ComboBox.controlCleanupHook(ComboBox.java:581)
at tonegod.gui.core.Element.cleanup(Element.java:1877)
at tonegod.gui.core.Element.cleanup(Element.java:1879)
at tonegod.gui.core.Element.cleanup(Element.java:1879)
at tonegod.gui.core.Element.cleanup(Element.java:1879)
at tonegod.gui.core.Screen.removeElement(Screen.java:299)
at manictubes.appstates.welcome.screens.GUIAbstract.close(GUIAbstract.java:29)
I suspect it has problems when not put inside a scrollarea too but didn’t test it… I can if needed.
Don’t get mad at me :D.
The gui is a delight to use, btw.
@loopies said:
Hello, me again :D.
I think there are 2 problems with the drop down list boxes in the gui:
- add one to a scrollAreaAdapter and it is moved correctly, but the part you click to have it show it’s content is not hidden, clipped, or something when out of the scroolAreaAdapter display area (I mentioned it already… just a reminder).
- add one to a scrollAreaAdapter, add the area to the window, add the window to the screen. When you remove the window from the screen, the cleaning of the combos throw an exception:
Apr 5, 2013 4:08:01 PM com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.NullPointerException
at tonegod.gui.core.Screen.removeElement(Screen.java:288)
at tonegod.gui.controls.lists.ComboBox.controlCleanupHook(ComboBox.java:581)
at tonegod.gui.core.Element.cleanup(Element.java:1877)
at tonegod.gui.core.Element.cleanup(Element.java:1879)
at tonegod.gui.core.Element.cleanup(Element.java:1879)
at tonegod.gui.core.Element.cleanup(Element.java:1879)
at tonegod.gui.core.Screen.removeElement(Screen.java:299)
at manictubes.appstates.welcome.screens.GUIAbstract.close(GUIAbstract.java:29)
I suspect it has problems when not put inside a scrollarea too but didn’t test it… I can if needed.
Don’t get mad at me :D.
The gui is a delight to use, btw.
Thanks a ton for reporting this… gonna give it a try and see what I can find for a fix!
Ah… I think I see where the problem is… just not what the problem is. Is has something to do with the dropdown list removal. This may be related to the current updates with autogenerating UIDs, though I thought I took care of this… time to test!
@loopies
Ok… here is the test that I ran and these are the results. Let me know if I did something different than you.
[java]
ScrollAreaAdapter sa = new ScrollAreaAdapter(screen, new Vector2f(10,40));
ComboBox cb = new ComboBox(screen,new Vector2f(10,40)) {
@Override
public void onChange(int selectedIndex, Object value) { }
};
cb.addListItem("Test", "Test");
sa.addScrollableChild(cb);
Window w = new Window(screen,Vector2f.ZERO);
w.addChild(sa);
screen.addElement(w);
screen.removeElement(w);
[/java]
I see the clipping issue with the button. I’ll try and get that patched today.
However… when I added the removeElement line, everything worked as it should. What is different about my example, so I can run the correct test… I believe I created and added the components in the order you listed.
I’m sorry, after tests, it only happens when a combo had no list items. Sorry for pointing in the wrong direction.
Thanks a lot for your help.
@loopies said:
I'm sorry, after tests, it only happens when a combo had no list items. Sorry for pointing in the wrong direction.
Thanks a lot for your help.
I may have missed tonights build, but the update that fixes this has been committed.
When adding a child element, the method was calling
[java]
child.setClippingLayer(this); // effects a single element
[/java]
when it should have been calling:
[java]
child.setContolClippingLayer(this) // recursive throughout all children, unless specifically overriden.
[/java]
1 Like
The remove error has been fixed as well.
1 Like
Ooooh, great news, thanks a lot. I’ll be patiently awaiting new build. “Patiently” :D.
1 Like
@loopies said:
Ooooh, great news, thanks a lot. I'll be patiently awaiting new build. "Patiently" :D.
On the subject of clipping and this control in particular. I ran a test to see if scrollareas could contain other scrollareas. There are some very odd results (it works, however the setControlClipLayer overrides the original scrollarea’s call for it’s children), so (at least currently) this doesn’t seem to work properly. I’ll eventually revisit this to see if there is a solution.
Random thoughts for self on this issue:
- The scrollarea may be setting the clipping on itself instead of it’s child elements. If this is the case it should fix the issue.
- I was under the impression that the inner scrollable area blocked controlClipping calls. I may have been wrong =)
Also ran a test to see what would happen if you add a control to 2 separate parents. It doesn’t create a fatal error, however, it has odd results as well. I can’t image someone doing this… so, it was more of a curiosity thing. I was however suprised that it didn’t take the app =) JME obviously accounts for this on the Node level… and I guess this UI should probably do the same:
Remove the reference from the previous parent prior to adding the element.
It seems that selectbox (and probably all combos) can’t be disabled, as in: not allowing to not allow the user to change the selected element in the drop down list.
The setIsEnabled method called is the one of the TextField that the combo extends. Guess would need to overwrite that method so it disables the button associated with the combo instead. Problem can be bypassed by only feeding the element you want to allow to the combo, but think would make the gui more intuitive. Not a breaking problem though.
@loopies said:
It seems that selectbox (and probably all combos) can't be disabled, as in: not allowing to not allow the user to change the selected element in the drop down list.
The setIsEnabled method called is the one of the TextField that the combo extends. Guess would need to overwrite that method so it disables the button associated with the combo instead. Problem can be bypassed by only feeding the element you want to allow to the combo, but think would make the gui more intuitive. Not a breaking problem though.
I’ll be resolving the disable option for all form based controls really soon! The concept of disabling somehow escaped me when I first started working on form controls =)
Happy to report that the removal of empty combos and the display of them in a scrollArea now works perfectly. Thx!
1 Like