QML Syntax check
I have searched the forum but found no result. We start to develop the GUI with QML and in this case
a lot of syntax errors made by programmers. I use QtCreator 2.7.2 (Based on At 5.1.0). Normally a lot of syntax errors found by the editor or by Tools.QML/JS.Run Checks.
But in the following case I can't found the error with the tools including the debugger
import QtQuick 2.0
width: parent.width / 2
height: parent.heightt / 2 // <-- syntax error should be height
MidRectangle is a simple Rectangle centered in the parent:
import QtQuick 2.0
There is no runtime error, why? And the result of the program is complete different from the expected.
How can I find such syntax error automatically? In the past I used QScript and there are checkSyntax() and evaluate() functions to find such errors.
The short answer is: that is not a syntax error.
(Well, of course, that's an oversimplification, since you can look for things which change the evaluation context (like eval() etc) and if none exist, you can assume that the runtime context "should be" identical to the context model that your tooling generates at build time - assuming that you have a full expression evaluator built into your tooling, of course).
Now, there will be a runtime error (you should see something like "ReferenceError: parent.heightt not resolvable" at runtime, when the property bindings are initialized (evaluated for the first time)) which you could scrape for error detection.
Alternatively, you could write a tool which parses all QML files and builds up a hash of static QML type information (type names and their property names), and then runs over your source tree and identifies any non-static property usages in other QML files. I think QtCreator could/should include something like this, if it does not already, as I agree that it's a common case which tooling should help solve (by warning / yellow squiggley at the very least).
Thanks, syntax or not:-) I need a way to detect such errors.
You are right, with
I get a ReferenceError: myValue is not defined message, which is very helpfull.
But not for the line
I see no reason to ignore the second one except a bug.