VB to C#

[Arvi]

Hi,

im converting a VB web app to a C#.



i have problem with the following line

ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

please let me know


Thanks

 

[Mark Rae]

ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

ds.Tables[0].Rows[ind]["taskid"]

 

[Scott M.]

Why isn't the use of the Item property supported? A DataRow is an object.
In VB.NET, you can use the object's Item property, so why not in C#?

ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

ds.Tables[0].Rows[ind]["taskid"]

 

[Jon Davis]

The use of the Item property is supported. But C# introduces a C# language
specific feature called indexers. Assuming your Item property is default,
these build on the "Item" property behind the scenes For example, the
following is a demonstration of an indexer declaration in C#:

public object this [object hashCode] {
get {
return _hashtable(hashCode);
}
set {
_hashtable(hashCode) = value;
}
}

The ildsm output of the above is equivalent to the following code in VB.NET:

Public Default Property Item (hashCode As Object) As Object
'...
End Property


- Jon

Why isn't the use of the Item property supported? A DataRow is an object.
In VB.NET, you can use the object's Item property, so why not in C#?

ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

ds.Tables[0].Rows[ind]["taskid"]

 

[Cor Ligthert [MVP]]

Scott,

I am glad that you are writting this and not me, I had this expirience
already in past.
In VB.Net you can do both.

I cannot find the English documentation anymore, have a look however to the
code part of this.

http://msdn.microsoft.com/library/i...html/frlrfsystemdatadatarowclassitemtopic.asp

Cor

Why isn't the use of the Item property supported? A DataRow is an object.
In VB.NET, you can use the object's Item property, so why not in C#?

ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

ds.Tables[0].Rows[ind]["taskid"]

 

[Scott M.]

I know that you can skip the Item property in VB.NET, as it is the default
property. But, the OP says that using Item doesn't work in C#, so my
question is: Why doesn't it work in C# when it is an object we're talking
about, not the programming language?

By the way, the link you supplied is written in Spanish (I think).

Scott,

I am glad that you are writting this and not me, I had this expirience
already in past.
In VB.Net you can do both.

I cannot find the English documentation anymore, have a look however to
the code part of this.

http://msdn.microsoft.com/library/i...html/frlrfsystemdatadatarowclassitemtopic.asp

Cor

Why isn't the use of the Item property supported? A DataRow is an
object. In VB.NET, you can use the object's Item property, so why not in
C#?

ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

ds.Tables[0].Rows[ind]["taskid"]

 

[Scott M.]

The use of the Item property is supported.

But the OP says it doesn't work in C#?

 

[Cor Ligthert [MVP]]

By the way, the link you supplied is written in Spanish (I think).

Yes, because I could not find the English one anymore on MSDN and my idea
was that you as American could speak Spanish as well.

Cor

Scott,

I am glad that you are writting this and not me, I had this expirience
already in past.
In VB.Net you can do both.

I cannot find the English documentation anymore, have a look however to
the code part of this.

http://msdn.microsoft.com/library/i...html/frlrfsystemdatadatarowclassitemtopic.asp

Cor

Why isn't the use of the Item property supported? A DataRow is an
object. In VB.NET, you can use the object's Item property, so why not in
C#?



ds.Tables[0].Rows[ind].Item["taskid"]

ERROR - 'System.Data.DataRow' does not contain a definition for 'Item'

whats the alternate that i can use?

ds.Tables[0].Rows[ind]["taskid"]

 

