I have a MobilePopupMenu that has a list of Countries, but the first item in the list is a blank so that no country appears as the default, but the user must select their country.
If a user selects a country (eg England) from the MobilePopupMenu then MobilePopupMenu.SelectedRowText will return the correct text (ie England).
But if a user selects a country (eg England) from the MobilePopupMenu, then selects the top Blank country value, then MobilePopupMenu.SelectedRowText will return the incorrect text (ie England) rather than the blank value that is being displayed.
Why doesn’t MobilePopupMenu.SelectedRowText return the blank value?
This has been fixed and will be available in the next release: #81787 (closed)
Meanwhile, may I suggest something?
Although generally a bad idea using just an empty string as “No selection” from a UI perspective, that’s even more important under iOS. Here, when the app is running… even the “empty” options is less than noticeable for the user.
Being that said, maybe you can use this as a workaround?
Implement the SelectionChanged event handler for the PopupMenu1 instance and put the following code in the associated code editor:
if item.Text = "" then
me.SelectedRowIndex = -1
end if
In addition, if the only purpose is that no country appears as the default, then you don’t need to do anything at all: just populate the list… and that’s all. And even if you do that using the Inspector Panel from the IDE, keeping the “Selected Row Index” to -1 is everything needed.
@Javier_Menendez There’s something else to consider here as well. Often a blank or empty row is used because it makes things immediately clear how to unselect a popup menu. Visually you either have a value or don’t have a value, which makes recognition almost instantaneous, especially as folks have been trained on this model for decades now.
By using “Unknown” you introduce the scenario where the user must parse through the entire list to try and find the “not set” value. As this is fairly arbitrary, some devs might call this “Unknown”, others “None”, or maybe something else. Some popups might not even have an unset value, so the user is now on a wild goose chase, if they’re even thinking this far ahead, for some value that may or may not exist.
There’s also a semantic difference between “Unknown” and “not set.” Unknown can itself be a meaningful value, whereas a blank clearly indicates the absence of one.
So from a UX perspective, having a blank row is actually helpful and, depending upon the use case for the popup, preferred.
That’s a great call out @Javier_Menendez and I guess I was thinking too much about Desktop here where blank values are definitely a thing. So I definitely stand corrected.
Reviewing how Apple is doing this these days, it looks like they’re using the value of None at the top of the list, and then adding a separator to segment this away from the values (which fixes the issue I noted of trying to find the “Not Selected” value in the list).
As this has been a topic of discussion in the forums recently, I created this ticket so that we can mirror Apple’s look and feel in Xojo iOS/iPadOS apps:
Yes, if this is indeed backed by a UIMenu, then this will all happen as a result of the grouping of things together as children. I’ve updated the ticket but I didn’t change the title as the intention is still for there to be the ability to add a separator, even if this is just a side effect of implementing children in UIMenu (e.g. what intended result is needed separated out from the implementation details).
That won’t works as probably anyone would expect, because you couldn’t access that particular menu item (separator), and also referring its contained childs by the regular indexing, for example.
In addition, that inlined group would add two separators: before AND after the group, and not just one separator…
Maybe I’m off, but I believe UIMenu will automatically render a separator between groups of children (I’m thinking about .displayInline). Yes, not being to access the separator as a menu item is actually fine and preferred. It simply needs to create a visual distinction.
I could be wrong, but I think the separator is just shown between menu elements so in the case of the iOS Calendar app screenshot from the ticket, being able to render things in this fashion, should be doable:
