>I like it better
>
>(1)
>In an other message you said that one of those 3 objects needn't be closed. That is correct
>In this case, you don't need to close loStream
>
>Because closing a stream adapter automatically closes the underlying stream. But you have to remember that
>
>Closing a stream more than once is not a problem
>
>In this case
>The using works from inside out ( deepest level first, then one level up)
>
>(inner level) Closing loStreamReader closes loStream
>(outer level) loStream which has been closed is closed again
>
>So even when an exception is thrown in the StreamReader constructor, loStream will still be closed
>
>I think it's cleaner code - with the nested using, you don't have to 'know' that the adapter closes the underlying stream
>

>
>>                    Using loStream As System.IO.Stream = loHttpWebResponse.GetResponseStream()
>>
>>                        Using loStreamReader As System.IO.StreamReader = New System.IO.StreamReader(loStream)
>>                            cHTML = loStreamReader.ReadToEnd()
>>                            llSuccess = True
>>                        End Using
>>
>>                    End Using
>
>

>
>(2) You also said that you had seen some constructs where only one using was used
>That is possible (but I think you need at least two usings) with a chain of stream decorators (Deflate/Crypto/GZip/Buffered).
>Closing a decorator closes the stream used in the decorator constructor
>
>(3) There are exceptions, eg MemoryStream doesn't need to be closed/disposed.
>
>I am all for the nested usings
>
>- It takes a lot of brain work, just to figure out which type you can take of the using chain.
>
>- It's also cleaner code (and easier to read - was this an exception or not ?)
>
>- It's more bullet proof
>
>- You can never go wrong

It is one of the fanciest response I have seen in a long time. Well done!