The real question you have to ask yourself is why do I want the scope bar to always be visible? The way it works now, the scope bar will animate visible when the user taps into the search field and hide itself when the search field no longer has the focus. What’s the point of showing a search option when search isn’t even active?
For forum readers who do not have prerelease credentials, the example project Tom is referring to is available in Xojo 2020 Release 2.1/Example Projects/iOS/Declares/iOSMobileTable Search Filters.xojo_binary_project
Just out of curiosity, in which event are you calling the declares?
I’m using this declare after instantiating the view but before calling MobileScreen.PushTo() to show it.
I don’t know if it is possible to force the scope bar to be displayed at all times. But it might not be a good idea.
A fair point in most cases, but in my use case I want to have the scope bar shown immediately because “search is active by default”, to answer that quote: the app defaults to showing a more helpful subset of records when a list view is shown (rather than the full database) and I think that the scope bar clearly shows that’s what happening and how to change it.
Hey everyone, I’m resurrecting this topic because I still haven’t worked out how to make the “iOSMobileTable Search Filters” example project display the search controls nicely without user interaction.
Currently, it launches with the search control partially shown and the scope bar not visible. For my use case, I would like to have to have the scope bar visible because my app defaults its list views to a subset of records.
Thanks for looking into this, Jeremie! The separate UISegmentedControl approach sounds similar to what I used with the previous Xojo iOS API, but I’d hoped that Xojo providing that “iOSMobileTable Search Filters” meant that this would be an officially supported way of adding a scope control to the handy new iOSMobileTable.AllowSearch option.
Are there any ways of setting the height of the iOSMobileTable search controller?
Thanks for the reply, Greg! It’s hard to know without know what the underlying controls are in apps: my previous version built with the old Xojo iOS API looked similar but used the UISearchBar control from iOSKit.
My preferred option would be to have the scope bar visible so that the user can see which filter has been applied, but a fallback option would be for the search controls to be entirely hidden when the view is shown: that would probably be better than the intermediate state we see at the moment, which looks like a bug.