why is code dumb

the function you use when binding expects a parameter "event" (doesnt have to be called an event, but has to have a parameter)

so you either have to do:

haxe
function reloadMods(event) {
}

or as you have done (when you dont care about the event):

haxe
function reloadMods(_) {
}

So the reason it "resets the position" is because your "mainView" is a "Box" which has a layout associated with it... if you want to freely position items absolutely without a layout use the "Absolute" container:

haxe
var mainView = new Absolute();
...

haxe
    @:bind( this, MouseEvent.CLICK )
    private function onClickEvent( e:MouseEvent ) {
        this.moveComponentToFront( );
    }

Nice, i always forget you can use

this

in

@:bind

🙂

I'm trying to use a dropdown for selecting a level theme: I can set

selectedIndex

when running my theme change code which correctly sets the right dropdown value, but having trouble figuring out the events part of HaxeUI to run the theme change code when a different value of the dropdown is selected

I thought it would be something like

currentThemeDropdown.registerEvent("PROPERTY_CHANGE", (_) ->
{
  switchLevelTheme(currentThemeDropdown.value);
});

based on what I read

... although it was

onChange

and I was just handing the event wrong the first time I tried it 🤦‍♂️

yeah,

.onChange

or

.registerEvent(UIEvent.CHANGE, ...)

is what you are after

I was trying something stupid like

[....].onChange = { callback: () - > { ... } };

🙂

just a normal function will do, as im guessing you've found out

>

.registerEvent(UIEvent.CHANGE, ...)

ah so I wasn't too far off

yeah, you could argue that PROPERY_CHANGE should also work... since, technically, a property has changed... ill check it out, but generally "change" is dispatched when a components value changes

eh you were closer with CHANGE, I was just going for the first one I saw lol

setting up the event also inadvertently worked around a bug in my own theme change code by running it twice when you use the keybind 😄 since it sets

selectedIndex

on the dropdown and then the onChange event makes it run again

Thanks, it works perfectly!

It seems like the setup for the haxeui electron boilerplate causes VSHaxe a little bit of confusion. Because it has two different targets that use different libraries, it looks like it can't "realize" that the HaxeUI libs are added for the

Main

target. Is anyone else getting this behavior? Best solution I could come up with that doesn't require flip-flopping between hxml configurations was to make a "fake"

hxml

setup with all the libraries.

right... and what does that fake one look like? Maybe i can just put both hxmls in one file and use --next

iirc the reason why i put them in seperate .hxml is because its quite rare to want to recompile the electron entry point

In fact, the template currently uses one

.hxml

and not two. But because there are two outputs, that's the problem in general. Notice: https://github.com/haxeui/haxeui-core/blob/master/cli/templates/electron-shared/electron.hxml The fake "all-libs.hxml" that I use is:

hx
-lib electron
-lib haxeui-core
-lib haxeui-html5

-cp src
-main Main
-js build/electron/Main.js

Never used for compilation, but used in VSCode as the haxe configuration. I feel like this might be leaning more towards a VSCode problem than anything

right so its the --next that is causing issues in vscode maybe?

I think it might not support multiple projects at once atm

right, you best bet then maybe is to just comment out the first part

Because --next is effectively starting another project that's unrelated to the prior . .

but if you make changes to "ElectronMain" then you'll need to compile manually

so maybe the best tactic is actually to split them into two

That's what I'm thinking, especially since you are right about rarely touching the ElectronApp in this case

yeah, agreed, in fact, in my electron projects i generally comment out the first one all the time

so yeah, two .hxml feels more sensible