I have this recurring issue with SWF generated classes and I’m not sure if that’s a problem with OpenFL, SWF lib or FlashDevelop/HaxeDevelop:
When I use generated classes from SWF I sometimes get an error like this:
src/app/view/screens/mainMenu/MainMenuLayout.hx:34: characters 22-30 : Type not found : LongHill
but surely the generated class is present. This issue can sometimes be fixed by opening the generated class after I’d build or rebuild the binaries once, but sometimes even that doesn’t help.
The app compiles just fine, but the issue is that the IDE (HaxeDevelop in my case) would stop any auto-completion and spams me with an error message in the output log instead. It’s very disruptive since the error is being triggered when working on a different class/package that is not using the generated class.
Is there a way to fix the problem? Maybe some setting to enforce HaxeDevelop to look into the generated class folder.
On a highly related note… would it be possible to run
openfl process target.swf
and work with the *.BUNDLE file and have my own class generator? I haven’t figured out how to bind the classes to the *.BIN file, copying come from generated SWF lib class didn’t work and there’s no explanation on-line that would explain how.
You could create a fake LongHill class where HaxeDevelop can easily find it. Put the whole thing inside an #if 0 ... #end block, so that it doesn’t interfere with compilation.
Thanks for the reply! The first solution is pretty pointless, no reason to use generated classes at all then. I would instead prefer to learn how to bind the bin files properly instead.
VS Code solution intrigued me; is VS Code’s auto completion that good now? The last I tried it, I couldn’t even get auto import for classes.
Or was it sarcasm to use VS code for generated classes because auto completion wouldn’t break since there is none to begin with?
You probably don’t need to type out the whole generated class. This should be enough to get rid of the blocking error:
package;
#if 0
class LongHill {}
#end
As for VS Code, no, it still doesn’t auto-import, at least not while typing. After you type the full class name, it often offers an option to import it, but you have to click a lightbulb icon or press Ctrl+Q.
Other than importing, VS Code’s completion is pretty robust, and always has been. This is because it uses the Haxe compiler’s built-in completion server. And aside from it being slow, I’ve never had any issues with it.
The main difference between now and previously is that they’ve released a Lime extension, making setup easier.
@player_03 Thanks, I will definitely take a closer look at VS Code. I wanted a good OS X IDE for long while. Maybe now is a good time to start using VS Code.
As for the temp class - it’s a really neat trick, but I can’t really use that. There’s no guarantee that some other SWF generated class won’t break like that and adding a whole bunch of such classes and their fields won’t work. It will make the code-base really ugly. I need to find a way to either work with generated classes or generate my own with the help of openfl command line tools; openfl process target.swf in particular.
@singmajesty I tried and couldn’t find it. I also tried adding a new custom class path with no luck. I will have to look deeper into it. I was really hoping I’m just making a silly mistake and it can be solved by a magic “fix it” button. In the worst case scenario I’ll have to look into FlashDevelop source code. Luckily the code looks super clean and written in familiar to me C# language.
I will try to fix the issue today and write back to this post if I find a solution.
I highly recommend VS Code for cross-platform Haxe development. I tried various other options, but none of them even came close. (Granted, I tried them a while ago, so they might have improved since.)
I’ve spend a little bit more time digging in FlashDevelop’s sources, SWF lib’s sources and lastly OpenFL’s sources.
One of the things I’ve tried to do is to change the output directory for the generated classes in the OpenFL’s code.
So with a clean build (completely deleting the bin folder beforehand) I got my generated classes in the main source folder.
To my surprise, that didn’t help at all. I had the same error message coming up over and over again.
Even more strangely, I found that if I’d press F4 (default shortcut to Go To Source in FlashDevelop) while the pipe symbol is in the middle of the class-name - I’d just get an error. However, if I’d do the same while having my pointer at the end of the class-name - I’d be able to jump to the target class. Very strange.
And due to the fact that the other generated classes behave normally, and only some are not being processed normally, I suspect it could be a problem with FlashDevelop after all.
PS: A special thanks to @player_03 ! I’ve been following your posts for years and I’m astouned by how knowledgeable you are. I will definitely use VS Code for OS X development. But for Windows - FlashDevelop is just way too good, too hard to compete.
If there will be a better solution I will update the thread.
OK, I solved the problem for FlashDevelop/HaxeDevelop:
Delete the bin/Export folder where the generated classes and .BIN files are
Build the project once ( I used lime build neko -clean from CMD)
In FlashDevelop/HaxeDevelop press Ctrl+F9 to edit global Class. Navigate to the folder where generated classes are. In my case that would be \bin\neko\haxe\_generated and add this folder.
Restart FlashDevelop
When building your project, use command line, that way your added class-path will have no chance of causing any problems (although it shouldn’t anyway).
I think it’s a completely reasonable solution, when working on a project, since you only have to do this once.
