Locating A Control's Variables In v2005 Debugger

[Gary Brown]

Hi,

Is there a resource that lists where a control's variables are put?
VC puts data such as a ListView's Items in fields that bear no
resemblance to the programmer's view. After documenting
them for V2003 I am in the same boat with V2005. MS has
done an even better job of hiding them in V2005.

Also, my V2005 does not always show a variable's class. For
example, a TreeNode will only show its text value. Digging
down a few levels will usually expose the class name but that
is distracting and annoying. Is this inherent or is there a fix?

Thanks,
Gary

[Nicholas Paldino [.NET/C# MVP]]

Gary,

What you see in the debugger is a representation of the class. For
example, the TreeNode is an object, not a string, and that single line is
the best representation that they feel they can give you (which, btw, is
totally configurable).

If you want more values from the class, you have no choice but to dig.

VS.NET 2005 should be ^better^ at displaying this, as it cleaned up a
good deal of what is revealed in the watch window. However, it still has
the raw view, which is everything that it offers. What I don't get is your
comment about bearing no resemblance to the programmer's view. Basically,
you can see the properties that are exposed through the class. What else
are you expecting to see?

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Gary Brown" <ga********@charter.net> wrote in message
news:OC**************@TK2MSFTNGP02.phx.gbl...

Hi,

Is there a resource that lists where a control's variables are put?
VC puts data such as a ListView's Items in fields that bear no
resemblance to the programmer's view. After documenting
them for V2003 I am in the same boat with V2005. MS has
done an even better job of hiding them in V2005.

Also, my V2005 does not always show a variable's class. For
example, a TreeNode will only show its text value. Digging
down a few levels will usually expose the class name but that
is distracting and annoying. Is this inherent or is there a fix?

Thanks,
Gary

[Gary Brown]

>> Is there a resource that lists where a control's variables are put?

VC puts data such as a ListView's Items in fields that bear no

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in What I don't get is your
comment about bearing no resemblance to the programmer's view. Basically,
you can see the properties that are exposed through the class.

To clarify, what I meant as the "programmer's view" is, for a ListView
for example, a property named "Items" an object that is noted as
an ListViewItemCollection with an array of items in it. What I get is
a puzzle that ultimately leads to the information I want. And if I don't
write
down how I got there will need to repeat the process next time.
Hence the request for some documentation, probably notes by
another programmer, on where the array of ListViewItems is stored.
Ditto subitems, TreeNodes, and so on.

I hope I'm not sounding picky or contentious - just looking to save some
time and effort by not repeating the process I already went through for
VS2003.

Thanks,
Gary

[Nick Hounsome]

"Gary Brown" <ga********@charter.net> wrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...

Is there a resource that lists where a control's variables are put?
VC puts data such as a ListView's Items in fields that bear no

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in

What I don't get is your
comment about bearing no resemblance to the programmer's view.
Basically, you can see the properties that are exposed through the class.

To clarify, what I meant as the "programmer's view" is, for a ListView
for example, a property named "Items" an object that is noted as
an ListViewItemCollection with an array of items in it. What I get is
a puzzle that ultimately leads to the information I want. And if I don't
write
down how I got there will need to repeat the process next time.
Hence the request for some documentation, probably notes by
another programmer, on where the array of ListViewItems is stored.
Ditto subitems, TreeNodes, and so on.

I hope I'm not sounding picky or contentious - just looking to save some
time and effort by not repeating the process I already went through for
VS2003.

But you are asking MS to effectively lock down the implementation of a class
and even the names of private fields!

In 2.0 MS have tidied up the debug view quite a lot by using some new
attributes to control what is seen in the debugger but I know what you mean.
I have played around with these attributes myself and I have found that the
problem is that what you want to show depends on what level you are
debugging at.

One "solution" is to create a static method:
public static ListViewItem[] ListViewToArray(ListView lv) { return
(ListViewItem[])new ArrayList(lv.Items).ToArray(typeof(ListViewItem)); }

You can then display this in the Watch window (or just the and it will
always work whatever MS does to the internals (Although you have to click
the update icon to get it to update)