I'm experiencing what I think is a very strange issue.
First and foremost, my application moves UI elements around the screen using the following example command:
[view setFrame:NSRectFromCGRect(CGRectMake(0, 0, 0, 0))];
I give my users the possibility to resize the application's NSWindow to one other size with this command:
[self.window setFrame:NSRectFromCGRect(CGRectMake(0, 0, 0, 0)) display:YES animate:YES];
When in 'resized mode', I obviously change every single setFrame command to the appropriate coordinate system.
However, there is an issue: when (if) the user switches back to the original NSWindow size by clicking on the button again, and the application performs the UI movements again, the views that are moved around are not in the location they are supposed to be in.
To clarify: my UI movement code runs fine, over and over, either in normal or resized mode. However, if I switch from one to the other, some items (not all) are shifted.
What could be causing this strange behavior? I'm using the same exact commands (within each screen resolution), and NSLogs confirm the UI elements are in the location that I specified; however, this location is clearly not the one I'm attempting to move to.
Has anyone experienced a similar issue here?
You've probably set some sort of autoresizing mask in Interface Builder that's interfering with your manual placements. Go in to your nib and remove all the springs and struts in the Size inspector. Although if possible you should let autosizing handle the placement, or move to Auto Layout which was introduced in 10.7.
After days and days of trying to figure this out, I've come to the following conclusion: the resizing code simply wasn't working.
I confirmed this by using NSLog after I resized my window. In the end, I changed my resizing code by adding the following line after the traditional setFrame: method:
[self.window setContentSize:NSSizeFromCGSize(CGSizeMake(desiredWidth, desiredHeight))];
Related
I noticed the other day that one of my web pages was looking ugly. The buttons on the page looked totally different, based on whether they contained one line of text or two.
After some digging, I've learned that the typical button uses NSRoundedBezelStyle, but it has a fixed height. So, if the text is going to wrap, Firefox (and Chrome and Safari) will change the button to use NSShadowlessSquareBezelStyle which can have a variable height. I'd like to petition the maintainers of these browsers to change this and am researching the best alternative.
After finding the already-filed bug and doing some reading, I suggested that maybe they could use NSTexturedSquareBezelStyle instead. It turns out that in Mavericks it looks almost exactly the same as an NSRoundedBezelStyle button. Same in Yosemite, except that it has no border. Changing setBordered has no effect.
So my question, on behalf of browser developers everywhere: is it possible to draw an NSTexturedSquareBezelStyle button with a border? Or, is there another way around this that all the browser vendors have missed?
Rewritten Answer
I'm not seeing an NSTexturedSquareBezelStyle button showing up borderless in Yosemite:
This is a stock button dragged from the palette in Interface Builder. I encourage you to post your code since it's likely you're generating your button in code. Here's my own code for generating the same button:
NSButton * anotherButton = [[NSButton alloc] initWithFrame:NSMakeRect(10.0, 10.0, 100.0, 100.0)];
anotherButton.bezelStyle = NSTexturedSquareBezelStyle;
anotherButton.title = #"Line 1\nLine 2";
Proof:
If you're seeing different results under Yosemite, you'll need to post your code. At a guess, you might be initializing your button with -init instead of -initWithFrame:, which can cause all kinds of drawing issues since NSButton is an NSView and therefore its designated initializer is -initWithFrame:. Just a guess though.
I am developing a iOS-6 app. I have a UIViewController with a view that needs fixed orientation (portrait mode). But when the phone is rotated, one control on that view needs to be moved and rotated (so that it will always be in the upper left corner, and its text will be readable).
I am achieving this by shifting the control(a UIView) using the frame-property of my control (it is a custom view, more on that later), and then using CGAffineTRansformMakeRotate() afterwards, since I know that it's not advisable to use the frame after rotating a view. Everything is fine so far, but here's the thing: That custom view has three UIButtons of type UIButtonTypeCustom as its subviews. Because I rotated the View, but cannot rotate the buttons inside the view (they are not squares), I need to rotate the titleLabels of the Buttons for the text to be readable in the new deviceOrientation.
But it won't work very well. The text will be rotated, as I intended, but it will be clipped by the titleLabel, because the titleLabel has the wrong frame. I checked this by applying borders to the label. So I need to change the titleLabels frame, right? But how can I do that? I tried setting it using [titleLabel setFrame: frameThatFits];, but to no avail. (frameThatFits is a CGRect I created). Also, calling [button.titleLabel sizeToFit]; has no effect that I could see.
I am using [button setTitle:title forControlState: UIControlStateNormal];to set the title.
TL;DR: I'm trying to change the frame/bounds of a UIButtons titleLabel after rotating it using an affine transformation. Any help?
Thanks.
PS: I can supply code when needed, but I wouldn't know what to show you. Tell me what you need, I'll post it.
OK, first of all, thanks to everyone who tried to help. Im posting an alternative solution for my problem, and although it doesnt really address the problem of changing the titleLabels dimensions, it will result in the proper display of my ViewController.
It turns out using the frame is a bad idea. I initially used the frame to reposition the view and i figured that this couldnt be a problem because i only ever applied transformations afterwards, but i was wrong. Because OBVIOUSLY i tried to change the titleLabels frame. AFTER the rotation. And that didnt work.
So the way to go here is using the center-property and the bouds of the view consistently throughout the code. It will result in properly rotated Buttons, that do not need any fidgeting afterwards.
My takeaway here is that i will never ever again use the frame-property outside of a NSLog-statement. But why [button sizeToFit];wouldnt yield any results is still beyond me. If i ever figure it out, i might post it if i remember.
EDIT:
#ZevEisenberg nailed it with this comment:
“Warning: If the transform property is not the identity transform, the value of this property is undefined and therefore should be ignored.” So you are right to use the center and bounds here, but if you do not have a transform, the frame is perfectly safe to use.
NEXT EDIT:
Heres how i ended up repositioning the Buttons:
-(CGPoint)centerForView:(UIView *)view{
//calculate a suitableposition for the view
//depending on the current orientation and the device type (iphone 4S/5, etc)
return point;
}
Then, as a reaction to the deviceOrientation change notification, i apply CGAffineTransformIdentity to all the views, reposition them using my centerForView shown above, and apply the correct rotation transformation to the View. I do this for all the subviews every time the divice rotates, like so:
-(void)setRightRotationTransformations{
[self resetAllTransformations];
self.someSubview.transform = CGAffineTransformRotate(self.someSubview.transform, -M_PI_2);
}
In my case works such hack:
set Line Break mode to Word Wrap
Add extra line to title (even for one line title)
I'v encountered strange bug, and have no idea why this happens.
I have UIScrollView, in it I have 12 views. Most of them contain UISwitch button and a label. Size of views are dynamic (depending on the lenght of label.text). Everything works and shows, except two views on the bottom. They do get shown, initialize as expected. Yet UISwitches in them do not work, clicking or touching them does not do anything. Both of them are no exception to others (all of them are copy paste). I have double checked IBOutlets, they are fine. I have suspicion something is wrong with scrollView. Maybe beyond some point it doesn't recieve inputs anymore? Eventhough I can scroll up and down and everything is shown just as expected.
Any ideas what to check ?
I have switched these two views with first ones. And more bottom views get unresponsive, like there is a line, beyond which ui is not responsive. Ideas?
You say the switch is in a view (one of 12) and that view is on the scroll view,
maybe the UISwitch is out of the view bounds? Try to set that views .clipsToBounds = YES;, can you still see the switch? If no, it means the switch is out of bounds therefor you gat no touch events. Make that view larger to fix that.
Check correctly. if the UISwitch and UIscrollview user interaction are enabled.
Check whether the UISwitch is added within the UIscrollview's frame.
I have a custom-subclassed NSWindow which is made into a fullscreen borderless window with NSBordelessWindowMask. It works perfectly, and as far as I can see, there are no problems or anything strange about the window itself.
What I am trying to figure out why exactly a custom-subclassed NSView within the aforementioned window is respoding to setFrame: requests in an odd manner. Rather than simply taking the requests as they are, it seems they are going through some sort of change - for example, setting the x coordinate to 25 and the width to 800 does not put the right edge of the view at 825 as one would expect. Instead, the width/height grow along with the x and y coordinates, even though they report the proper numbers when asked by [view frame].size.width with an NSLog.
The sizing masks should not be an issue, as I have disabled them entirely and get the same result with several different configurations.
Has anybody else experienced this type of behavior?
Without seeing the code that you're using to create the window/view it's hard to know what might be causing this. That said, if you're targeting Leopard of later, there's a built in way to make a view go fullscreen which might help. The method is enterFullScreenMode:withOptions: on NSView. If you want the entire window to go fullscreen you can call this on the contentView of the the window. This may not fix your bug, but it should simplify things a bit at least.
I've created an application for Mac that uses a horizontal resize view (technically a BWToolkit resize view) that is linked to a toggleCollapse button. After collapsing and expanding the panel a few times, this happens (see image) right table-view should be flush with panel divider. Any one have any info on why this is happening. I've carefully adjusted my alignment and anchors to be correct but it seems like this is a weird issue that bugs out the view?
EDIT: Is anyone NOT having this issue? Any input would be helpful! Maybe I just need to start fresh?
This is a known bug in BWSplitView itself, and is related to how view animation and timers interact in that view. The details are covered here:
http://bwalkin.lighthouseapp.com/projects/36323/tickets/34-split-view-doesnt-resize-subview-properly-during-a-toggle-uncollapse-after-manual-collapse
Basically, before the view is animated, autoresizesSubviews is unset, so that the view can be collapsed/expanded without affecting the contents; a timer is then scheduled to restore the autoresizesSubviews property for when the animation has completed. But (of course) the animation may sometimes finish ever so slightly earlier, or later, than the scheduled timer fires; so autoresizing is switched on before the animation has completed, resulting in a few pixels resize. As you've probably seen, the subviews tend to move around a bit as the view is collapsed and uncollapsed.
The "full" fix for this would be to restore autoresizing when the CAAnimation has completed using a callback, but this hasn't been implemented yet. However, in that thread "Robert Payne" has posted a version of BWSplitView.m which uses a slightly different approach - the view sizes are recorded before collapsing, and restored after expanding. I applied this patch myself (I think it won't compile at first - but it's a simple matter of an undeclared variable?) and can confirm it does fix the problem.
Let me know if you'd like a BWSplitView.m which compiles successfully, or a copy of the compiled framework.