https://linen.dev logo
Powered by
# haxe-ui
  • b
    ( @User )
  • n
    taking a look, your implementation looks much cleaner, nice
  • n
    yep, it works fine
  • n
    unfortunately it has the same problem as mine
  • n
    if you add a 
    trace("here!);
    right after 
    CommonDialogs.openFile
    is called, it will run immediately on openfl targets, but it won't run until you close the dialog on wx
  • n
    it's not a huuuge problem but if we could get every target to behave the same, that'd be cool
  • b
    thats just the nature of the sync dialogs in wx
  • b
    we could make them async (probably) with some effort, but im not sure its worth it...
  • b
    if anything, i think the openfl behaviour is wrong... you can still interact with the app while the dialog is open - which doesnt seem right, since the open is (essentially) an atomic action
  • n
    fair enough
  • n
    you got me wondering about the "being able to interact with the app" thing
  • n
    I think I used some programs in the past where that was the case 🤔
  • b
    i wouldnt say this is normal / good app behaviour:
  • n
    I think qbittorrent works like that
  • n
    it looks silly at first but it may make sense in apps where you add multiple files to a queue
  • b
    i mean, for specific cases, sure... but for 99% of the time, this isnt normal behaviour
  • b
    and also, i still dont really think "adding multiple files to a queue" really is a good reason to have this behaviour anyway, i mean, you'd still be adding the item one at a time... why would you need 14 open dialogs at the same time?
  • b
    added a card component to haxeui (which i needed for something)... but figured it would make sense to put it into core (since its so simple)
  • p
    I havent looked, is it easy to switch themes live?
  • p
    I like the card
  • b
    <switch onchange="haxe.ui.Toolkit.theme = this.selected ? 'dark' : 'default'"  />
  • l
    Is there a way to tell a dialog box to close aside from the close button? I have a dialog with a handful of buttons that I'd like to have close the box when pressed if successful with their actions, IE a Save button that closes on a successful save
  • b
    sure... 
    myDialog.hideDialog(DialogButton.OK)
  • l
    I get a null access error performing it a second time
  • l
    Kind of why I'm asking, heh, was afraid I was using it incorrectly
  • l
    and now I'm getting a null access error on first prompt after some changes in my code behavior
  • l
    Copy code
    Null access

Called from components.ui.menus.$SaveMenu.~__constructor__.1 (components/ui/menus/SaveMenu.hx line 97)
Called from haxe.ui.tooltips.ToolTipManager.~stopCurrent.0 (C:\HaxeToolkit\haxe\std/hl/_std/Date.hx line 0)
Called from haxe.ui.util.EventMap.invoke (haxe/ui/util/EventMap.hx line 76)
Called from haxe.ui.core.ComponentEvents.dispatch (haxe/ui/core/ComponentEvents.hx line 98)
Called from haxe.ui.core.ComponentEvents._onMappedEvent (haxe/ui/core/ComponentEvents.hx line 127)
Called from haxe.ui.backend.ComponentImpl.~__onMouseUp.0 (haxe/ui/backend/ComponentImpl.hx line 716)
Called from haxe.ui.util.$Timer.~delay.1 (haxe/ui/util/Timer.hx line 10)
Called from haxe.ui.backend.$TimerImpl.update (haxe/ui/backend/TimerImpl.hx line 13)
Called from haxe.ui.backend.$BackendImpl.update (haxe/ui/backend/BackendImpl.hx line 7)
Called from haxe.$MainLoop.tick (C:\HaxeToolkit\haxe\std/haxe/MainLoop.hx line 204)
Called from haxe.$MainLoop.~injectIntoEventLoop.0 (C:\HaxeToolkit\haxe\std/haxe/MainLoop.hx line 118)
Called from sys.thread.EventLoop.progress (C:\HaxeToolkit\haxe\std/sys/thread/EventLoop.hx line 114)
Called from hxd.$System.runMainLoop (hxd/System.hl.hx line 152)
Called from hxd.$System.runMainLoop (hxd/System.hl.hx line 142)
Called from haxe.$Timer.~delay.0 (C:\HaxeToolkit\haxe\std/haxe/Timer.hx line 144)
Called from haxe.$Timer.~__constructor__.0 (C:\HaxeToolkit\haxe\std/haxe/Timer.hx line 76)
Called from sys.thread.EventLoop.loop (C:\HaxeToolkit\haxe\std/sys/thread/EventLoop.hx line 150)
Called from sys.thread._Thread.$Thread_Impl_.processEvents (C:\HaxeToolkit\haxe\std/hl/_std/sys/thread/Thread.hx line 62)
  • l
    Will see if I can reproduce
  • l
    It seems that declaring a component new a second time doesn't index it back into the same id or however you have it tracked
  • l
    Guessing declaring the UI is only supposed to happen once?
1...812813814...1687Latest