Simple boxing question

[Mike D Sutton]

Please excuse the terribly 'newbie'ness of this question, unfortunately my C# is very rusty..
What I'm trying to do is write a simple interactive drawing application where a few lines can be moved around on the form. What I'm
trying to do is in the MouseDown() event hit test each line point and when I find one, store a _reference_ to it. The MouseMove
event then checks to see if this reference has been set, if so it will edit this point and cause a redraw which should use the new
coordinates since I'm using a reference to the original point.
The way I understand it is that PointF is a value type and as such I have to box it using (object)Point; and store it in an Object
variable in order to create a reference to it. I then unbox it using PointF p = Point; in MouseMove to edit it's fields, however
this is not editing my original line. Is it just my syntax or am I 'just not getting it'? If this is the case does anyone know of
a good reference for boxing and unboxing and what they're actually used for. I could easily write a simple point class which would
already be an object but I'm curious as to how this would be achieved with value types.
Cheers,

Mike

[Paul E Collins]

"Mike D Sutton" <ED***@mvps.org> wrote:

["boxing" a value doesn't turn it into a reference
to that specific instance of value]

C# is a fairly rigorously object-oriented language, so everything can
be treated as an object. Even a simple value type like an integer can
be treated like an object (reference type) - for instance, you can
write:

int i = 5;
string s = i.ToString(); // calling a method on an int

However, general performance would be very poor if all of this
object-baggage was always passed around with such simple value types,
so behind the scenes your simple native types are "boxed" (put inside
object-wrappers) when an object-operation is required (like the method
call on "i" above). In other words, they don't have the object-baggage
until it's needed.

What boxing *doesn't* do is create a reference to the specific
instance of the value type's value. That is, you can't (as you seem to
be trying to) cast a value type variable to a reference type and
expect changes to the reference to propagate back to the original
value.

PointF is just a pair of co-ordinates - a way of indicating a position
on the screen - so you don't need it to be a reference. You can either
use those co-ordinates to decide where to draw when you come to update
your line, or - if you're a bit more ambitious - create some sort of
Line class of your own (classes are always reference types!) and make
that redraw its own line - or raise an appropriate event so that the
form can do so - whenever either of its co-ordinates is changed.

P.

[Mike D Sutton]

> C# is a fairly rigorously object-oriented language, so everything can

be treated as an object. Even a simple value type like an integer can
be treated like an object (reference type) - for instance, you can
write:

int i = 5;
string s = i.ToString(); // calling a method on an int

However, general performance would be very poor if all of this
object-baggage was always passed around with such simple value types,
so behind the scenes your simple native types are "boxed" (put inside
object-wrappers) when an object-operation is required (like the method
call on "i" above). In other words, they don't have the object-baggage
until it's needed.

What boxing *doesn't* do is create a reference to the specific
instance of the value type's value. That is, you can't (as you seem to
be trying to) cast a value type variable to a reference type and
expect changes to the reference to propagate back to the original
value.

PointF is just a pair of co-ordinates - a way of indicating a position
on the screen - so you don't need it to be a reference. You can either
use those co-ordinates to decide where to draw when you come to update
your line, or - if you're a bit more ambitious - create some sort of
Line class of your own (classes are always reference types!) and make
that redraw its own line - or raise an appropriate event so that the
form can do so - whenever either of its co-ordinates is changed.

Yup, writing a simple point and/or line class would be an easy solution, I was just trying to use some of the features of the
language but it appears my understanding of what it's up to was off - Kept going back to that "everything is an object" line that
all the C# books used to say, they just forgot to add "but they can't always be used like objects.." to the end, or perhaps I was
just reading too much into it. ;)
Even a pointer would suffice for this but it seems that pointers can only be used with unsafe code in C#, is that right?
Ah well, not to worry it's only a simple little demo I'm throwing together so I'll just go the classes route which should suit my
needs.
Cheers,

Mike