Below are screenshots of a debugging session showing the visibility issue. I blacked out any proprietary code and information, hopefully still leaving enough code to show the problem I'm running into.
Here is my procedure, showing the var definition. Note that "global" is in the "uses" part of the implementation section.
Here we are in the constructor. Notice that now we are inside global.pas, this is the correct location for CParsedFile.Create.
The instant I hit "Step into" I get an access violation error. If you look at the code at the top of the constructor (above screenshot), you will see that it's nothing fancy, just a bunch of string assignments (these strings are defined in the class definition of CParsedFile in the implementation section of global.pas).
If I was referencing a separate var, or there was another definition of CParsedFile, why am I stepping into the correct constructor? If I edit my procedure so that "CParsedFile.Create" is now "global.CParsedFile.Create", and step through it, everything is fine. So you understand my frustration when:
- I can compile
- When I step through my code with the debugger, I get to the appropriate constructor
- I get a runtime error in the constructor
- This runtime error is fixed by prefacing the unit in front of my constructor call in my procedure.