UISegmentedControl width in SplitView - iphone

I have several UISegmentedControls in different view controllers. On the iPad, when the device changes orientation I realign the segments inside these so they line up with the UITableViews underneath. The problem I'm seeing is that although the resizing mask is set for the UISegmentedControl and without any of my code, it resizes to fill the right width, once I try to change the width of the segments within, the segmented will either not stretch all the way to the end, or they'll be too big and go over.
This only seems to happen when the controls are in a split view.
- (void)orientationChanged:(NSNotification *)notification {
[self setHeaderWidths];
}
-(void)setHeaderWidths{
int totalWidth = self.segSorter.bounds.size.width;
int areaWidth = 100,
priceWidth = 100;
int padding = 35;
[self.segSorter setWidth:totalWidth -padding- areaWidth-priceWidth forSegmentAtIndex:0];
[self.segSorter setWidth:areaWidth forSegmentAtIndex:1];
[self.segSorter setWidth:priceWidth forSegmentAtIndex:2];
}
Initially I thought it might be caused by the animation, but even adding a delay so the rotation animation has totally finished has no effect in the width. Are controls within a splitview given a false width or something?

One option you might consider is simply re-creating the control or removing then re-adding the segments.
Without knowing what's going on inside the control, as you change the widths, what if the first one you're resizing (say increasing width) would cause the sum of the widths to exceed the bounds? Without knowing how that logic is working inside, when I've run across things like this that seem like a fight for a simple change, it's easier to roll a method that just recreates the control as you need it (or removes and re-adds the elements) in the specified sizes.

Related

Changing frame of an NSView inside NSScrollView ends up with weird values

