Currently you can highlight or select a button. In some cases for navigation purposes it would be nice to deselect all tabbar buttons. Maybe something like:
tabBar:setSelected()
tabBar:setSelected( 0 )
I spoke with the Engineers. At least on iOS, one button is required to be pressed as it’s the current screen you are on. You always have to have a view showing and there is one button per view, therefore you need to have a button pressed for the current view.
I spoke with the Engineers. At least on iOS, one button is required to be pressed as it’s the current screen you are on. You always have to have a view showing and there is one button per view, therefore you need to have a button pressed for the current view.
This doesnt make much sense to me. I have views that are not listed on the tabBar. Eg. I use the tabBar to list the 5 main screens of the app, however, there other screens as well. If you check Instagram for instance, it has a tabbar, but if you enter the “explore” tabview, and then on “search” you end up on a new screen… to go back to “explore”, you need to click on its button on the tabbar again.
Corona’s tabbar does not allow “tabBar:setSelected( 0 )” and does not allow clicks on the tabbutton that is currently selected, and it’s frustrating if you have sub-screens (in these cases we have to create tabbars from scratch).
This was possible with widgets v1. The capability disappeared with widgets v2 release and was requested by many forum members to be brought back. I don’t recall what the CL response was.
This doesnt make much sense to me. I have views that are not listed on the tabBar. Eg. I use the tabBar to list the 5 main screens of the app, however, there other screens as well. If you check Instagram for instance, it has a tabbar, but if you enter the “explore” tabview, and then on “search” you end up on a new screen… to go back to “explore”, you need to click on its button on the tabbar again.
Corona’s tabbar does not allow “tabBar:setSelected( 0 )” and does not allow clicks on the tabbutton that is currently selected, and it’s frustrating if you have sub-screens (in these cases we have to create tabbars from scratch).
This was possible with widgets v1. The capability disappeared with widgets v2 release and was requested by many forum members to be brought back. I don’t recall what the CL response was.
Is there any solution to this yet?
I put a “dummy” button on my tab bar with no onpress handling because I am using other buttons to display screens. iOS needs to be more application pliant.
Is there any solution to this yet?
I put a “dummy” button on my tab bar with no onpress handling because I am using other buttons to display screens. iOS needs to be more application pliant.
Is there even a way to unselect a button? When I use setSelected (with or without onPress flag), at least in the simulator the previously selected tab remains selected.
Hi @henrik5,
Another user recently reported that :setSelected() wasn’t working, but it was a scope issue in his code and he resolved it. I also recently tested this, and setting one tab via that function de-selected all of the other tabs, just as expected. Please check your code again to make sure you’re referencing everything properly and that there’s not a scope issue or unknown reference.
Thanks,
Brent
Just as a reminder, the idea behind a tabBar controller is that each button represents one scene in the application. There always has to be a scene on the screen and therefore there always has to be a button selected. What scene shows when none is selected?
This is an example of where we can’t build these widgets to do every possible thing you want them to do. This is one reason why we made the widget library open source. You can download them and build in your functionality that’s beyond what our widgets currently do.
The ability to click a tab that is already selected would be good feature to bring back. This was a widgets 1.0 feature which was dropped for no reason and with no warning.
What you consider a feature, when I look at it, I see a bug that was fixed… Now I think the move to Widgets 2.0 predates me joining the team, or at least I wasn’t privy to the design decisions, but to me, having all buttons deselected is a bug just as much as having multiple buttons selected would be. One button - one view. What shows when everything is deselected?
Now of course there is the utility that you might want to use it as some time of menu, but if so, that’s not what the tabBar is designed to emulate. Its designed to behave like a tabBar controller. As I said above, if you want to used the widgets outside of what they are designed for then that’s a good reason to use the open source files and build your own custom widget.
Rob,
I agree with you in one tab selected at a time.
On the point of having the same tab button being tappable again, we had this very same discussion back when the feature (not bug) was taken away. Try the following if you have a minute :
Start the Music App in your iPhone
Hit Playlists tab which will bring a list of your playlists.
Tap any playlist in the list - this will bring a list of songs in that playlist.
Now hit the playlist tab bar button again - you will see that the original list of playlists will be returned.
In other words, it is an IOS feature that tab bar buttons can be tapped again while they are in selected state. We had this capability in widgets 1.0 and somehow it never made it into widgets 2.0 and trust me it was not because the original behaviour was a bug. If that was considered to be a bug then IOS 7 and 8 still have the same bug in them.
Hope this presents a valid case as to why this ‘feature’ should come back. Thanks & best regards.
One person’s “feature” is another’s “bug”, and this feature from the 1.0 library (now about 3 years old) will not be prioritized, simply because you have several options which would solve this easily. These include:
-
newSegmentedControl works like you need: one segment at a time is selected, but the selected one can still be tapped (and trigger an event).
-
newSwitch() of “radio” type could probably do something similar.
-
basic display objects and listeners could be set up to accomplish this in about 15 minutes.
I urge you to choose and implement one of these options.
Brent
Hi Brent, I agree you can do similar things with various methods but we are all using the tabBar widget which is designed to emulate its IOS counterpart. Why take away something that existed in the first place and then try to get away with it calling the feature a bug that was fixed. This almost makes it sound as though we should be thankful for this bug fix. Maybe one of these days Apple will fix that bug in IOS as well… 
Anyways, long time past and lots of water under the bridge. I know that feature will never be back. No problems as long as we all know what happened here and call it what it is…
Also, the tabBar has a metal shine and strange dark cyan-blue tint on Android, which is completely different from the iOS 7 one, and also from the older ones for iOS and Android both 
Yes, I considered scope and made all objects and functions global to try. Still no go. It’s created as the last lines of code in main.lua, outside any functions.
Both these things told me I should roll my own and so that’s what I did yesterday.