https://linen.dev logo
Powered by
# haxe-ui
  • b
    tbf, its totally fine to do it that, its what its for, but for me, i would probably create a custom event
  • b
    (for starters it would be typed, so in the handler "e.data.foo" could just be "e.foo", and it would compile if you used the dynamic data and potentially break at runtime)
  • b
    ie, "e.data.this_doesnt_exist.something()" would compile fine and die at runtime
  • b
    @User - example:
  • b
    Copy code
    @:xml('
<hbox>
    <button id="button1" text="Button1" />
    <button id="button2" text="Button2" />
</hbox>
')
class MyCustomComponent extends HBox {
    public function new() {
        super();
    }
    
    @:event(MyCustomEvent.FOO)   public var onFoo:MyCustomEvent->Void;
    @:event(MyCustomEvent.BAR)   public var onBar:MyCustomEvent->Void;
    
    @:bind(button1, MouseEvent.CLICK)
    private function onButton1(_) {
        dispatch(new MyCustomEvent(MyCustomEvent.FOO, 101));
    }
    
    @:bind(button2, MouseEvent.CLICK)
    private function onButton2(_) {
        dispatch(new MyCustomEvent(MyCustomEvent.BAR, 102));
    }
}

class MyCustomEvent extends UIEvent {
    public static inline var FOO:String = "foo";
    public static inline var BAR:String = "bar";
    
    public var myspecialdata:Int = 0;
    
    public function new(type:String, myspecialdata:Int) {
        super(type);
        this.myspecialdata = myspecialdata;
    }
    
    public override function clone():MyCustomEvent {
        var c = new MyCustomEvent(this.type, this.myspecialdata);
        return c;
    }
}
  • b
    usage:
  • b
    Copy code
    haxe
        var x = new MyCustomComponent();
        x.registerEvent(MyCustomEvent.FOO, function(e:MyCustomEvent) {
            trace(e.myspecialdata);
        });
        
        x.registerEvent(MyCustomEvent.BAR, function(e:MyCustomEvent) {
            trace(e.myspecialdata);
        });
        
        x.onFoo = function(e) {
            trace(e.myspecialdata);
        }
  • m
    Nice! An example will help me a great deal!
  • b
    or from xml binding:
  • b
    Copy code
    haxe
    @:bind(myCustomComponent, MyCustomEvent.FOO)
    private function onFoo(e:MyCustomEvent) {
        trace(e.myspecialdata);
    }
    @:bind(myCustomComponent, MyCustomEvent.BAR)
    private function onBar(e:MyCustomEvent) {
        trace(e.myspecialdata);
    }
  • b
    i think it's a DPI translation issue
  • b
    when i was tapping in the lower right corner of the screen it gave me the coordinates 2205 1060
  • m
    Custom event worked fine! But I've hit another wall. I'm trying to store a reference to the custom component created in the xml but I'm getting:
    Copy code
    "assets.haxeui.xml.lobby.item.ItemSlot should be entity.ui.lobby.item.ItemSlot"
  • m
    This prevents me from running the game in VSCode. But if I run lime test cpp directly in the terminal, it works 🤔
  • b
    nvm i think its just the `Toolkit.scaleX`/`Y` messing with the calculations unexpectedly since it's mobile
  • b
    dialog appears at -300 something so yeah
  • b
    ok using 
    componentWidth
    instead of 
    actualComponentWidth
    inside 
    centerDialogComponent()
    calculations fixes it for me
  • m
    Well, don't know how or why, but it started working all of a sudden now...
  • b
    interesting... maybe actual component width is wrong?
  • b
    Sounds like a (or "the") vscode issue... :/
  • b
    (i meant for both 
    actualComponentWidth
    and 
    actualComponentHeight
    btw)
  • b
    i guess 
    actualComponentWidth/Height
    is supposed to be the unscaled size
  • b
    but 
    Screen.instance.width/height
    is the scaled size
  • b
    so the calculation of 
    var x = (Screen.instance.width / 2) - (dialog.actualComponentWidth / 2);
    is a mistake?
  • b
    ill have to check the other backends... but looks to be either a discrepancy or a bug
  • b
    if this is actually a bug i see some more calculations mixing 
    actualComponentWidth/Height
    and 
    Screen.instance.width/height
    in MenuBar, Menu, and DropDown that could be worth a look
  • b
    yeah, thats what makes me think ill have to check against other backends... as, unless im mistake, things should be fine on them when toolkit scale is, say, 2x
  • b
    so im guessing (assuming / hoping) its just a matter of doing whatever they do in kha
  • b
    @User - so i think its bugged on all backends 🙂
  • m
    @User Any luck on the tabview + scrollview thingy?
1...629630631...1687Latest