ComboBox IsEmpty not working?

[jed76]

I can't understand what I'm doing wrong here:

I'd like a ComboBox to either be visible or not (or I could use DisplayMode.Edit / DisplayMode.View) if another ComboBox is empty. However, it doesn't seem to work and even when I use:

If(!IsEmpty(ComboBox1.Selected),DisplayMode.View,DisplayMode.Edit) for the DisplayMode of the other ComboBox, it still seems to think that there is some content in the ComboBox even when it is actually blank / empty? This means the other ComboBox remains in VIEW mode even when the other box is blank?

[RandyHayes]

@poweractivate 

Selected on a Combobox is not going anywhere!!  The property that was always in question was SelectedText property.  It is absolutely ambiguous and has no particular use because it really ignores the underlying record.  And, what is the purpose of a Selected or SelectedItems property...to return the record of the selection!

.Selected on a combobox will return the last selected item.  If you select 10 items in the combobox, then the 10th one is what Selected would represent.  Is it meaningful for a multi-select combobox?  Not really, but in the context of determining if anything is selected at all, it is highly sufficient.  In the case of a single-select combobox it is highly needed.

As for the confusion - it is common across all of PowerApps when dealing with properties to observe the plurality of the property.  Anything with an "s" on the end is going to provide a Table.  Anything without it, will provide a record.  i.e.   Items is a table.  Item is a record.  SelectedItems is a table.  Selected is a record, etc.

So again, to re-iterate on the use of either for a combobox - If you have multi-select, then Selected will return the last selected item.  This is useful in many ways, but one in particular is just to determine if anything is selected.  SelectedItems will always be a table and sometimes it is a waste of time to pull the table and then pull a record when Selected will suffice.

As for the "unexpected outcome"...it is not unexpected!!  It is the last item selected.  If you wanted to actually know the last item selected as the use selects items, then it is highly important - otherwise there would be NO way to determine it.

As for the docs...well, there is a lot of missing stuff in the docs.  I always consider them a work in progress!!

But this point - "The Selected property on a Combo Box control introduces ambiguity on what Record is returned in the case that the Combo Box does have multiple selections. " Is not true.  It is not ambiguous!  It is the last selected record of the control.  If you were in a scenario where you needed to pull in some other data based on the selection made (one at a time) while still needing to hold the table of selections, then Selected is highly important and accurate.

I would not expect to see Selected deprecated in any way.  This is a highly important property of the combobox.  Unlike the SelectedText property that has been marked as deprecated for years it too has not gone away (but still should never be used).  Selected is not marked as such and would completely break MANY apps as it is relied on heavily.

[poweractivate]

@RandyHayes I agree with it, I think it should be seen this way. So it is the last item in multi select Combo Box. It would be then be shorthand to Last(cb.SelectedItems). I agree it would be more convenient this way because a one selection Combo Box is quite frequent and always requiring Last(cb.SelectedItems) could be pedantic. Also, if Selected really does internally pull one record in backend, and the use case is just to check if it is selected, this could be important as the other way would introduce inefficiency. Also, yes, lots of apps rely on it, I am aware of it. In the context of Power Apps, my understanding is similar to yours and I like it that way. Thank you for taking the time to clarify it!

[RandyHayes]

@jed76 

If you have a blank selection, then you want to have it reflected in the record when you submit the form.

To do that, make sure you have the formula level error management feature turned on.

After that, your only concern (as far as I can tell) is to simply determine if anything is selected in the combobox in order to govern the DisplayMode of the other control.  Is that not correct?

[RandyHayes]

@jed76 

Actually No-and Yes!! 😂  It would not be the equivalent of Last(cb.SelectedItems).  Using that would give you the last item in the table of selections.  That would/could be unreliable.  

Selected would give you the last item that was selected.  

NOW...I say that it could be unreliable because that is something that I would expect could cause issues at any point.

Technically the combobox, currently, will build a table of selections that is ordered by the selections made.  And, technically, Last(selectedItems) would give you the last selection made.  But...if the ordering of that returned table is impacted in any way, then it would not necessarily be the last selected item.

Is it safe to bet on Last(selectedItems)?  Probably so, but then the lazy typing person comes out in me and say there is much less typing for Selected over Last(selectedItems) 😉

[poweractivate]

@RandyHayes 

You are right, I think it may not even be the same, and to me the principle behind Selected makes sense exactly like that. I really think your explanation is very excellent on this matter and it's very helpful, thanks for it! 🙂

[RandyHayes]

@poweractivate 

Oh my - happy to explain anything in PowerApps!  I've been living and breathing this stuff for many years now non-stop!  So it is second nature to me.  I am more than happy to explain because I really want everyone to share that knowledge and take their PowerApps to a whole new level!!  The sooner people get out of the weeds of "plumbing" the sooner they design so many wonderful things.  

When someone says "Can we make it do this?" - It's that difference between a response of "Hmmmm" and "Piece of cake!"

[jed76]

I have formula level error management turned on and it still won't patch a blank back in this particular ComboBox but it does with the other?!

SO essentially, yes you're right. I can get the DisplayMode of the other ComboBox to change when the gallery is "new". However, when I save it back to the data source and got back into the Gallery I still want it to do the same. As the DefaultSelectedItem of the ComboBox is set to read the value from the Data Source, it's obviously no longer blank? So, I created an OR statement based on whether the ComboBox is blank OR if the ThisItem.Value is blank, which does work, but obviously only if I patch a blank record back to the data source first? This is where I am finding a problem as I can't patch blank?

[jed76]

@RandyHayes It's OK, I have sorted the Patching BLANK - this now works. I had a toggle button to activate only when it detected a change which then flagged when a change to an item had taken place and so whether a patch back was needed. I'd forgotten to include this particular combobox in the logic which activated the toggle!

However, any thoughts on how I can set the display mode of the other combo box to still work if the other combobox's default selected item isn't blank until it is patched back if you see what I mean? Everything is now working as expected, but I need to save the gallery back to the data source (so the blank is patched back first) and then I need to reopen the gallery again. I'd sooner not need to do this.

[RandyHayes]

@jed76 

Your DSI property is going to dictate what IS selected.  So looking at the SelectedItems will give you the results of the DSI (as long as no other selections are made).  However, if you want to check the status of the DSI even beyond the selection by the user, then you would need to utilize that formula.

I was reading back through the posts and I don't see that you have posted your DSI property (or maybe I just missed it)...so what is that?

[jed76]

Thanks.

it is ThisItem.CrewName