I'm experiencing a bad looking graphical glitch with UIDatePicker, and I'm wondering if anyone else has seen and/or resolved it. It is something non-deterministic, because every once in a while it goes away and looks normal.
Check out the highlight and shadow bars are shifted...
alt text http://img.skitch.com/20091218-x45e3i7bxw2ir4euymwxdrifhb.jpg
I have tried removing all other graphical elements. I have tried removing my slide-up animation so that it just appears in place (I thought there might be a break in animating the sub-views). At this point, I'm out of ideas for isolating this thing.
Thoughts? Thanks guys.
It looks like the picker view has been resized which they shouldn't be (as shown in IB by their frame properties being greyed out). I'd imagine this is the cause of the problems.
Wow, so yeah, big "f you" from Apple to all the devs who don't use their crap Interface Builder. Turns out Daniel was correct and there is indeed a resizing bug with UIDatePicker. No mention of this in the documentation.
I would have left this as a comment to his answer, but I wanted to elaborate on the solution.
You can set the frame origins to anything, but the size MUST be 320.0, 216.0 or else you will have non-deterministic graphical glitches.
I would also like to link to this spot-on blog post about some strange date issues with the UIDatePicker control. The NSDate class was basically a huge screw up from a localization standpoint, and they've attempted to deprecate the issues, creating an even worse disaster in the process.
Related
I have a very basic application that has two buttons that are supposed to retrieve properties and display them on a label. The classes are simple, basically containing properties.
The thing that I am running into is that everytime I hit the play button, it showcases a screen that is all white/blank.
So far, I am assuming this is due to a goof up in the UI because as far as the classes are concerned, I am quite confident that they work i.e they do not report any errors.
This question is vague but if you guys have experienced a similar issue maybe you know what it is.
So I'll leave this question at this without inching into more description that is highly likely to be irrelevant.
Any leads people?
When I was getting started with iOS stuff, I found a good way to debug weird UIView behaviour was to set the backgroundColor property of each view to a different colour, eg:
[myView setBackgroundColor:[UIColor redColor]];
That way I could tell at least vaguely what was going on.
I have iOS 4.3 installed on my iPad. I'm noticing that my text in my UILabels is not resizing. In other words, I'm adding letters, but it's just truncating. Same settings work find on iPhone also running 4.3. I'm perplexed. I've made certain that "Adjust to fit" is checked on the label properties. I've even set it in the code with .adjustsFontSizeToFitWidth and even tried calling sizeToFit.
None of these let the text resize.
Does anyone else have this problem?
Any ideas?
My next solution is going to use this: Check if label is truncated to try and manually resize the label text.
I finally figured it out. I'm using OHAttributedLabel. I had intended to do some things with color in my labels and have not yet gotten around to it. It finally dawned on me that was the only difference from previous iPad versions and from the iPhone version (I never even thought to look at the class). Turns out this OHAttributedLabel class does not support resizing yet.
Sorry for wasting everyones time. Maybe someone else will someday find this useful.
Try using CGSize eLabelSize = [yourLabel.text sizeWithFont:yourLabel.font]; to get the size of the label and then you can simply modify the yourLabel.frame.size property with eLabelSize.
This worked for me in case of iPhone.
Hope this works for you if yes do communicate..... :)
Maybe it only appears as if the label is truncating text because the label frame runs out of the bounds of its parent view, which clips to its bounds? Verify the frame of the label and the autoresizing mask.
Also, the minimumFontSize property is set low enough?
Is there a right/wrong approach for creating a Custom view using code or IB? I mean what should be the preferred way of designing a custom view.
As for all broad questions, the answer is "It depends what you're trying to do". Both IB and writing code have their merits. Some projects will end up with a bit of both.
There's some discussion here:
http://wiresareobsolete.com/wordpress/2010/03/striking-the-balance-interface-builder-vs-code/
Personally, I started out working with IB. But as I went deeper into iOS development, I started building my views in code....
Gave me a higher sense of control over my view objects.
But, like everyone else says, both ways are correct; It just depends on what you're comfortable with.
Like me, try both and see which one works best for you. You have nothing to lose either way.
I used to do it in code but now I mostly use IB to lay out my views and then do fine tuning in code, like setting the font for a UITextView. Always seems odd that you can't do that one in IB...
I'm trying to workaround a long-running bug in Apple's SDK here, but I can't see how to achieve it without huge amounts of code.
Here's the bug:
Create a view.
Put another view inside it, with an origin ANYTHING except (0,0).
Configure the subview to resize to fill
...then, at runtime:
4. Set the superview size to zero
5. Set the superview back to ANY non-zero size
BANG! Apple's SDK goes haywire, resets the origin of the subviews, loses all ability to tell up from down, etc. (seems like the programmer "Forgot" to include a variable to record what the spring/strut-size was before it went to 0).
I've heard this bug has existed in OS X for 5 years or so, and Apple still hasn't fixed it. What I would like is some way (any way!) of working around it, without re-writing Apple's entire springs/struts system and implementing it properly, without the bug. Unfortunately, I can't even find the original references to the OS X bug that someone showed me previously.
EDIT:
...I have a resizing "drawer" at the bottom of the screen that has to shrink to small height. The problem is subviews "collapsing" all down to origin 0 (amongst other things) at the drop of a hat (technically: they're reducing their origin.height, but not re-increasing it).
The best solution I have found is to limit your minimum window size so that none of your views can ever hit zero size.
EDIT: an hour later, the collapsing behaviour has returned, without me touching the source files. I'll use source-control to double-check, but I believe all that happened is I added other files to a different part of the view-hierarchy and re-built. Argh!
(what follows SEEMED to work, but is now failing again, in the same way)
Hmm. So, I had two UIVC's on one screen. Refactoring so that I only had one made the resizing bug vanish. It seems to be a bug in the UIVC layout code.
NB: I had the idea this might be a problem because I know Apple currently advises you to only have one UIVC on screen at once with iPhone, even though this means you have to ignore their MVC architecture for complex apps. So, technically, they warn you away from this. But, at the same time, I'm now unable to use the MVC stuff for this code.
The following worked (for my current example - may not be universal!).
HOW:
If you're adding any UITableViewController instances ... give up. You'll have to re-implement that class yourself
Find my subviews that were in UIVC instances, and change the extended class in the UIVC header from "UIViewController" to "NSObject"
Move all code from viewDidLoad to init (remembering that "init" has special rules about first few lines etc)
Replace the instantiation of that UIVC from "[[vc alloc] initWithNibName:nil bundle:nil]" with a plain "[[vc alloc] init]"
Another potential workaround (that works in my current situation):
The only View I have right now that MUST have a non-zero origin and MUST resize-to-fit is a UITableView.
Apple has a special feature of letting you put any view as a "table-header".
So ... I've taken all my other components, stuck them in a large view, and made that the table-header view.
The downside is that they now scroll off the top when you scroll the table, but it allows me to give the table a zero-origin, working around the SDK bug.
I'd like to draw attention temporarily (±1 sec) to a value in a UILabel when a user changes something elsewhere on the screen. I know Apple is pretty particular about what and how people add "pizazz" to their apps...and for the most part I think it's for good reasons but in my case I feel my UI would really benefit from a subtle animated effect of some kind.
So I'm asking the UI police if there is an acceptable way to bring "tasteful" attention to a UILabel?
Currently I'm animating a color change to a lighter shade and back again but it's not quite "strong" enough.
Maybe some kind of a glow effect? (prolly a huge HIG no-no if there is even framework support for it?!?)
Edit - Example:
There's a good example of what I'm thinking might work that is right in front of our eyes. When you type the the 2nd half of a paren or "]" or "}" in XCode other, corresponding half "(", "[" or "{", is briefly highlighted. How is that accomplished? Is that just a simple view behind the character that fades in and out?
What you are describing probably won't be a problem with Apple. The main thing they seem to dislike is when you take an Apple standard usage and use it to mean something different.
So for example, if you added a symbol like the little x-circle that you find inside UITextField boxes, and used it in a UITableViewCell to mean "Search" -- Apple won't like that.
Good idea. Well, you could use an image with alpha that fakes the glow. Just fade it in and out quickly.
My english is not so good, but are you concerned about apple rejecting your application just because of an animated lable? don't worry.
Animated color change is probably the best you're gonna get if there's no built in UI support for it. Apple won't reject your app for this, but it will bother some purists.
You could consider some of the more traditional messaging frameworks to draw attention to the concept you want to highlight for the user.
In my apps TafelTrainer and TafelTrainer+ i blinked the UILabel for a short time, and they both came in without problems.