You may see in syntactical use in our examples that does not seem to make sense at times. I would like to explain some of these. Most of these are just anomalies in Visual Basic. So let’s go over them briefly. First of all, sometimes you will see our methods are being used like functions. Sometimes they are being used like sub-routines. You can actually make them work either way. Let me show you what I am talking about. Let me add a brand new display and I will just add a little sub-routine to change the timestamp on this. PITrend is one of our sample tags. I will go into the Visual Basic Editor by pressing Alt-F11 And here is one example of such an odd syntax. I am going to go and on that object, the Trend object, I am going to do a SetTimeRange and when I do a SetTimeRange, as you can see by looking at the IntelliSense, this is returning a boolean value. So if I were to do a SetTimeRange of say * – 4 days to the current time, then technically that’s going to return a value. And when you return a value, then typicall you expect to use it as though you were using a function. And in Visual Basic, functions have certain characteristics. Let’s go over those real quickly. If I were to do this as a function, I would want to setup some variable first of all to take the result. Let’s dim X as a boolean. And then I would say, let’s look at the result of this function. Let’s say X is equal to… Since we know this returns a boolean value, we are going to say X is equal to the result of this. And when you use a function in Visual Basic, you have to put the arguments in parentheses. That’s why in some of our examples, sometimes you will see it looking like this. Sometimes you will see it looking like this. And in fact, it has no difference that I can figure out. I have been all over Microsoft’s website trying to figure out why they have decided to use this convention, using functions requiring parentheses and procedures… Procedures of course do not return a value. So a procedure basically does not have to be assigned to anything. Let me just demonstrate that this is going to work just fine in both instances. I better give this a name, let’s call this test2. And I am going to go ahead and take my code and put that into test2. And let’s go ahead and run this and you will see it works just fine either way we run it. Right now I have an eight hour time range. I will go ahead and run test2 and now I have got a four day time range. I will revert back to the eight hour time range. Let’s change the code. As you can see, this works just fine as well. So I suppose the moral here is, if you are going to be a well behaved programmer and you want to actually interrogate the results of your functions, then you should probably always use these as functions. And as functions, you should use parenthesis like that and have some kind of an if then statement– if X equals false, then tell the user that something went wrong. Incidentally, if you omit these of course you will get an error message from Visual Basic. It is enforcing that rule of functions requiring parentheses around the arguments. The second thing you may notice is sometimes we omit the item method in our examples. You get examples off of the Developers Network or in the books that we ship with the software. You will see in many cases we use the item method and things like the Symbols Collection. Other times we do not use the item method. There is a real simple explanation for that. The default method of any collection is the item method. Now since that is the default, if you omit that method, it ends up becoming just the default. So you see a lot of VB programmers that just simply things by saying it’s called symbols1 and not symbols item 1. I just do not trust that one day Microsoft will not change the default method from item to something else. It’s probably an exaggeration but it has happened before that defaults get changed. I always think it is a more conservative method to always explicitly define everything and not rely on the defaults. Because the defaults can change, there is no guarantee [inaudible] defaults are going to persist from one revision to the next.