Casting problem

[tshad]

I am trying to do this in one statement;

This works:

PropertyType pt1 = propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Sales"; });
cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
pt1));

But I can't seem to get this to work:

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; }).PropertyTypeID)));
break;

I get an error:

Cannot convert type 'int' to 'PropertyType'

If I put an (int) in front of it I get the same error.

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(int)(PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; }).PropertyTypeID)));
break;

I have also tried putting parens after the (int) and before the
..PropertyTypeID with same error:

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(int)((PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; })).PropertyTypeID)));
break;


Does it have to be created as an object before?

Intellisense knows that the return is a PropertType as it gives me the list
of properties when I put the "." in - so I would assume that it should be
able to know that I am passing back an int.

Thanks,

Tom

 

[Paulus E Kurniawan]

I am trying to do this in one statement;

This works:

PropertyType pt1 = propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Sales"; });
cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
pt1));

But I can't seem to get this to work:

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; }).PropertyTypeID)));
break;

I get an error:

Cannot convert type 'int' to 'PropertyType'

If I put an (int) in front of it I get the same error.

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(int)(PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; }).PropertyTypeID)));
break;

I have also tried putting parens after the (int) and before the
..PropertyTypeID with same error:

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(int)((PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; })).PropertyTypeID)));
break;


Does it have to be created as an object before?

Intellisense knows that the return is a PropertType as it gives me the list
of properties when I put the "." in - so I would assume that it should be
able to know that I am passing back an int.

Thanks,

Tom

tshad,

The problem is because you are trying to cast an int to PropertyType. Try
this instead:

cmd.Parameters.Add(new SqlParameter("@PropertyTypeID",
propertyTypesList.Find(delegate(PropertyType pt)
{ return pt.Description == "Listing"; }).PropertyTypeID));

 

[tshad]

tshad,

The problem is because you are trying to cast an int to PropertyType. Try
this instead:

cmd.Parameters.Add(new SqlParameter("@PropertyTypeID",
propertyTypesList.Find(delegate(PropertyType pt)
{ return pt.Description == "Listing"; }).PropertyTypeID));

It works fine.

I was puting the (PropertyType) in front of the delegate since the delegate
was passing back a PropertyType object. I assumed that I would have to tell
it what type of object it was before I could use the property. Obviously, I
was wrong.

Thanks,

Tom

 

[Marc Gravell]

I am trying to do this in one statement;

(see also previous thread) Why do you keep trying to do everything in
one statement? This aim is often detrimental to code quality...

 

[Christof Nordiek]

This works:

PropertyType pt1 = propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Sales"; });
cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
pt1));

But I can't seem to get this to work:

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
(PropertyType)(propertyTypesList.Find(delegate(PropertyType pt)
{return pt.Description == "Listing"; }).PropertyTypeID)));
break;

This is not the same as above. Why did you add PropertyTypeID? In the first
statement you implicitly cast the result of Find to PropertyType. In the
second statement you cast the PropertyTypeID to PropertyType.

I get an error:

Cannot convert type 'int' to 'PropertyType'

I guess PropertyType is int and can't be cast to PropertyType

Christof

 

[tshad]

(see also previous thread) Why do you keep trying to do everything in
one statement? This aim is often detrimental to code quality...

Probably true.

I like to consolidate where possible.

For the same reason to use anonymous functions (at least one of the
reasons). Why create a function name I am going to call only once, where I
would create the function and then call the function. Why not just do it in
one call.

Why is it detrimental to code quality?

It could be that in some cases it is harder to follow by putting 2 anonymous
delegates in one method call. Not incorrect, just hard to follow.

Is that what you mean?

Thanks,

Tom

 

[tshad]

This is not the same as above. Why did you add PropertyTypeID? In the
first statement you implicitly cast the result of Find to PropertyType. In
the second statement you cast the PropertyTypeID to PropertyType.

Your right, that was my mistake.

It should have been:

cmd.Parameters.Add(new SqlParameter("@" + "PropertyTypeID",
pt1.PropertyTypeID));

but that wasn't causing the problem. The casting to (PropertyType) was the
problem. PropertyTypeID is an int property in PropertyType. And by adding
the (PropertyType) cast I was, apparently, trying to cast the PropertyTypeID
(which is an int) to a PropertyType object. I just had to take the cast off
to make it work. I was under the assumption that I needed to say what type
of object I was dealing with before I could add the property
(.PropertyTypeID).

Thanks,

Tom

 

[Marc Gravell]

I like to consolidate where possible.

For the same reason to use anonymous functions (at least one of the
reasons).

Actually I'm all-up for anonymous methods for delegates; agree with
you strongly. Even better in C# 3 where you can use the much
abbreviated lambda syntax.

But there's a line smoewhere, between simpy consolidating, vs
deliberately banging your code out of shape to make it into one line/
statement; the fact that you have to ask how to do it in one statement
probably means you're on the far side of the line. It isn't helping
you, and it can *only* complicate the code. Fine if throwaway, but
most of the longterm cost of code is support/maintenance - which means
(in a typical corporate setupt) that you might not be the person
editing the code next time. If the next person has to stop and think
"what does this do?" then you've achieved an own goal; there are times
when simple code, and meaningful variable names go a long way towards
creating maintainable code.

It could be that in some cases it is harder to follow by putting 2 anonymous
delegates in one method call. Not incorrect, just hard to follow.

I agree - not incorrect (see LINQ...) - but I would advocate using
lambdas if possible; they make such things a lot easier to follow;
regardless of the body of the anon/lambda, the human eye/brain can
only see so much at once; a lambda takes only a fraction as much
effort to understand as an anon-method.

Marc

 

[tshad]

Actually I'm all-up for anonymous methods for delegates; agree with
you strongly. Even better in C# 3 where you can use the much
abbreviated lambda syntax.

But there's a line smoewhere, between simpy consolidating, vs
deliberately banging your code out of shape to make it into one line/
statement; the fact that you have to ask how to do it in one statement
probably means you're on the far side of the line. It isn't helping
you, and it can *only* complicate the code. Fine if throwaway, but
most of the longterm cost of code is support/maintenance - which means
(in a typical corporate setupt) that you might not be the person
editing the code next time. If the next person has to stop and think
"what does this do?" then you've achieved an own goal; there are times
when simple code, and meaningful variable names go a long way towards
creating maintainable code.

Sounds reasonable. If it costs more to put it together and even more to
maintain, then it probably wasn't the best way to go.

I agree - not incorrect (see LINQ...) - but I would advocate using
lambdas if possible; they make such things a lot easier to follow;
regardless of the body of the anon/lambda, the human eye/brain can
only see so much at once; a lambda takes only a fraction as much
effort to understand as an anon-method.

I haven't really done much with lambdas yet, but heard it was pretty neat.
Looking forward to playing with it.

Thanks,

Tom