https://linen.dev logo
Powered by
# haxe-ui
  • b
    🙂 np
  • e
    Sorry for wasting your time. And thanks!
  • b
    no worries - extra pair of 👀 usually helps 🙂
  • b
    so just to confirm, does your hex view also work now with the constructor param?
  • e
    Yes, it works without any problem :)
  • b
    ok, cool - 😌 - at least the constructor param code is working inside the macros
  • b
    its pretty ugly iirc
  • n
    Nah, it's because Lime opens the file dialog in an async way (your program keeps running and you pass a handler function that is called when the user selects a file), while hxWidgets is not (the program will only resume execution when you're done selecting a file). I attempted to use a different thread to make the behavior consistent between the two 😅
  • b
    right, ill have to take a look, but i think it all should be possible... just means the hxwidgets version would be sync (but still could call a callback rather than directly returning)
  • b
    you might also be able to show the wx file dialog "modeless" (ie .show() rather than .showModal()) but i think that would be crappy behaviour
  • n
    I might double check if hxcpp has a way to do it
  • n
    I know the Neko and HL targets have builtin functions in the STL to open file dialogs
  • n
    if hxcpp does as well, then we could avoid any wxWidgets issue
  • n
    I don't think it has tho
  • p
    The hashlink (and neko?) functions for file dialogs are only implemented on Windows. And hxcpp does not have builtin functions for file dialogs. (You could easily write them yourself though)
  • n
    @User thanks for saving me time
  • n
    in that case, might as well just use Lime's/wxWidgets' built-in functionality
  • n
    if anyone has an idea on how to make it synchronous in Lime or asynchronous in hxWidgets, please tell 😄
  • n
    we could just leave them with different behavior but that's the last case imo
  • n
    crashes the same way
  • b
    if you are running it from a thread? I dont think you should be doing that... i also think the "default" behaviour (ie, wx blocks the main ui thread) is better behaviour tbh
  • b
    @User - whats the call to show the file open dialog from oepnfl?
  • n
    here's how it looks atm
  • n
    Copy code
    public static function open(handler:(path:String)->Void):Void {

        #if openfl
        var window = new FileDialog();
        window.onSelect.add(handler);
        window.browse(FileDialogType.OPEN);
        #end

        #if hxWidgets
        var dialog:FileDialog = new FileDialog(null, "Open a Haxe file", null, null, "All(*.*)|*.*|Haxe files (*.hx)|*.hx|Haxe build files (*.hxml)|*.hxml");
        var r = dialog.showModal();
        var path = dialog.directory + dialog.filename;
        handler(path);
        #end

    }
  • n
    you import 
    lime.ui.FileDialog
    and 
    lime.ui.FileDialogType
    on lime targets, and just 
    hx.widgets.FileDialog
    on hxWidgets
  • n
    this function receives a handler function that does something with the selected path.
  • n
    it could be changed to use 
    haxe.io.Path
    instead of passing a string as well
  • n
    the lime version allows you to tweak the dialog just like the hxWidgets one, I just didn't get into it yet
  • b
    i did it like this:
  • b
    obviously its pretty basic, but seems to work fine for wx, html5 and openfl... also, you can just keep adding to it if other frameworks provide the functionality
1...811812813...1687Latest