How is the With Construct handled in a compiler (specifically Excel's IDE)

[JohnnyWaffles]

So there seems to be a debate between me and some friends. Not sure who is right on this one. Using the With Construct is something I like to use in my office programming, and just in general.

What are the advantages and disadvantages of using it? I guess I use it mostly out of habit. However I find also that it is convenient to use. If I need to access several properties of an application object, then I would prefer the With construct because you don't have to write out the object variable every time you want to access a property. You write out the object once and that is it.

However, I'm constantly criticized for using it because I am told that it uses more memory when you access an objects properties like that.

My argument is one) who cares...If it does require more memory HOW much more could it possibly use. These are office macros we are talking about, not full on applications.

And two) I thought that every time you access an object like so:

String(0) = Object.Property1

String(1) = Object.Property2

String(2) = Object.Property3

etc....

Requires more overhead.

Is this better, or is it not?

With Object

String(0) = .Property1

String(1) = .Property2

String(2) = .Property3

End With

[LaVolpe]

Can't really speak about compilers since I don't know how the compiler optimizes statements. It may be that they are ultimately compiled the same in many cases. However, WITH readability is a plus IMO.

There are definitely cases where WITH has performance benefits. One that jumps to mind is when you are setting properties on an object that was retrieved indirectly. An example using any kind of object that has keys, indexes, ranges, etc or an object that is retrieved from a function. Depending on what code is executed behind the scenes, within that object's class, to find that object's item, the performance benefits may be substantial.

The following would need to look up the item each time a property is accessed, or you would need to use a separate variable and cache a reference to the object

ValueA = SomeObject(Key/Index/Range/etc).PropertyA 
ValueZ = SomeObject(Key/Index/Range/etc).PropertyZ

The following would not require a temporary variable nor looking up the value more than once

With SomeObject(Key/Index/Range/etc)
    ValueA = .PropertyA 
    ValueZ = .PropertyZ 
End With