Hi Mike, thanks for the reply!
Well, I am sure that would also work, yes... and also, there is the workaround of using the $classmethod instruction, and neither of them would break the parser...
But the point of the parser itself is to prevent problems from happening in the first place, so if we "hide" our code inside something, then we lose the ability of the editor to warn us from errors in a proactive way...
The one problem on the "%" calls is actually very annoying, since the problems are even also reported on %SYS core classes when they are being referenced in your code, since the VSCode seems to search for problem inside them once you reference them...
Following the threads that John posted on his reply, I understood that ISC is not going to pursue a solution for this, due that on the parser, they cannot assert accurately the namespace that is being referenced, something, I cannot understand very well as a developer, since that is only true if the namespace is being specified as a variable instead of a hardcoded value, as in my example code...
Besides the above, I also noticed that the parser also fails when calling a %SYS routine as in:
do DecomposeStatus^%apiOBJ(sc,.err,"-d")
Is that also not going to be corrected?
Hi John,
Thanks for the reply. Sure, I can paste here what I mean:
When using a system % routine, we get the line underlined as an error, and it is shown under the "Problems" of the class.
If for any reason, we reference a system class that actually contains itself some %references, for some reason, the vscode syntax checker also fails like this, even if we do not actually open that file, the vscode seems to check it anyways:
Notice how the Problems tab is not populated with some core classes problems.
I believe this happens when the #dim is used actually.