Surely the scope of the implicit variable is simply where its declared, no different to normally declared variables, beit at the global, module, procedure, routine, local procedure or class or class method its declared in?
Obviously it depends on the compiler how its handled ultimately, but its got to recognise the variable and then handle it in a way that doesnt simply throw a compiler error, otherwise noone would be able to use an implicit variable would they?
The only other thing I can say about implicit variables is they match the same data types available to use in the template language when using #Declare, the default datatype being a string, 32 characters long.
The existence of the three datatypes as implicit variables and template variables are perhaps a nod to the IEEE754 which was established in 1985.
Now where a problem might be seen, which maybe linked to what I have seen in the templates but not reported, is the handling of a section of source, ie a variable declared in a global, module, procedure, routine, local procedure, class, or class method conflicting with another section when they shouldnt be any scoping issue, like a procedure var conflicting with another procedure var, in much the same way as I have declared variables in #Application, #Procedure, #Extension, #Code, #Group, and sometimes the scope of a variable declared conflicts with a template symbol declared in a totally unrelated template, which has forced me to use unique variable/symbol names throughout all my templates and the shipping templates. [and whilst I was just editing the last part of this sentence, having already written out the everything you see below, this website popped up message saying this message was being edited in another window !?!, only Iām not editing it in two windows simultaneously]
Where I am most likely to see this is, is in a group in a template that happens to be in a group in another template sometimes with the same #group name sometimes not.
Typically what Iāve done is copied functionality I need, defined as a #group into another #extension typically. Its why Iāve been prompted into building my templates with output to debugview, to track down whats happening internally, and also why Iāve written a template chain which can write templates, to help with scoping issues and management. In other words, eliminating the human error risks as much as possible.
But this scoping issue doesnt always show up which makes me think some other condition is needed first in order to trigger it, like maybe a crash or something perhaps happening at the machine level, which maybe totally unrelated to Clarion other than its interfering with it.
I dont know if its a bug in the runtime data conversion handling that goes on, when someone assigns a value from a variable of one datatype to another variable of a different datatype, or if its something else.
But something strange is going on because Iām seeing the same random problems with template symbols containing the wrong values, or conflicting with #groups declared in other templates, but they happen to have the same #group name.
Edit. The fact the documentation is poor does not help matters either, at worst, its dangerous.
Edit 2. This whole website just reminds me of this The Gentlepersonās Guide To Forum Spies (cryptome.org)
and as someone who has suffered a lifetime of criminality from employees of the state, nothing would surprise me from the criminals that work for the state. After all the state imposes itself onto everyone whether they like it or not because you cant kill ideas.