I'm running into a weird issue with my code and I hope someone else has better ideas on how to handle this.
**Summary of what I want to achieve: **
I have an editor that looks like this:
On the right side I have an inspector panel where I can manually change the frame of the currently selected view (which sits inside another NSView that's the document view of an NSScrollView).
**Summary of implementation: **
The main view inside the NSScrollView doesn't directly use autolayout, because I need to be able to set the frame manually, I leave the translatesAutoresizingMaskIntoConstraints property to true (default value) for all the subviews inside the NSScrollView. So I end up with constraints automatically created when I set the frame.
The problem:
When I set the frame, to let's say (1, 0, 100, 100) for some reason the autolayout engine will take in account the magnification value of the NSScrollView and will readjust the frame, so the final frame might end up looking like (1.74, 0, 100, 100). While I do understand this, the question is, can I disable this behavior? Is it possible to have frame value increments of 1.0 while making sure Autolayout doesn't screw the final frame regardless of the NSScrollView magnification value?
Thank you!
Autolayout views inside a magnified NSScrollView can give very strange values at times, and I haven't really figured out when and why.
I have approached a similar problem by adjusting the views' position manually according to magnification of superview, or by subclassing them and writing a method for them to take the magnification into account.
So, for example:
CGFloat factor = 1 / magnification;
element.frame = NSRectMake(x * factor, y * factor, ...);
Hope this helps.

UISlider minimumValueImageRectForBounds: and super maximumValueImageRectForBounds returns empty rectangle

I subclass UISlider in order to make the thumb smaller, and I want to override minimumValueImageRectForBounds and maximumValueImageRectForBounds to make their width 2px less. So my code is
- (CGRect)minimumValueImageRectForBounds:(CGRect)bounds
{
CGRect stdRect = [super minimumValueImageRectForBounds:bounds];
return CGRectMake(stdRect.origin.x + 2, stdRect.origin.y, stdRect.size.width - 2, stdRect.size.height);
}
The point is that stdRect is empty rectangle (0, 0, 0, 0).
Morover, if I explicitly set some rectangle like that
- (CGRect)minimumValueImageRectForBounds:(CGRect)bounds
{
return CGRectMake(2, 0, 40, 8);
}
It doesn't affect minimum value image position at all.
Any ideas?
Haha, I just figured it out. I wasn't reading closely enough.
Setting the minimumValueImage is not the same as calling setMinimumTrackImage:forState:. The minimumValueImage is an image that gets displayed to the left of the slider and is independent what's going on in the slider. Overriding minimumValueImageRectForBounds changes the dimensions of this image (the default size being 0pt wide) and the sliders frame is made less wide and shifted to the right as a result. As I understand it, there isn't a way to modify the rectangle of the minimumTrackImage (such as to make it extend to the right of the thumb image); it is only possible to change the image.
I haven't really figured out the point of allowing you to set the minimumValueImage. It seems like you could accomplish the same thing by changing the size of the slider and adding separate UIImageViews to the side of the slider. Who knows.
Note that everything I've said here applies in the same way for the maximumValueImage and setMaximumTrackImage:forState methods.
DO NOT DO THIS. This is an old, incorrect answer, by past me. I hate that guy.
--
As a general rule, you probably don't want to subclass the Apple standard UI controls. You might want to build it up and set those properties yourself instead (not sure if they are settable, but seems like they should be).

iphone: re-sizing gradient after shift from portrait to landscape

In viewDidLoad, I can create a gradient with no problem:
CAGradientLayer *blueGradient = [[CAGradientLayer layer] retain];
blueGradient.frame = CGRectMake(gradientStartX,gradientStartY,gradientWidth,gradientHeight);
where gradientWith is device-defined as 320 or 1024 as appropriate.
What I can’t do is resize it inside willRotateToInterfaceOrientation: -– and thus get rid of that empty black space off to the right -- after the user changes to landscape mode. (The nav bar and tab bar behave nicely.)
(1) Recalibrating the gradient’s new dimensions according to the new mid-point, (2) using kCALayerMaxXMargin, and (3) employing bounds all looked like they would do the job. bounds looked a litte more intuitive, so I tried that.
I don’t want to admit that I have made zero progress.
I will say that I’ve been reduced to the brute force method of trying every permutation of self, view, layer, bounds, blueGradient, and CGRect(gradientStartX,gradientStartY,newGradientWidth,newGradientHeight) with zero success.
This is not difficult. My lack of understanding is making it difficult. Anyone out there “Been there, done that”?
Does the layer resize its size automatically? If so, simple
[blueGradient setNeedsDisplay];
should do the trick.
Hope this was helpful,
Paul

UILabel inside custom UITableViewCell not drawing at the correct size

I have a custom table cell which contains a number of UILabels. At runtime, I am adjusting the height of the labels to fit their contents using sizeWithFont:constrainedToSize:lineBreakMode: and repositioning them accordingly. The last label in the cell contains a large amount of text, causing it to wrap, and I'm having a very odd problem. Although the sizeWithFont call returns the correct size, and I'm setting the UILabel's frame to that height, it draws a couple of lines short. This screenshot illustrates what I'm talking about:
In this example, the height of the full block of text should be 90 (as checked in Interface Builder), and that's what returns from sizeWithFont. It's also the height that the UILabel's frame is set to, which I have verified by logging and also by stopping execution and inspecting the value. However, as you can see, it's clearly not drawing the full 90 pixels high, although it's correctly allocating the space for it (the thin black line above 'Edited' is the table cell border). I'm completely perplexed. If anyone can offer some insight as to why it's behaving this way, I would be very grateful.
At last, a solution!
Turns out that the cell does layout twice -- once during heightForRowAtIndexPath, which is where I tweak all the heights of the subviews and the cell, and later during some untraceable transaction originating in __CFRunLoopDoObservers. How did I trace this? I added a layoutSubviews override to my custom table view cell class so I could breakpoint it.
During the second pass, the last UILabel subview was getting set to a shorter height than I set it to, probably in accordance with some arcane autoresizing rules. (Yes, I tried tweaking all of those settings first, with no success.) As it turns out, merely doing nothing in layoutSubviews disabled this framework behavior, allowing me to completely control how my views draw.
With iOS 8 it doesn't work anymore like this. Implementing layoutSubviews alone doesn't do the trick, because the layout of subviews have already changed when the method is called.
I have found 2 solutions:
adding NSLayoutConstraint to layout the subviews programmatically
implementing subview's layoutSubviews and change the frame
An example für solution 2:
- (void)layoutSubviews
{
[super layoutSubviews];
CGRect frame = self.frame;
frame.size.height = 39.f;
self.frame = frame;
}
I've fought with similar problems. It was to do with other properties being set in previous incarnations of the cell. To find it / prove it I changed the reuseidentifer for the offending cell to make sure it was a unique cell.

Clipping within an UIView with some subviews

I have some buttons in an UIView. My problem is, that they get cut
off at the right side of the UIView. How do I prevent this?
alt text http://img.skitch.com/20090629-mj32p1bkff476256pwrpt69n2d.png
I've checked already Interface Builders clip property, but it's no
solution for this problem.
Regards
It seems like either you made these buttons programmatically, or you reiszed the initial IB view window to be larger and expected it to shrink down to the fit the screen.
The buttons in question cannot fit on the screen as they are - what effect are you looking for?
If you want the buttons all to fit you could set the text size to be smaller, and then they could fit.
If you want the buttons the size they are then you'll have to make another row, or put the buttons into a side scrolling container.
I have been using java and only recently began learning Apple's Obj-C framework.
An alternative to scrolling and row-breaking is using a "grid" layout with 1 row and n columns, where n is the number of buttons. Each cell has a fixed size. And you will have to resize your buttons (the subviews) in your superview's setNeedsLayout: method to whatever width you need such that all buttons fit the row.
See java's GridLayout class.
Kendall, thanks for your answer.
Here is my solution:
if(previousFrame.origin.x + theStringSize.width > 220){
roundedButton.frame = CGRectMake(15, previousFrame.origin.y + 30 , theStringSize.width + 8, theStringSize.height);
[myContainer insertSubview:roundedButton belowSubview:[tagsContainer.subviews lastObject]];
}else {
roundedButton.frame = CGRectMake(previousFrame.origin.x + previousFrame.size.width + 5, previousFrame.origin.y, theStringSize.width + 5, theStringSize.height);
[myContainer insertSubview:roundedButton belowSubview:[tagsContainer.subviews lastObject]];
}
I calculate, how many pixel I've moved from the left side. At some threshold (in my case 220) I start a new line.