Another "Incompatible types for comparison" error

[TedBabcock]

I'm hoping @RandyHayes has another solution up his sleeve. I am getting the same "Incompatible types for comparison" error that two others have recently reported, but my situation is not like theirs. I have a popup component, cmpPopupOK_AAP that has an input property and an output property, both Boolean. They both default to false: the output property's default is false in the component, and the input property's value is the global variable boolApprPopupVisible, which is set to false in App.OnStart. The visibility of the popup component is when these two properties do not equal each other, which should evaluate to false on startup, thus making the popup not visible. But when the app starts, the popup is visible.

I inserted a label to show the value of input <> output, and it shows true when the app starts, even though both values are false. The "<>" sign in the label formula area has blue lines beneath it, and the error message that shows when I hover over it says, "Incompatible types for comparison. The left value is Text and the right value is a Boolean." But the left value is clearly Boolean, and Power Apps even says so:

The right value is also Boolean, as Power Apps says:

But the comparison can't be completed because of the incompatible types error.

It doesn't seem to be a problem with App.OnStart. After I render the popup not visible, I click the ellipses by App in the navigation menu and click Run OnStart, but it doesn't suddenly become visible. It's only when the app is opened for the first time that this happens. It doesn't matter if it's opened in edit mode, or just played the way an end user would.

Also, it doesn't matter how many times I toggle the value of boolApprPopupVisible, which controls the input property; the popup stays visible. It's only when I change the output property by clicking the component's OK button that the comparison is recognized and the popup disappears. I double-checked both properties in the component, and they are indeed defined as Boolean.

I was half hoping that, while going through the explanation and verifying all the steps, I would stumble onto the cause of the problem, but that did not happen. Thanks for any assistance you can offer!

[RandyHayes]

@TedBabcock 

You cannot compare input properties of a component.  They are properties to be set, not read.  So in your case you need to compare the property value from the input to the output.

You state that the input property is set to boolApprPopupVisible, so that is what you need to compare the output to.  

boolApprPopupVisible <> cmpPopup_OK_APP.PopupOKVisible_output

However, if I had to make a guess, I would say you are trying to determine if a user has selected OK (or something like that) in the component to determine if the component is visible. 

If so, I would highly recommend using a behavior rather than an Output property for this.

I hope this is helpful for you.

[TedBabcock]

That's odd, because after I click on the popup's OK button, it works as planned, with the comparison of input and output properties. It's only on startup that it doesn't want to work right.

I did try your suggested comparison, and I get the same error message.

I'll keep poking around and look into behaviors. I'll post again here if I discover anything. Thanks for your help!

[RandyHayes]

@TedBabcock 

How is your Output property defined in the component?

EDIT: oh and sorry, I misspoke on the reading of the input properties.  Yes, you can read those values.  Sorry about that.

[TedBabcock]

@RandyHayes It is defined by a Boolean variable, which is toggled when the OK button is clicked.

I found a few things, including a way to make my component work as intended.

But first, I found out that the "Incompatible types for comparison" error did not appear when I put the comparison in a label without the concatenated text. Then I tried putting parentheses around the comparison in the concatenated label, and that also made the error message disappear.

I set up an OnReset action in the component that does the same thing that the OK button does: toggle the component's visibility variable, which controls the output property.

I still had the problem that the component was not evaluating the output value correctly -- it showed it as false to begin with, which should have made the component not visible at startup. It was only when I clicked the OK button twice that the component would go away: the first click changed the output value to true, and now the comparison evaluated correctly, keeping the component visible. When I clicked it a second time, it set the output value to false again, and now the comparison evaluated to false, and the component became not visible.

So in my App.OnStart, I included the statement Reset(component) twice, to duplicate clicking the OK button twice. Lo and behold! The component was not visible the next time I opened the app. I triggered it by changing the variable that controls the input property, and the component was visible; and clicking the OK button made it disappear again. So now it's doing what I need it to. The comparison between the input and output values does seem to work.

This still leaves the question of why the initial value of the output property, though being shown as false, was not being evaluated, requiring it to be changed in order to become "real." It would be nice to get that problem solved with something in the component, so that the rather kludgy way of resetting it doesn't have to be employed.