[Jon Skeet [C# MVP]]

I know that you can skip the Item property in VB.NET, as it is the default
property. But, the OP says that using Item doesn't work in C#, so my
question is: Why doesn't it work in C# when it is an object we're talking
about, not the programming language?

C# doesn't allow indexers (properties with parameters) to be referenced
by name. It's absolutely to do with the programming language.
Personally I think it's one of C#'s weaknesses, but there we go...

 

[Cor Ligthert [MVP]]

Jon,

Forgive me, but today I had the idea, would Jon have that on his C# shooting
VB.Net page?

Do not react on the shooting part, I have just fun with a fine glass of wine
beside me, it is one hour later at my place than on your place you know..



Cor

 

[Jon Skeet [C# MVP]]

Forgive me, but today I had the idea, would Jon have that on his C# shooting
VB.Net page?

I'll put it on the list now - it's a reasonably significant difference.

 

[Jon Skeet [C# MVP]]

I'll put it on the list now - it's a reasonably significant difference.

.... except that it was already there

 

[Jon Davis]

But the OP says it doesn't work in C#?

And as I said, it works--you can get the data out of the Item property from
C# where the Item property is defined in VB.NET--but the C# syntax to do so
uses the indexer syntax.

Jon

 

[Jon Davis]

And as I said, it works--you can get the data out of the Item property
from C# where the Item property is defined in VB.NET--but the C# syntax to
do so uses the indexer syntax.

Jon

... said syntax is "object[..]" rather than "object.Item[..]".

As far as I'm concerned, C# indexers and the Item property are one and the
same, just different nomenclature and calling syntax per language.

Jon

 

[Scott M.]

Well, I guess this is where my confusion lies. I must not fully understand
indexers, because you claim it is the answer to my question, but I don't see
how.

My question is: If the object has an Item property, then why can't you call
it (and by call it, I mean literally state the Item property in code) in C#?
You say the answer is because C# uses indexers, but it seems to me that
indexers just allow you to use the indexed property as a default property
(which is the same in VB.NET - - You don't *have* to actually state the Item
property). So, I guess I need to restate my question....

Although you can utilize the Item property, why can't you do it by actually
calling the property directly?

And as I said, it works--you can get the data out of the Item property
from C# where the Item property is defined in VB.NET--but the C# syntax
to do so uses the indexer syntax.

Jon

.. said syntax is "object[..]" rather than "object.Item[..]".

As far as I'm concerned, C# indexers and the Item property are one and the
same, just different nomenclature and calling syntax per language.

Jon

 

[Scott M.]

Yes, because I could not find the English one anymore on MSDN and my idea

was that you as American could speak Spanish as well.

Hmmm.

 

[Jon Davis]

Although you can utilize the Item property, why can't you do it by

actually calling the property directly?

Calling the property directly in syntax is unsupported for the same reason
as get_Item(..) is unsupported. It is a "language feature" and boxes the
coders into a common coding convention.

In C# the parameterized Item property is reserved specifically for indexers,
and Item[..] (VB.NET) / this [..] (C#) / get_Item (MSIL) is the only indexer
property that C# uses. VB.NET supports parameterization for any custom
properties besides Item, but C# only supports the one property, which in
code is "this[..]" and not "Item[..]", but in MSIL is always
get_Item(..)/set_Item(.., ..). It is indeed a language limitation, but I
consider the limitation an intended one, which makes it a feature. It makes
it much less difficult to get confused about whether you're accessing an
object's indexer or an object's property's indexer, i.e. ...

myObject.myIndexedProp["three"]

.... is "myIndexedProperty" above implemented as an indexed myIndexedProp
property of myObject, or is it the Item property of an object that is
returned by a non-indexed myIndexProp property of myObject??

By forcing C# to use only one optional property as an indexed property,
understanding the code becomes significantly less ambiguous and awkward.
Exposing that single indexed property as "this[...]" made the property bound
to the object by its explicit name. By compiling down to MSIL as
get_Item(..)/set_Item(..) (the same MSIL method names that are used by
VB.NET's Item property), the property became inline with industry common
naming conventions for collection indexers and ultimately VB.NET coders can
then call C#'s clean "object[...]" indexer as "object.Item[...]" which is
more familar with the VB coder community anyway.

Jon

Well, I guess this is where my confusion lies. I must not fully
understand indexers, because you claim it is the answer to my question,
but I don't see how.

My question is: If the object has an Item property, then why can't you
call it (and by call it, I mean literally state the Item property in code)
in C#? You say the answer is because C# uses indexers, but it seems to me
that indexers just allow you to use the indexed property as a default
property (which is the same in VB.NET - - You don't *have* to actually
state the Item property). So, I guess I need to restate my question....

Although you can utilize the Item property, why can't you do it by
actually calling the property directly?

The use of the Item property is supported.

But the OP says it doesn't work in C#?

And as I said, it works--you can get the data out of the Item property
from C# where the Item property is defined in VB.NET--but the C# syntax
to do so uses the indexer syntax.

Jon

.. said syntax is "object[..]" rather than "object.Item[..]".

As far as I'm concerned, C# indexers and the Item property are one and
the same, just different nomenclature and calling syntax per language.

Jon

 

[Jon Davis]

Or the shorter answer is, because supporting object.Item[..] and object[..]
at the same time would be unnecessarily redundant. The redundancy is
necessary in VB.NET because VB.NET supports multiple parameterized
properties with custom names.

Jon

 

[Jon Davis]

The redundancy is necessary in VB.NET because VB.NET supports multiple
parameterized properties with custom names.

.... while also supporting Default properties (when parameterized), which was
added because VB6 coders whined and boo hoo'd and complained and dogged and
sobbed and cried and screamed and hollered about how much they needed
default property behavior. That or else the VB.NET team were smart enough to
figure out that it would happen, I don't know which. ;->

C#, meanwhile, has a cleaner history, literally. Except for dealing with VB
programmers, C# doesn't need nor want what you're asking about. You get an
indexer... MSIL's use of get_Item()/set_Item for the indexer was a handy
fluke for VB folks.

Jon

 

[Jon Skeet [C# MVP]]

C#, meanwhile, has a cleaner history, literally. Except for dealing with VB
programmers, C# doesn't need nor want what you're asking about. You get an
indexer... MSIL's use of get_Item()/set_Item for the indexer was a handy
fluke for VB folks.

Well *I* want what VB.NET supports in terms of multiple indexed
properties. Suppose I want to expose an array in a read-only fashion
(i.e. I don't want people to change the elements of the array). To do
that in a simple way in C# requires an extra class which in turn has an
indexer. Otherwise I'm stuck with

GetSomeCollection(int index)

Alternatives are just exposing the array with a property and telling
people not to change it (urgh) or copying it each time (eek).

Generics make it easier to accomplish in .NET 2.0 as we can use *one*
container class for all types, but even so, multiple indexers would be
neater.