The question in title is probably pretty dumb, but i just can't find answer. I need to have invisible UITabBar (without TabBarController) which interacts with user exactly as visible do. If i set its HIDDEN property to YES it becomes disabled even if i leave UserInteractionEnabled checked. Also (since i'm already asking a question) i would like to know what OPAQUE property do. I switch it but nothing seems to be changed and Apple's documentation is not quite understandable for me personally
Another approach to have an invisible UITabBar could be to have invisible UIButtons (use the custom type), and use them for your behaviour.
you can set the alpha value of your tabbar to 0 it will be transparent.
Related
I have been searching thru the web but cant find a confirmed answer.
There are ways like removing the subview within the searchbar.subviews but is that allowed?
If not then, aside from changing the tintColor of SearchBar, or use a textfield instead,
is there a way that wont break apple's rule and still being able to customize the background of searchBar?
Thanks!
You are not breaking apple's rules if you are not conflicting with private API's.
I worked on a shipping app that made the background of the search bar transparent. There were no problems with this.
A solution I've seen used a lot (albeit only on toolbars and navigation bars, so I'm not 100% sure it'll work the same way): subclass UISearchBar and override its -drawRect:, drawing your own background image within the view's bounds.
I have an application with multiple views that contain subviews. I know that you can hide or make visible a view and its subviews by setting the hidden property to YES or NO. However with a number of views, to use the hidden property requires keeping track of what view is being displayed. I thought I could use sendSuBViewToBack: to hide a view and moveSubViewToFront to make it visible. However, these methods appear to only act on the specific subview and not its child subviews. For example, a view with a couple of labels on it, when sent to the back, the labels remain visible.
Is there any way to make this behavior work besides using the hidden property?
Thanks,
Jim
UIViewController seems like what you're looking for. Or rather, what you should be looking for.
I'm not quite sure what exactly you're having trouble with here. As long as you're keeping track of each "container" view (perhaps using a #property), you should be able to show/hide them on demand using a method in your code (which can be as simple as hiding all container views, and then showing the one you desire).
I'm building an iPhone application and like most I am trying to implement a UIScrollView with a UIPageControl, however I am coming across a very quirky behavior, which I assume may be a bug. Hopefully one of you has seen this before because it is driving me nuts.
Basically, the page control works fine, everything is hooked up and works normally on all accounts EXCEPT, with certain placements of the UIPageControl within the UIView, the UIPageControl will cease to render.
I'll just take screenshots of the XIB window to help illustrate... here's a placement that works perfectly fine:
http://www.jasconi.us/prob1.png
The UIPageControl is placed physically above the UIScrollView. Works great, everything is visible and working.
The next two DO NOT work:
http://www.jasconi.us/prob2.png
http://www.jasconi.us/prob3.png
The first one is simply placed below the scroll view. Doesn't render at all.
The second one is placed above the scroll view without technically being inside of it. Also doesn't render.
What the hell is up with this? I've tried using
[[self view] bringSubviewToFront:pageControl];
...to no avail.
Any ideas?
OK I found the answer to this, it's a little six degrees of Kevin Bacon.
This isn't actually a software bug, but a XIB quirk, for some reason the lower placement of the page control in combination with the default settings for autosize and anchor seem to jettison the control into outer space.
If you turn off all auto-scaling and auto-sizing and auto-anchoring and all that other crap, the controls appear exactly as you expected. The fact that it appears reliably when placed above the ScrollView is an oddity.
shrug.
Hope this helps future iPhone initiates.
Did you check to make sure that numberOfPages is not 0?
If you set a breakpoint can you see that pageControl is not nil?
I was still encountering this exact same problem, even after trying everyone's posted answers. My issue ended up being a little more "DOH":
I was using UIPageControl at the bottom of a modal FormSheet, however, I forgot to set the size of the view as Form Sheet in the xib. This caused my page control to be off the screen and never visible.
Moral: set view size (Full, Form, Page, etc) in your xib on the base view.
This will sound like a real no brainer, but I got caught out by it.
By default, UIPageControl expects to be on a dark background. IE: The dots are light gray, and white for the current page.
I used UIPageControl on it's own with no scrollview to change the time range of a graph I was rendering with drawRect:
Long story short, the graph background was white, so the page controller worked, I just couldn't see it. The solution was putting the graph itself in a subview, and making the parent that contained the page control have a dark background.
I have a UITextView that I'm trying to keep hidden from the user, except I'm using it's autocorrect interface so I can't just put it's hidden property to true.
Currently I am putting the contentOffset such that it hides the first line of text, however this does not consistently work. Sometimes it does, other times the scroll view re scrolls to where the text is partially visible. It seems arbitrary which it does, as without changing a line of code, the behavior will switch by itself after I rebuild...
I have tried turning off scrolling for the UITextView, as well as overriding the UITextView's drawRect function to not do anything, as well as changing the TextColor of the UITextView to clear color. It seems that you cannot change the alpha values of text colors so that did not work.
Any other ideas on how to achieve this?
Thanks in advance.
Perhaps the UIScrollView is trying to be smart about where it is automatically scrolled to, even though you have disabled user scrolling?
You could try manipulating the contentOffset, and see if controlling that value stops the unwanted scrolling.
Another idea to help debug any unwanted scrolling activity is to add debug NSLog statements into a few of the key methods of UIScrollViewDelegate, such as scrollViewDidScroll: or scrollViewShouldScrollToTop:. If the contentOffset approach fails, this might help you understand what is going wrong, and possibly prevent it at the delegate level.
By the way, it sounds like what you're doing in general is kind of hacky. You might end up with more to-the-point answers (and cleaner code) by just asking about your true goal - maybe having your own version of spell checking?
Is it possible?
I have a UINavigationBar that I'd like to have an 'edit' button next to the 'back' button. From what I've read you can only have one or the other, which makes no sense as they are separate properties of the navigationItem object(backBarButtonItem and leftBarButtonItem).
I'm assuming you have to somehow insert a custom UIView into the UINavigationBar. I'm looking into this option and if no better solution is given then I'll outline this method.
The short answer is:
Yes, you have to add your own UIButton views (or other UIControl subclasses) to the navigation controller, yourself. So, ignore the custom *ButtonItem properties and roll it yourself.
A little more involved answer is:
Apple makes it very easy to follow their HIG guidelines, but you're on your own if you want to break them or customize. In this case, only one button is allowed, because the actual hit region is bigger than the size of the displayed button--much easier to hit from a usability standpoint.
Extraneous:
btw, there is a subtle distinction between left/rightBarButtonItem and backBarButtonItem. left/right is specified on the current UIViewController. However back is specified by the previous UIViewController.
Using a custom view is indeed your only option here. The UINavigationBar is not terribly flexible. What you will need to do is create a UIView that contains UIButtons. Be sure you realize that if you use a custom view, you gain none of the automatic behaviors of the backBarButtonItem; you have to create your own IBActions, and the graphics for the buttons as well.
On a related note, I'm not sure this is the best idea. It's usually wise to stick to Apple's UI guidelines; is there no where else you can put the edit button? The right side of the bar, for example?
While #Kelvin's answer works for pre iOS 5, if you're using iOS 5+ there is now a leftBarButtonItems array property. Note that you also must set leftItemsSupplementBackButton to true.