I’m created a custom remote design and wanted to use the small buttons you get all the way at the bottom under all the bars and pads. I’m able to turn off all the pads but every time I turn off the top bar, Roomie crashes. If I turn off all the pads but one, I can turn off the top bar but if I then attempt to turn off the last pad, Roomie locks up.
We have indeed fixed that issue in the next release. The App Store is effectively closed for any new apps through the holidays so the next release will likely be in January sometime.
Meanwhile, there is technically a way to do what you’re talking about if you edit the underlying XML directly. RoomieRemotes.plist has a section for each remote that looks like this:
tbar
If you delete that section from the remote you want to modify and then sync your change back to Roomie via Dropbox, the Top Bar will be disabled.
Worked, thanks!
Tim
Just a quick note to help others who are crashing with Top Bar issues:
-
As of Jan 28, 2013 this problem is still happening in both directions: when you have a top bar and try to remove it (OP) or when you don’t have a top bar and want to add one (my issue)
-
on a Mac get a free / trial copy of Pref Setter to edit the XML in the .plist as indicated by the Roomie guys above
-
if you want a top bar and don’t have one, just add a new boolean key called tbar with the value of True to one of your remotes. It is not super easy to see how if you are new to XML, but if you’ve ever dealt with the Registry on a Windows computer, this won’t be hard, either. Expand the items to find their names, select the item that corresponds to the remote you want to change, add key named tbar, make it boolean value of true. Save.
-
After you add it, the crashing will stop and the top bar will be there
To the Roomie guys: a month is 10x as long as it takes my developers to get something through the approval process, so can you investigate / re-submit? I am sure there is other Roomie goodness in that release: WANT !!
Best,
TC
Actually the App Store process can easily take as long as two months (and did for Roomie 1.7.0 due to extensive additional approvals for hardware accessory support).
But in this case that’s not an issue. Version 1.8 is looking great and there are no pressing issues that need an urgent hotfix right now. We’d rather take the time to get more into it than rush it out at the moment.
So it is “fixed in the next release” but you aren’t yet ready to release it, and when you do release it, it could take as long as two months for Apple to release it?
Dare I tease: Agile much? 
(come on – laugh with me)
The additional delay was a one-time thing, for instance 1.7.1 went right through. When we’re ready to release 1.8, we don’t anticipate it will take that long.