yeah, ive fixed it all now, just making toggle dispatch clicks too... will commit shortly

btw, that autoDispatch is just so the behaviour knows to dispatch an event when its value changes, ie, when you call

.selected

, the other issues were related to linking up native events and mapping them to haxeui events

that feels better

Interesting, between the events elements , the handler elements, and the autotdispatch, I admit I don't understand much haha. Great Work !

alright, pushed

yeah, the native stuff can get complex, for sure... iirc the autodispatch is just a lazy shortcut i added to save myself from having to dispatch the event manually in code

its only used in hxwidgets i think

What's the use of

<event id="change" native="EventType.TOGGLEBUTTON" class="haxe.ui.events.UIEvent" />

?

so this basically says, when the user (you) request to add a haxeui "change" event (UIEvent.CHANGE), rather than having to map that manually, we'll map it to a wx TOGGLEBUTTON listener, and when it gets dispatch, well create a UIEvent and dispatch that to haxeui listeners

this drives that, essentially:

haxe
        var native:String = nativeConfigQuery('component[id={className}].event[id={param1}].@native', type);
        if (native != null) {
            var eventType = EventTypeParser.fromString(native);
            if (eventType != 0) {
                if (_eventMap.exists(type) == false) {
                    _eventMap.set(type, listener);
                    window.bind(eventType, __onEvent);
                }
                return;
            }
        }

Okay, I was suddenly confused. lol . I though it was both in the dispatched event in the handleer, but that's the click. Okay, makes sense 🙂

again, mostly all of this is shortcuts, it used to all be done in code, especially during the PoC stage, but mapping things gets old real fast 🙂

Yeah, it's a great system for all the boiler plate code. Plus just by looking at native.xml, it's really easier to see what features are implemented or not.

yeah, when done purely in code (no config) it gets overwhelming fast, and as you say, tough to see whats doing what... although, saying that, i was just adding to the Toggle entry and not understanding why it wasnt working, so there is always room for dumbness and looking with your eyes closed 😄

Haha, it happens to the best of us.

And just when you thought it was safe he's back with another question 🙂 I am creating a point-light component to house the controls of a point light. This means it will include instances of my labelled-slider and other components. So it extends VBox and it renders fine. What I cannot get to work is in my main UI.hx class I added a member variable

@:bind(uiPointLight2)
    public var pointLight2(default, null):PointLight;

and I get

haxeui-core/git/haxe/ui/macros/Macros.hx:356: characters 21-66 : haxe.ui.util.Variant should be ui.PointLight
Source/ui/UI.hx:20: lines 20-420 : ... Defined in this class

The class is listed in module.xml. This happens on html5 and hl. So question, am I not able to define a field in the UI class for the component as a whole - can I only bind to HaxeUI types ? or am I as usual missing something ?

hmmm, i would have expected that to work... ill check it out...

Hmm, continuing to make my app in hxWidgets. I have multiple problems with dialogs. The main one , is that you create a Dialog Base and have a width for it ( by code or xml or whatever) , it makes it crash. ( and autosizes doesn't really work)

haxe
var dialog = new haxe.ui.containers.dialogs.Dialog();
        dialog.text = "Dialog";
        dialog.width =400;
        dialog.showDialog();

I have with gdb #0 0x0000555555d93eef in bool hx::TestLessEq(Dynamic const&, Dynamic const&) () #1 0x0000555555ec9350 in haxe::ui::core::ComponentBounds_obj::set_percentWidth(Dynamic) () I think it has to do wth https://github.com/haxeui/haxeui-hxwidgets/blob/87a2062859753d8354bf533bf1f0595a24392a11/haxe/ui/backend/DialogBase.hx#L118

that DialogBase shouldnt be used

it should pick up the one from haxeui-hxwidgets... two secs... i wonder if ive broken this recently too :/

defo used to work

... yup... crash

i bet its that recent change where how i changed how native classes were looked up... :/

hmmm, nope

OK, it happens when a dialog doent have any buttons

Hmm, I think in my original app I had some buttons, and it crashed too

there seems to be issues with using the buttons too... and something strange happening with the size

obviously havent used native dialogs in a while, need to give them the "once over" - bear with me

not having dialog buttons should crash the app anyway, so that needs to be fixed regardless

No problem. Yeah I had clicking on the button crashes ,it was maybe with normal messages boxes (which do appear correctly). There was also that an onClosed event that weren't always called . ( I was able to add them to normal dialogs, but with messages boxes it still didn't work). Yeah, wxwidgets is quite finnicky 🙂