Cannot implicitly convert type 'object' to 'bool'

[michaelbierly]

you are trying to assign "Pause" to btnPause.content (=) you need the equality comparison operator (==) I dont have a lot of context to what you are doing, but you might want to try refering to sender rather than btnPause in the code.

[tom1443]

Ah, bitten by the old "==" typo. Don't feel bad it was my first coding mistake in C 25 years ago. I still occasionally make that error but it usually takes me a whole lot less time to find it.

[Devi Ganesan]

error in line "if (btnPause.Content = "Pause") " it should be like btnpauser.content == "Pause" hopefully this should fix the error

[TNCaver]

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.

[Luc Pattyn]

I don't care much what symbol(s) get used for operators, I started out in Fortran which used .EQ. for equality testing. However if assignment and equality test operators coincide, some semantics get lost, as in a=b==c versus a=b=c; there is only so much context analysis can do. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

[Bob1000]

Silly mistake, but hey CodeProject a bit of downer to place this question on the daily news email. or maybe someone is having a bad day and wants to pass it on.....:)

[ErrolErrol]

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:

[Kenneth Kasajian]

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!

ken@kasajian.com / www.kasajian.com

[alton turner]

I thought it was a good idea, though I could never do that myself.

[Jonathan C Dickinson]

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)

[Jonathan C Dickinson]

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]

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)

[Lost User]

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.

[Jonathan C Dickinson]

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)

[Lost User]

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.

[Jonathan C Dickinson]

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 = b In 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)

[Lost User]

:confused:

It's time for a new signature.

[cor2879]

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."

[Orjan Westin]

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.

[Jonathan C Dickinson]

*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)