I implemented the

cix.css.Runtime

class to basically fix the styling issue

Also - I was definitely not ignoring the XMLParser you were pointing out earlier. I did end up looking more into what was going on and it was far more involved than what I originally said. I don't think it would actually be as easy as I originally thought to make a more "HaxeUI-native" implementation like I thought. I'll be working closely with all this though so if I find that it makes a lot more sense to go that direction I'll start looking into it more seriously again

@bright-gpu-74537 euhm; Should menuItems be created on macro build ? Because I have the field(i.e. the field with the name of the id of the menuItem in the class) but when I try to do @:bind(menuItemName,MouseEvent.CLICK) it is always null and it crashes the app.

it shouldnt crash, can you share an example? What backend?

MouseEvent.CLICK is the wrong event though

(i think)

hmmm, actually, maybe it is the right event... I thought it was something like "MenuEvent.SELECTED"

can you share an example then?

ah, yeah, it is... its

MenuEvent.MENU_SELECTED

... it should bubble all the way through the menus...

so you can do:

@:bind(mainMenu, MenuEvent.MENU_SELECTED)

and you'll get an event no matter what menu item is selected, saves having to have loads of @:bind's

that said, it certainly shouldnt crash... it should work, its just a longer way of doing it... so can you share some source possibly?

I will work tomorrow(unrelated to haxeui). Will share something sunday(my Sunday probably your monday). I think the issue is I am trying to do it per menuitem instead of the whole menu.

sure, whole menu is "easier" but at the same time, single menu item should also work too - its not the way i would do it, but that doesnt mean it shouldnt be possible, and it certainly shouldnt crash

actually, i just thought of something, maybe per menu item isnt actually possible... they might not exist in the class ready for binding, let me confirm

OK, so yeah, you cant bind to individual menu items as they are created on demand (ie, when the menu is shown) which means there isnt anything to bind to until the menu is actually ever show, so you have to use something like this:

that said, it shouldnt kill the app if you bind to something non existent, so ill add a check there and spit out a warning.

(ok, shouldnt kill the app now, should issue a warning in

haxeui-core:1.0.8

)

Running through the three test cases I've submitted and put on github - have had to update them (see notes about earlier changes here in #565569107701923852 from @quick-king-64105) - should I push the changes I make for them to build with current haxeui-flixel and notes? [Edit: I pushed them. The two about actual errors are still valid.]

Right now seeing several things actually work how they should, but you might have a fourth test case soon :/

... What I keep noticing is that buttons are a little strange.

Attempts to set properties seemed to act in unexpected ways, too, but that's still on my "come up with a concrete testcase" pile right now.

Those two are from the

flxsubstate

testcase. The source for them right now is just:

xml
    <button id="open-substate" left="100" top="400" text="Open Substate" />
    <button id="overlapped"    left="200" top="400" text="Overlapped" />

inside the xml used to generate that state. Edit: There is now an issue in tracker for this, please see below.

... Textflownull still crashes. 😦

Cantstopwontstop still can't stop, won't stop.

Pushed updates to github, about to hit up those error reports and update them, too 😦 [edit: done]

textflownull update comment:

cantstopwontstop update comment:

That last one comes with a workaround that seems to work, if other people were affected by it might try it.