Thanks again for your help!

[RandyHayes · Accepted solution]

@TedBabcock 

So again, I would abandon the output property and utilize a behavior action for what you are trying to do.

Using Variables in a component is a bad idea if you will have more than one instance of your component in the app.

At this point there is a bug in components that has gone on for too long, which is that the components share variables across instances - this includes controls in the component.  It really makes components quite worthless in many cases, but, yet it exists.

I make a lot of pop up components like you are doing and the output has never been a good one.  Turn them into behaviors and I believe you will resolve your issues.

Seems like you are trying to set the visibility of the component based on once they hit ok button.

If so, I'd suggest the following:

  In your app - when you want the pop up to show, set a variable to something like UpdateContext({lclShowPopup: true})

  Set the Visible property of your Popup component to : lclShowPopup

  Create a Behavior property in your Component called : OnOk  (set to Boolean)

  In the button or other action of the component, use set the formula to: Parent.OnOk()

In your app component, set the OnOk action that you now have to : UpdateContext({lclShowPopup: false})

You can get more mileage out of the pop up with setting the variable to a text value - the text you want to display in your popup to: UpdateContexct({lclShowPopup: "blah blah blah, press ok"})

Then, the visible property of the component to : !IsBlank(lclShowPopup)

The input property of your component for the text of your message to : lclShowPopup

And change the OnOk action to : UpdateContext({lclShowPopup: Blank()})

[TedBabcock]

@RandyHayes  Yes, I guess I never did make it explicit: I'm trying to set the component's visibility with all of this. 

I never knew of the bug with component variables. I only have the one popup in this app, but it's good to know for the future.

I will set up the behaviors. One quick question: this is an experimental feature. Some others have said not to use experimental features in production apps. Do you think using behaviors in components will be okay?

Again, many thanks for all of your help, and for dealing with all my newbie questions, but I don't want to be given a fish, I want to learn to fish so that I can better deal with all the issues that will no doubt arise down the road. I'll report back how it goes.

[TedBabcock]

Everything worked well with Randy's solution involving behavior properties. Thanks!

To make another thing clear: the inspiration for my original attempt, comparing input and output properties, is a room in your house that has two doorways in and therefore two light switches. Whether the light is on or off is not determined by the up-down position of either light switch, but by the combination of both of them: if they're both up or both down, the light is on, and if one is up and the other is down, the light is off.

[PeterCBell_au]

FYI or anyone having a similar problem.

I had a component (part of a Lib) with a large number of properties, with various properties referencing other properties within the same component.

Who knows why, but one of the components started throwing multiple incompatible type errors (expecting objNull).

There were no code/logic problems demonstrated by this sequence....  Duplicate the component, reference that component from test screen checking the component properties, all in order. Execute Lib save --> no problem. Close/reopen Lib --> duplicated component had exactly the same large number of objNull errors.

Relevant or not, I had used the same names for a number of property arguments for different properties and thought that might be the cause, so made sure they were all unique -->no change. 

The solution was to go through and use disambiguated references in formulas when calling another property. eg. funcA(parA,parB,...) with a formula of =[@parA]+[@parB]+Self.funcX([@parC]) instead of =parA+parB+Self.funcX(parC).

However, after doing that there was one final property with the same error (eg.funcB) not solveable by the above. I left that property, copied it to a new property (funcZ) with exactly the same formula, and changed all references (ie. all references to Self.funcB changed to Self.FuncZ) and problem solved.

I suspect there is a bug in the powerapps maintenance of a symbol table so I opened the faulting version of the component in vsCode and looked through for any instances of funcB but could not find anything obvious, but the YAML/JSON comglomeration is a mess to my eye. In any case, from what I can work out, the src files created by the tool are a derivative of the underlying code used by make.powerapps, not the actual execution code.

my 2 cents here about the pack/unpack utility: Although VB might be almost dead, exporting/importing using single VB.NET like file syntax (not executable by VS) would represent a much more usable tool for citizen developers who want to flex powerapps, than bending a markup language to express code.