TextBoxBase.Lines Property

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

emma middlebrook

Hi

TextBox inherits the following property:

public string[] Lines {get; set;}

From experimentation, it seems every time you get the Lines property,
it hands out a reference to a new *copy* of the array of Lines. It
*doesn't* mention this in the documentation.

Am I correct?
Is this a general rule of similar .NET functions?
So, how can I directly manipulate the array's individual items? I
don't really want to get a copy, change it then pass it back (!!!) -
seems inefficient even in this day and age :-)

Hope someone can clear this up for me.

Thanks

Emma Middlebrook
(e-mail address removed)
 
Hi again

Can anyone confirm this about the Lines property as it does not seem
to be documented? i.e. That it hands out a *copy* of the Lines and so
the only way to update some elements is to get the copy, edit the copy
and set the property to that copy. Also, can anyone explain the
rationale behind this as it seems a little inefficient? Is it due to
an idiosyncracy of String (and if so what is it please)? And are there
are other examples in the framework? One last question - I could find
out myself about the copy issue if I could look at the source code so
I'll try and use ILDasm and see if I get anywhere with that!

Cheers!

Emma Middlebrook
(e-mail address removed)
 
Becaurse an array is fixed in size, it's not possible to add or delete an
item. Use the Add() and/or Remove() Methods of the Items Collection to
modify the items as needed.

I have not looked inside the TextBoxBase (with ILDASM), but I think the
Lines - Property is just an Import/Export mechanism, that is not updated on
eath modification, just if you use the get/set handlers of the property on
reading or writing the property.

GP

emma middlebrook said:
Hi again

Can anyone confirm this about the Lines property as it does not seem
to be documented? i.e. That it hands out a *copy* of the Lines and so
the only way to update some elements is to get the copy, edit the copy
and set the property to that copy. Also, can anyone explain the
rationale behind this as it seems a little inefficient? Is it due to
an idiosyncracy of String (and if so what is it please)? And are there
are other examples in the framework? One last question - I could find
out myself about the copy issue if I could look at the source code so
I'll try and use ILDasm and see if I get anywhere with that!

Cheers!

Emma Middlebrook
(e-mail address removed)

(e-mail address removed) (emma middlebrook) wrote in message
Hi

TextBox inherits the following property:

public string[] Lines {get; set;}

From experimentation, it seems every time you get the Lines property,
it hands out a reference to a new *copy* of the array of Lines. It
*doesn't* mention this in the documentation.

Am I correct?
Is this a general rule of similar .NET functions?
So, how can I directly manipulate the array's individual items? I
don't really want to get a copy, change it then pass it back (!!!) -
seems inefficient even in this day and age :-)

Hope someone can clear this up for me.

Thanks

Emma Middlebrook
(e-mail address removed)
Click to expand...
Click to expand...
 
Becaurse an array is fixed in size, it's not possible to add or delete an
item. Use the Add() and/or Remove() Methods of the Items Collection to
modify the items as needed.
Click to expand...

I only mentioned manipulating already existing elements. But I take
your point. See below though - the reference is to a *copy* so no
point in doing anything to it and expecting it to affect the Lines
array itself. Also, to what Items collection are you referring -
System.Array derives from IList - is that what you mean? But then it's
not fixed in size surely if it supports IList?!?!?
I have not looked inside the TextBoxBase (with ILDASM), but I think the
Lines - Property is just an Import/Export mechanism, that is not updated on
eath modification, just if you use the get/set handlers of the property on
reading or writing the property.
Click to expand...

I checked with ILDASM and it does indeed hand out a new String array
*copy* of the data. So that's that but ... can anyone explain the
rationale behind this as it seems a little inefficient ... would there
be a better alternative?

Thanks for your response!

Emma Middlebrook
(e-mail address removed)
 
Gabriele G. Ponti said:
Yes, you get copy. The class doesn't maintain the text internally as an
array of strings, so when you read the property it converts the text into an
array of strings. When you write the property the process is the opposite.

I understand that this doesn't seem to be the most efficient way, however
it's a design choice. I don't think there is any property in the framework
that returns a reference, or if they exists they are rare cases.

For more information search the framwork documentation for "Property Usage
Guidelines".
Click to expand...

Cheers for this tip - I guess they don't want to have its internals
modified directly. But I had to laugh when I see they are not
following their own guidelines and it is exactly this double-standard
that was causing my problems. Look at this!!

"Properties that return arrays can be very misleading. Use a method
instead. Usually it is necessary to return a copy of the internal
array so that the user cannot change internal state. This, coupled
with the fact that a user can easily assume it is an indexed property,
leads to inefficient code. In the following code example, each call to
the Methods property creates a copy of the array. As a result, 2n+1
copies of the array will be created in the following loop."

Oh well, maybe they thought of that good tip (method please, not
property) at the end of development :-)

Thanks for the reference - problem sorted/explained!

Emma Middlebrook
(e-mail address removed)
 
Back
Top