2

I'm using HaxePunk 2.5.6 with OpenFL 3.6.1 and Lime 2.9.1 ; I read in an issue on the HaxeFlixel GitHub that Lime prevents access to its classes on legacy. That's a big problem, because HaxePunk uses legacy by default. I want to use lime.ui.FileDialog to open and save files, but since HaxePunk is stuck with legacy, obviously that doesn't work (lime.ui.FileDialog reads as null instead of Class<lime.ui.FileDialog> ...). Is there a workaround to this ? I didn't see anything in OpenFL that replaces this, so I'm really lost. Obviously I don't want to install any additional lib unless it's really necessary. Using -Dnext or -Dhybrid when compiling to override -Dlegacy breaks everything, so that's not a solution either.

Thanks by advance !

Alexander L. Hayes
  • 3,892
  • 4
  • 13
  • 34
Matrefeytontias
  • 592
  • 1
  • 4
  • 13
  • Upon further inspection, it appears that OpenFL implements the `openfl.net.FileReference` class, which is exactly what I need. Except guess what ? It's not implemented for `openfl-legacy` either, so welp, I'm still as stuck as before. – Matrefeytontias Jul 13 '16 at 12:07

1 Answers1

1

You could go to <haxelib directory>/lime/2,9,1/legacy and undo the changes to include.xml in the relevant commit by removing this line:

<haxeflag name="--macro" value="exclude('lime')" />

However, as described in this thread, this adds a dependency to lime.ndll (as opposed to lime-legacy.ndll, which is the only one being copied to /bin for legacy builds), so your binary would crash when shipped to other computers that don't have a Haxe installation.

You can work around this by manually copying lime.ndll over (or add <ndll name="lime" dir="ndll" /> to legacy's include.xml), but using a third-party library like systools or linc_dialogs would be a cleaner solution.

Gama11
  • 31,714
  • 9
  • 78
  • 100
  • I tried that, but HaxePunk programs don't compile then. I found out that I can use `-Dnext` in some cases, which fixes the issue, but this breaks something in HaxePunk that I'm not using in this project (still haven't found out what), so I'd rather do it the correct way. I saw systools, but the dialogs break on Linux it seems (there are a couple of issues about this that were never addressed) ; linc_dialogs only works with the C++ target, while that's not really a big deal (seeing the use I'll have for it), I like to retain maximum versatility. But then again, I guess I'll give it a try. – Matrefeytontias Jul 13 '16 at 12:20
  • 1
    Well I am confused, I cannot get it to break again (which is sort of good news) ... I tried linc_dialogs though, I think I'll stick with it, I'm using it for a utility program so it doesn't really matter if I stick to the C++ target or not. Besides, I don't like to mess with libs' options and parameters, so I'm fine with linc_dialogs. Thanks for pointing that out ! – Matrefeytontias Jul 13 '16 at 12:38
  • Well, you _were_ asking for a workaround without additional dependencies. ;) – Gama11 Jul 13 '16 at 12:45
  • Yeah indeed. But I installed it and it's not given me any trouble, so let's say I'm fine with that :P – Matrefeytontias Jul 13 '16 at 13:11