https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    then you just go 
    var d = new CustomDialog(); d.show();
  • r
    This is a minimalized repro, but the way this came up in my project is I have larger UI elements with multiple dialogs in them (all hidden), which represent one flow of modals... and the crash occurs when I want to unload one modal flow and load another with another set of dialogs
  • r
    I'm guessing that is just wrong in general though 😄
  • b
    i think the main issues are a) your dialog isnt really a dialog, its a vbox with a dialog embedded in it and b) you are manually adding the dialog to the screen, and thats what haxeui will do
  • r
    Got it, I will switch to doing that, and I guess break the dialogs into individual xml files... how do you unload the dialog when it's no longer needed, though?
  • r
    (if I want to force it to go away permanetly but not because of a specific user interaction, like a timed dialog)
  • b
    dialog.hide()
  • r
    ah this actually removes it from the tree? nice
  • r
    thank you!
  • b
    yeah, and it will destroy the dialog, if you didnt want it to be destroyed, you can set 
    dialog.destroyOnClose = false
  • r
    perfect
  • b
    you can also do 
    dialog.hideDialog(DialogButton.X)
    ... this is useful if you have a validation override that will stop the dialog from closing
  • b
    dialog.hide
    is basically just 
    dialog.hideDialog(DialogButton.CLOSE)
  • b
    btw, another fyi: you can use 
    @:xml
    in custom components (at the top of the class), for dialogs (which tend to be pretty small xml wise) i find it really useful, eg:
  • b
    Copy code
    haxe
@:xml('
    <dialog id="dlg" width="30%" height="30%" visible="false">
        <button id="btn"/>
    </dialog>
')
class CustomDialog extends Dialog {
}
  • b
    (obviously you dont have to use that, but for tiny little UIs, which dialogs tend to be, i find it much neater)
  • r
    that is handy! though some of mine in this particular case are fairly complex custom dialogs
  • b
    cool, fair enough
  • b
    another fyi... 🙂 You ca also now put the .xml next to the class
  • r
    how does that work?
  • b
    so you can have your 
    dialog.xml
    in the same dir as your class and just use 
    @:build(haxe.ui.macros.ComponentMacros.build("dialog.xml"))
  • r
    aaah I see what you mean, neat
  • b
    just little QoL things that can let you organize things differently if you want
  • b
    (all optional / up to you ofc)
  • r
    always happy about more QoL 🙂
  • b
    @:build(haxe.ui.macros.ComponentMacros.build("..."))
    should probably be 
    @:build(haxe.ui.ComponentBuilder.build("..."))
    btw, doesnt make a difference at the moment (its just an alias) but it is the preferred method (in case the other does get removed)
  • r
    I will update that! I think I've just been using the same snippet to set up my UI classes since the first time I got it working
  • b
    yeah, i think the old method is also used all over the place in docs and examples - it doesnt really matter, its just to unify 
    haxe.ui.ComponentBuilder
    and 
    haxe.ui.RuntimeComponentBuilder
  • b
    well, not unify, but make consistent
  • r
    Hmm, @bright-gpu-74537 , what about in this case? https://gist.github.com/kaug-whis/3c6a6a784aa3ab6e287fa1c04ea14fc6 This generates the same crash.
1...137313741375...1687Latest