I am trying to develop a code editor that - where you are able to develop using OpenFL classes and enums - will accept all the classes and enums as required to develop a game at runtime using the HScript library. I’ve got this far, but it seems that when I parse the code at runtime it does not seem to detect the classes/enums:
_classKeywords = ClassPaths.split(";");
for (fullPath in _classKeywords)
{
var shortName = fullPath;
if (fullPath.indexOf(".") > -1) {
shortName = fullPath.substring(fullPath.lastIndexOf(".") + 1, fullPath.length);
_classHighlighters.push(shortName);
}
_interp.variables.set(shortName, Type.resolveClass(fullPath));
}
_enumKeywords = EnumPaths.split(";");
for (fullPath in _enumKeywords)
{
var shortName = fullPath;
if (fullPath.indexOf(".") > -1) {
shortName = fullPath.substring(fullPath.lastIndexOf(".") + 1, fullPath.length);
_enumHighlighters.push(shortName);
}
_interp.variables.set(shortName, Type.resolveEnum(fullPath));
}
For some reason, when I parse the code from the interpreter, I get the error:
TypeError: Error #1007: Instantiation attempted on a non-constructor.
at Type$/createInstance()
at hscript::Interp/cnew()
at hscript::Interp/expr()
at hscript::Interp/expr()
at hscript::Interp/exprReturn()
at hscript::Interp/execute()
at CodeEditor/parseCode()
at CodeEditor/keyUp()
From what I can tell from looking around a bit, it seems Flash is just “I can’t find this class, so I can’t create it.” What is the best way to go around it, and is the Type.resolveClass() a function that should be used to pass in a Class to the interpreter?
I have done a trace on fullPath and shortName, both output as expected.
i.e. openfl.display.Sprite is the full path, and shortName is Sprite.
The resolveClass function just returns null when passing in either the shortName or the full path, so I am unsure what is going on there. I have not tested it on native targets, but I expect a crash should it fail.
If it helps, the string I pass into the ClassPaths to be split and read looks like this:
No, I did not do all that manually I created a small program that reads all the .hx files in the base directory of the source code of a library, and converts the directory path to its respective full path in code.
Looking at the first openfl.display.Sprite,
in openfl’s code it’s a typedef: typedef Sprite = flash.display.Sprite;
I wonder if that changes anything once at runtime.
Does it work if you try to load a “normal” class you made yourself?
What if you do a replace from “openfl.” to “flash.”?
Though not all classes are flash classes or vanilla copy.
Ah yes, I didn’t think about that. If you pass in the TextField class just as it is into the interpreter, I’d expect at runtime it would be considered “flash.text.TextField”, not OpenFL.
However, native is the target I am looking to distribute this editor in anyway, Flash is merely for testing.
When I did export using the windows target, I did get some errors:
openfl.text.TextField has no field tabEnabled
openfl.text.TextField has no field caretIndex
It will probably help if I upgrade from 2.2.8 to 3.0.x but I don’t know what the situation is with the Beta yet, and I am hoping the TextField is more supported now on native than it used to be. I will try neko as well.
The aim, however, is to implement the ability to load libraries at runtime as well, which is why I am using this approach. By converting the paths and directories to their appropriate class types at runtime when you pass in the library path.
EDIT: Although, now that I have just tested the neko target it’s also complaining about the field’s not existing.
It is odd, however, that it the cnew() function in HScript attempts to resolve a class anyway, but that is ironic since when I comment out the code as seen in the OP, the HScript interp complains the variable “TextField” does not exist when using the following script code:
var myText = new TextField();
myText.x = 50;
myText.y = 50;
myText.text = "Hello";
Lib.current.stage.addChild(myText);
I’ve written my own errors as follows:
try
{
var parsed = _parser.parseString(_mainText.text);
_interp.execute(parsed);
trace("Successfully parsed.");
}
catch (err:Error)
{
var erObj:ErrorObject = new ErrorObject();
erObj.LineNumber = _parser.line;
erObj.CharNumberTo = err.pmax;
erObj.CharNumberFrom = err.pmin;
switch (err.e)
{
case ErrorDef.EUnterminatedString: erObj.ErrorText = "String was not terminated with a single- or double-quote as expected.";
case ErrorDef.EUnknownVariable: erObj.ErrorText = "The variable could not be found. Have you misspelt or forgot to declare it?";
case ErrorDef.EInvalidIterator: erObj.ErrorText = "Cannot iterate over this variable. Is this variable an array?";
case ErrorDef.EInvalidOp: erObj.ErrorText = "The operator given cannot be applied to this type.";
case ErrorDef.EInvalidAccess: erObj.ErrorText = "Cannot access variable, member or class. Are you missing an include?";
case ErrorDef.EUnterminatedComment: erObj.ErrorText = "The given comment does not terminate. Are you missing an close block?";
case ErrorDef.EUnexpected: erObj.ErrorText = "The given expression cannot be evaluated.";
case ErrorDef.EInvalidChar: erObj.ErrorText = "The character given is not valid for this expression.";
}
trace("Errors found.");
trace("" + erObj.LineNumber + "(" + erObj.CharNumberFrom + " - " + erObj.CharNumberTo + "): " + erObj.ErrorText);
}
When parsing the former code, I get “The variable could not be found.” pointing to line 1, characters 13-27, that being the TextField “variable” that it’s trying to parse.
Anyway, I’m having another problem now because after upgrading to OpenFL 3.0.3, the windows target does not seem to allow me to place input on the TextField which I am confused about…
I’ve got my project on Github if you wish to help.
Everything is a child of Lib.current unless you explicitly add it to the stage. So when you make Lib.current invisible, you make everything else invisible too.
You’d need to write import flash.display.TextField; first, unless you wanted to type out new flash.display.TextField().
var stage = flash.Lib.current.stage;
for(i in 0...stage.numChildren) {
stage.removeChildAt(0);
}
I guess a code editor isn’t a security-critical application, but it would be confusing to write a game that showed up in the same window you were programming in.
Well, the aim of the program is to be able to make a game without needing to compile; being able to test game code on the fly without compilation, the ability to drag-and-drop TextField’s, Sprites, Sounds etc. into the Stage and auto-generating the expected code, in addition to property dialogs, event handling. And while testing, you would be able to track variables as you play, set breakpoints and modify the code as you test and play at the same time. The ultimate aim is to speed up video game development A LOT!
You barely would ever need to compile except on the occasion that you release your game or patch it to the public.
That might be too much. It’s starting to sound like you’re making a UI library in addition to the editor.
Actually, this might work well as its own library. Include the library in an existing project to place a console onscreen, and then view/edit values from within the console.
From my experience, with my project StoryDev HScript does not seem to be that slow.
I was thinking of implementing breakpoints in the sense that when the parser reaches a specific line, the rest of the code is split up into an array of strings. Stepping into/over would execute the next string in the array and being able to track all the variables that changed since the previous execution. That would require a lot of thought, ofc, since it would mean knowing what to do when a new function arrives, knowing which line that is, what to do when you hit a for/while loop etc. It would get insanely complicated but certainly a challenge I would love to experiment with.
I’m going to create a discussion about this because this is going way off-topic now.
I created a small program that reads all the .hx files in the base directory of the source code of a library, and converts the directory path to its respective full path in code.