Hi,

>>I think there's a definite speed issue. Doesn't using the long version mean that the application has to 'walk' the entire chain of pointers each time you reference the object?
>
>Not with an optimizing compiler <g>... but then I don't think the C# compiler current does that sort of optimization.
>

You mean that a truly optimised compiler wouldn't need to have either a WITH..ENDWITH or a variable reference - it would work out for itself where such a construct would be more efficient? In that case the only reason to use either method would be for readability - but then , arguably, by using it for readability you might be preventing optimisation! Or would the compiler be clever enough to 're-expand' all the references before working out its own optimisation ?

>
>with endwith is really compiler sugar and the compiler behind the scenes actually creates a variable and uses it.
>
>So if you want to do this in C# the way to approach this is to use a local variable instead of the with/endwith which gives the same performance and most likely very close IL code.
>

Is there still one extra level of indirection ? If not then a simple VB

WITH Me
 .Width = 1 'etc
ENDWITH
'would be identical to
Dim o as Object = Me
 o.Width = 1 'etc

and would ONLY provide better readability and no performance gain?

>Personally I never used with/endwith even in VFP which had it. I prefer readibility of a local variable because THAT clearly identifies what you are dealing with.

I tend to us WITH...ENDWITH a lot in VFP (even been guilty of deliberately taking advantage of the scope still being in effect in called methods) but I take your point (subject of course to using a suitably descriptive name for the reference variable<s>)

Regards,
Viv