Michael Lang said:
It may be a matter of opinion on many types what ToString() should return.
If they returned something other than what you wanted you would also
complain. If you want a particual property value, then query that property.
Yes, I realise this. Can't please everyone. However, define ToString's
semantics accurately enough and there won't be room to argue
ToString should return a single value if appropriate. Otherwise it
should provide a string representation of its internal structure (!!)
or, alternatively, only publicly accessible parts. How about that as a
first idea?
How is it useful to dump what you wanted for
System.Windows.Forms.MouseEventArgs.ToString()? What are you going to do
with that string value of all the concatenated property values? you
wouldn't want to parse that for individual properties would you? And if it
did just one property value, which should it do. I think there would be
someone that complained no matter which property or property combination
Microsoft picked.
Simple - tracing. Parsing comment - as above, MouseEventArgs is
obviously an example of the second case. As you say, it's not useful
from a data access/manipulation point of view.
I find that most people use ToString() for collections/arrays of objects
they add/bind to a control such as a combobox. You can add any object to a
ComboBox (or bind array of any object type). When each item is displayed it
calls the ToString() method of each object and displays the results for that
item. When you query for SelectedItem it returns the object selected, and
not the ToString() value. Typically you would add types of a custom type to
the comboBox, such as an Employee object. The ToString() could then return
whatever you want to be displayed when that item is added to a comboBox,
maybe the "LastName, FirstName"? There are other controls that do the same
thing as ComboBox. I think this is the real reason they even made a
ToString() method.
Point taken. I just want something nice for tracing so maybe what I am
really asking is for a DumpState() and dump internal state at that!
Not nice and not appropriate in general. It looks like I'll have to do
some work with System.Reflection for the general case or maybe just
stop wasting time moaning and write a class with a set of overloaded
static DumpState functions for each particular type
Cheers for your comments - you've convinced me by the end of your
comments that I'm looking in the wrong place for what I'm after and
it's been useful to set me straight. Thanks!
Emma Middlebrook
(e-mail address removed)