Couple quick notes

User Code & Projects tonegodgui
1

In the process of committing some fixes…

The most notable is a fix for TextField that stop the caret position from being pushed to the end of the text field after mouse clicking to set the position. The fix is semi-temporary, as it doesn’t account for cut & paste (well… sort of… it accounts for cut… just not paste… which is currently disabled do to incompatibility issues with Android). Anyways… it does stop a major irritation for the time being.

Next is a fix for SelectList and the vertical scroll bar not showing up when the inner content exceeds the outer bounds.

I have a list from the forum that I am working off of and will be recompiling the jars soon(ish). This is in preparation for the Particle Emitter System’s release, as the visual design tool is made using this library. Why do I mention this? Because I wrote a new control that others may (or may not) find useful. If you decide to try out the visual designer and like the control… let me know and I’ll add it to the library.

What’s the control? Well…

It’s a SelectList which allows you to reorder the list using up/down arrow buttons, as well as an edit and remove item button. It’s been a staple for the latest project… maybe others will have a use for it.

I’ll likely be starting a release thread for the emitter system + visual design tool soon(ish) which will also likely contain update notes for this library.

Just a heads up if any care to know.

2

Another note:

There is an issue intermittently with the z-order of buttons being drawn properly but not being seen in the correct order with picking. I’m still unable to locate the source of the issue, however the fact that it seems to be very specific to the button class should make it easier.

In the mean time… if you stumble across this issue, you can do the following to resolve it:

[java]
// These two lines in the same update:
myButton.hide();
myButton.show();

// It basically does the following:
myButton.removeFromParent();
elementParent.attachChild(myButton); // This is JME’s attachChild, not to be confused with Element.addChild(el)
[/java]

This (for some reason) fixes the issue and picking happens correctly again…

3

I’ve added a method to Element for auto-sizing to content. I picked a very abscure name for the method, so be warned. It is:

[java]
Element.sizeToContent();
[/java]

And here is an example of using it to dynamically size a window to your components:

[java]
Vector2f pos = new Vector2f();
Vector2f dim = new Vector2f();
float padding = 7;
float dragBarHeight = screen.getStyle(“Window#Dragbar”).getFloat(“defaultControlSize”);

pos.set(padding,padding+dragBarHeight);
dim.set(100,100); // Some arbitrary size

Element innerContent = new Element(screen, “innerContent”, pos, dim, Vector4f.ZERO, null);
innerContent.setAsContainerOnly();
innerContent.setIsMovable(false);
innerContent.setIsResizable(false);

// Add all your controls to innerContent

innerContent.sizeToContent();

dim.set(innerContent.getWidth()+(padding2),innerContent.getHeight()+(padding2)+dragBarHeight);

Window win = new Window(screen, Vector2f.ZERO, dim);
win.addChild(innerContent);
win.setWindowTitle(“I’m a window”);

screen.addElement(win);
win.centerToParent();
[/java]

4
@t0neg0d said:

There is an issue intermittently with the z-order of buttons being drawn properly but not being seen in the correct order with picking. I’m still unable to locate the source of the issue, however the fact that it seems to be very specific to the button class should make it easier…

Interesting. I think I have seen this, and suspected some z-order weirdness. I had put it down to my layout code, and was on my list of things to investigate. I hope you find the problem :slight_smile:

I’ll likely be starting a release thread for the emitter system + visual design tool soon(ish) which will also likely contain update notes for this library.

Just a heads up if any care to know.

Oooh that sounds very interesting. I have been waiting with bated breath for a more capable particle system. I look forward to having a play with it! And visual design tools huh, even better.

5
@t0neg0d said: which is currently disabled do to incompatibility issues with Android). Anyways... it does stop a major irritation for the time being.

Why not use something like:

[java]
if (System.getProperty(“os.name”).contains(“Android”)) {
// Nope you can’t do this on Android
}
[/java]

Or the contrary… !contains(“Android”)
I think that would make more sense than having everyone pay for the lack/bug of an OS.

6
@madjack said: Why not use something like:

[java]
if (System.getProperty(“os.name”).contains(“Android”)) {
// Nope you can’t do this on Android
}
[/java]

Or the contrary… !contains(“Android”)
I think that would make more sense than having everyone pay for the lack/bug of an OS.

Screen has these static methods:

isWindows() isMac() isLinux() isAndroid()

The problem is the includes tank Android

7

@rockfire -
Going through the patches atm… eventually they will all likely be integrated.

Just wanted to note the LinkedHashMap catch. I really thought I had done this a long time ago. Both Element and Screen have been updated to reflect this change.

I also exposed the child elements for both Screen and Element via:

[java]
public Map<String, Element> getElementsAsMap() // and
public Collection<Element> getElements();
[/java]