No Analyzer warning on ...

It took me a little while to understand why I was getting an [quote]OutOfBoundsException[/quote] on a line below.
I didn’t get an analyzer warning about this assignment, and I’m confused why.

I have some code in the app section in a method that goes like this:

Dim tdat As New Date If strt ISA AddCardWindow Then tdat.SQLDateTime = ACTopRc(0)//no error warning here??? End If
ACTopRc is a property in AddCardWindow. This window is currently open, and the method was called by it.

The line above should read

tdat.SQLDateTime = AddCardWindow.ACTopRc(0)

and when I changed it to the above - it works without an [quote]OutOfBoundsException[/quote]
strt is AddCardWindow and was part of the call for the method.
Is this normal when using ISA or passing the window?
If so why isn’t it working without AddCardWindow?

I would double check to make sure ACTopRc isn’t also declared somewhere else too. And I would expect your code should really be this:

If strt ISA AddCardWindow Then tdat.SQLDateTime = AddCardWindow(strt ).ACTopRc(0) End If

But really depends on what you’re doing so without more context it’s hard to determine.

The analyzer can’t tell that, at runtime, ACTopRC does or doesn’t have a 0th element. At compile time the assignment is syntactically legal - which is what the analyzer really checks.

Right, which is why I suspect ACTopRc is also declared somewhere else. Because, if it’s only on AddCardWindow the compiler will have given a warning that the item doesn’t exist.

Out of Bounds exceptions are Runtime-only exceptions and have nothing to do with the compiler. Sorry, focused on the fact that the property was on a Window and it compiled.

Never mind. I found the other declaration. I’m usually good at creating names.
It was in a module and it was definitely null at the time.

A good way to get around the issue is to change the scope of variables in modules to protected. This way they always have to be fully resolved. This way ACTopRc would become Module1. ACTopRc and a) you never have a global by accident b) the code is easier to read because you know where it comes from without having to search.

Having a standard can really help with that. I adopted Bob’s naming conventions. They are quite nice, and I haven’t had a conflict since. You should check them out here:

One of the secret powers of using the prefix system is that it really complements auto-complete well. Let’s say you know you want an integer, since you know it’s an integer start with i and a few letters from the variable name. Press tab, it’s right there in auto-complete! After a while, it becomes mindless and easy to find the right variable :slight_smile:

Edit: grammar and relvance

Thanks Bob. I’d been trying to get a handle on when to use Protected for the longest. I’d even asked Mark Zedar to write up something that could explain when stuff could work. I usually put everything in modules so it is global. I am fortunate. This is the first case I ran into problems. I’ll look at what I can modify.

Thanks Tim. I’ve been looking for a better naming convention than the simple one in the handbook. Most of it easy to apply.
I have it saved for future reference.

Be vary wary of excessive use of Global variables. I mean like a dozen, maybe less. Data should be local as much as possible.

Without knowing more about your project it’s hard to know for sure but that’s one of my big Red Flags when evaluating a consulting project that someone else has worked on. Classes are a good way to encapsulate data and an easy way to pass data around to various objects.