Cannot implicitly convert type 'object' to 'bool'
-
I keep getting the below error message when I try and run my code. Error 3 Cannot implicitly convert type 'object' to 'bool'. An explicit conversion exists (are you missing a cast?) When I try run the below code: private void Pause_Click(object sender, RoutedEventArgs e) { if (btnPause.Content = "Pause") <<<<
-
Yes, I saw that once I'd replied. It was the changed subject line that threw me off. Sorry, I'm new in the neighbourhood. :)
Ok, first things first...If this is August 10th, I will gladly eat this post. Why are the messages all dated the 10th? Secondly, being "new in the neighbourhood" sounds like a good reason for everyone to pile on and really "get you" for not plowing through all of the messages!! LOL! :laugh:
-
Here's a radical idea: why not throw out the '==' and '===' confusion and make the compiler use the single '=' as either an assignment or a comparative operator depending on the context, like VB does? Oh yeah, because we don't want C# to be like VB with all the stigma associated with such simpleton languages. Sorry, I forgot.
You joke, but there's a lot of truth to that. you need the braces { and the weird 'for' syntax, the ++/-- operators and == for equality. it means it's a real programming language. Microsoft could have solved all of the technical problems without C#, by simply releasing .NET with only VB as the language, and it would simply have been the new version of VB, and the rest of us would be dealing with CString and MFC message maps. But now we get to implement IDispoable!
-
I thought it was a good idea, though I could never do that myself.
-
Instead of coding:
if (btnPause.Content == "Pause")
try writing it this way round
if ("Pause" == btnPause.Content)
then when you inadvertently miss one of the
=signs the compiler will give you a much more useful message.It's time for a new signature.
Yeugh! That looks too much like C++ for my liking. The alternate compiler error is just as confusing; and the alternate code is more confusing to read. The reason they did things the second way in C++ is because:
if (btnPause->Content = "Pause") // Compiles with no errors or warnings NPNPNP
And:
if ("Pause" = btnPause->Content) // Doesn't compile (error)
We don't need to resort to such language hacks in C#. Please, for the kittens!
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Here's a radical idea: why not throw out the '==' and '===' confusion and make the compiler use the single '=' as either an assignment or a comparative operator depending on the context, like VB does? Oh yeah, because we don't want C# to be like VB with all the stigma associated with such simpleton languages. Sorry, I forgot.
Nope. Firstly, there is no === in C#. Secondly the 'inconvenience' of == is outweighed by its benefit. For example:
while((line = reader.ReadLine()) != null)
This would be more difficult to read (albeit probably less confusing) without the explicit identity equality operator:
line = reader.ReadLine();
while(line != null)
{line = reader.ReadLine();
}The second block has absolutely no intent locality (keeping the same ideas in the same place in code).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Personally when performing value comparisons with strings (and many other types) I find I am far less prone to syntax errors if I make myself use the "Equals" method. With strings in particular, it is a good practice to use the static method
String.Equals(string a, string b)
as this eliminates the possibility of a null reference exception. With this in mind, the boolean in your if statement would look like this:
if (String.Equals(btnPause.Content, "Pause"))
"We are men of action; lies do not become us."
You can't get a NRE using the == operator. The .Net runtime essentially does this:
if (Object.ReferenceEquals(a, null) && Object.ReferenceEquals(b, null)) return true;else if (Object.ReferenceEquals(a, null) || Object.ReferenceEquals(b, null)) return false;
else return a.Equals(b);Unless you override the == operator (in which case you should do this in the header). The String.Equals is better because you would be more inclined to use the StringComparison enum[^] - but that is only the case for Strings.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Nope. Firstly, there is no === in C#. Secondly the 'inconvenience' of == is outweighed by its benefit. For example:
while((line = reader.ReadLine()) != null)
This would be more difficult to read (albeit probably less confusing) without the explicit identity equality operator:
line = reader.ReadLine();
while(line != null)
{line = reader.ReadLine();
}The second block has absolutely no intent locality (keeping the same ideas in the same place in code).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Jonathan C Dickinson wrote:
This would be more difficult to read (albeit probably less confusing) without the explicit identity equality operator:
Except your example uses the inequality operator. :doh:
It's time for a new signature.
I was talking hypothetically, i.e. if '=' was the identity equality operator; expressions like the one I used wouldn't work.
while((line == reader.ReadLine()) != null) { } // This is what I was talking about.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
I was talking hypothetically, i.e. if '=' was the identity equality operator; expressions like the one I used wouldn't work.
while((line == reader.ReadLine()) != null) { } // This is what I was talking about.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Jonathan C Dickinson wrote:
if '=' was the identity equality operator; expressions like the one I used wouldn't work.
I don't see that that follows, since the compiler would still recognise
!=as the not equals operator.It's time for a new signature.
Hurm... The example doesn't need a
==operator because it is demonstrating what is possible when a=and a==are distinct. With==around;=becomes more versatile. Because=is more versatile the example I gave is possible. If there was only=(and no==) the example I gave simply wouldn't work (you would get an warning saying that a boolean is never null). I think the mathematical term for this kind of 'proof' is proof by contradiction. The compiler would recognize!=as the not equals operator, BUT it would recognize the=as identity equality and not assignment. Thus the AST would look (where the VB-route is taken) something like this:WHILESTMT(BOOLEXPR(BOOLEXPR("line", Operator.IdentityEquality, "reader.ReadLine"), Operator.IdentityInequality, NULL))As opposed to (and why my example works):WHILESTMT(BOOLEXPR(BOOLEXPR("line", **_Operator.Assign_**, "reader.ReadLine"), Operator.IdentityInequality, NULL))More simply, the following expression results in a boolean type (and boolean value) in VB:a = bIn C# is results in the type of 'a' (and the value contained by 'a'). Which is why these statements are possible:int0 = int1 = int2 = int3 = int4 = 0; // Set all to 0.He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Hurm... The example doesn't need a
==operator because it is demonstrating what is possible when a=and a==are distinct. With==around;=becomes more versatile. Because=is more versatile the example I gave is possible. If there was only=(and no==) the example I gave simply wouldn't work (you would get an warning saying that a boolean is never null). I think the mathematical term for this kind of 'proof' is proof by contradiction. The compiler would recognize!=as the not equals operator, BUT it would recognize the=as identity equality and not assignment. Thus the AST would look (where the VB-route is taken) something like this:WHILESTMT(BOOLEXPR(BOOLEXPR("line", Operator.IdentityEquality, "reader.ReadLine"), Operator.IdentityInequality, NULL))As opposed to (and why my example works):WHILESTMT(BOOLEXPR(BOOLEXPR("line", **_Operator.Assign_**, "reader.ReadLine"), Operator.IdentityInequality, NULL))More simply, the following expression results in a boolean type (and boolean value) in VB:a = bIn C# is results in the type of 'a' (and the value contained by 'a'). Which is why these statements are possible:int0 = int1 = int2 = int3 = int4 = 0; // Set all to 0.He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
You can't get a NRE using the == operator. The .Net runtime essentially does this:
if (Object.ReferenceEquals(a, null) && Object.ReferenceEquals(b, null)) return true;else if (Object.ReferenceEquals(a, null) || Object.ReferenceEquals(b, null)) return false;
else return a.Equals(b);Unless you override the == operator (in which case you should do this in the header). The String.Equals is better because you would be more inclined to use the StringComparison enum[^] - but that is only the case for Strings.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
Jonathan, I can see why my language may have been confusing. I was not meaning to imply that using the == operator would result in a NullReferenceException. My first statement was that the "Equals" method should be used to make the comparison, and I then went on to state that the static method should be preferred for strings (rather than the instance method) since using the instance method could result in a NullReferenceException while using the static method will not. Looking back at my post, however, I can see why one might think I was implying something different, which was not my intent. Regardless, thanks.
"We are men of action; lies do not become us."
-
Ok, first things first...If this is August 10th, I will gladly eat this post. Why are the messages all dated the 10th? Secondly, being "new in the neighbourhood" sounds like a good reason for everyone to pile on and really "get you" for not plowing through all of the messages!! LOL! :laugh:
The messages are dated [date] [month] [year], so they're all posted in 2010, or '10 for short. And it's August 10th now... As for piling on, I'd expect to be shouted at for factual errors, or bad advice (like saying "Use Emacs" ;-) but not so much for being a newbie. And should that happen, well, I've been online long enough to grow a reasonably thick skin.
-
*shrug* :)
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
Instead of coding:
if (btnPause.Content == "Pause")
try writing it this way round
if ("Pause" == btnPause.Content)
then when you inadvertently miss one of the
=signs the compiler will give you a much more useful message.It's time for a new signature.
The point isn't that the compiler gives a more useful message (as has been pointed out), the point is it will give an error message even if the type in question in fact has a conversion-to-bool operator! Whether or not you cannot figure out what the actual cause of the resulting message is, is an entirely different question. I'd suppose everyone intelligent enough to put literals on the left hand side of a comparison will recognise what it means when the compiler states he wants an lvalue! At least I am ;)
-
The point isn't that the compiler gives a more useful message (as has been pointed out), the point is it will give an error message even if the type in question in fact has a conversion-to-bool operator! Whether or not you cannot figure out what the actual cause of the resulting message is, is an entirely different question. I'd suppose everyone intelligent enough to put literals on the left hand side of a comparison will recognise what it means when the compiler states he wants an lvalue! At least I am ;)
-
I agree, but it seems this construct is no longer 'in vogue'. Being a sheep I'll just follow the herd. ;)
It's time for a new signature.
Hmm, has it ever been 'en vogue'? Judging by my experience, I believe the reason why 'nobody' uses it is that few people know about it, not that it isn't 'en vogue' any more. Also, it seems more natural to ask 'does x currently have a value of 2?' than 'does 2 happen to be the value currently stored in x?'. So even when I tell people about it, they might be reluctant to change their style accordingly.
-
Hmm, has it ever been 'en vogue'? Judging by my experience, I believe the reason why 'nobody' uses it is that few people know about it, not that it isn't 'en vogue' any more. Also, it seems more natural to ask 'does x currently have a value of 2?' than 'does 2 happen to be the value currently stored in x?'. So even when I tell people about it, they might be reluctant to change their style accordingly.
Stefan63 wrote:
has it ever been 'en vogue'?
Possibly not, but it was certainly common practice at my last company, which had a fairly large group of developers around the world. I've never actually tried to see if it's in any of the published books on C++ (or C).
It's time for a new signature.