Framework classes' ToString implementations query.

  • Thread starter Thread starter emma middlebrook
  • Start date Start date
E

emma middlebrook

Hi

ToString() for System.Drawing.Point returns a string with the fields'
values. I would really have liked e.g.
System.Windows.Forms.MouseEventArgs.ToString() to dump out all its
useful information: X, Y, Button etc.

I notice most of the classes just return their type name. Not much use
really.

Anyone know why it was chosen to make these implementations pretty
'useless'? Or am I misunderstanding something here?

Cheers

Emma Middlebrook
(e-mail address removed)
 
The default implementation in Object just returns the type name. It's
not that useless implementations were specifically given, just that
they inherited the implementation from Object.

OK, I see what you are saying but the end result is still the same - I
really think they should have made a bit more of an effort providing
at least an attempt at some sensible, useful ToString implementations
where appropriate :-).

Emma Middlebrook
(e-mail address removed)
 
ToString is a member of the base object class from which
all classes are derived. Its simple implimentation is due
to the fact that it is there to be overridden.
Inherit your own class from
System.Windows.Forms.MouseEventArgs and provide a ToString
override that gives you what you want.
 
ToString is a member of the base object class from which
all classes are derived. Its simple implimentation is due
to the fact that it is there to be overridden.
Inherit your own class from
System.Windows.Forms.MouseEventArgs and provide a ToString
override that gives you what you want.

"Inherit your own class" ... and then what?!

Firstly, I can't change the event specification of e.g.
Control.MouseDown so I can't shoehorn the new class you suggest in
anywhere!

public event MouseEventHandler MouseDown;
public delegate void MouseEventHandler(object sender, MouseEventArgs
e);

Secondly, your suggestion doesn't seem to be a good use of
inheritance. I suppose what I will do is just implement a set of
static functions (wrapped in a class in a namespace) that overload on
type and provide what ToString should have provided (in my opinion)!

My original post was really just to air my complaint: that the
framework classes haven't bothered to provide overriden
implementations. I was also really wondering 1) whether anyone agreed
with me :-) and 2) how did they get round it i.e. did they implement
what I suggest above or is there any better solution?

Cheers!

Emma Middlebrook
(e-mail address removed)
 
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.

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.

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.

Michael Lang, MCSD
 
Emma,
My original post was really just to air my complaint: that the
framework classes haven't bothered to provide overriden
implementations. I was also really wondering 1) whether anyone agreed
with me :-) and 2) how did they get round it i.e. did they implement
what I suggest above or is there any better solution?

I'm not sure where the benefit to have MouseEventArgs have a meaningful
implementation of ToString. As generally I will use ToString in preparation
of presenting something to the actual user. What does the actual user of my
program care what MouseEventArgs contains. I can see presenting Point to the
user as a string. For example in the status bar...

However I do agree with you, in the case of Debug & Trace WriteLine, having
MouseEventArgs return something more meaningful would have been nice...

Just a thought
Jay
 
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)
 
Jay B. Harlow said:
Emma,

I'm not sure where the benefit to have MouseEventArgs have a meaningful
implementation of ToString. As generally I will use ToString in preparation
of presenting something to the actual user. What does the actual user of my
program care what MouseEventArgs contains. I can see presenting Point to the
user as a string. For example in the status bar...

I was trying to argue that it should have been used to allow
tracing/dumping state where possible. Previous poster has now
convinced me I'm asking for something that's wrong.
However I do agree with you, in the case of Debug & Trace WriteLine, having
MouseEventArgs return something more meaningful would have been nice...

Yep, that's what started me moaning :-) I just didn't want to do any
work I guess.
Just a thought
Jay

Thanks!

Emma Middlebrook
(e-mail address removed)
 
Back
Top