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.
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'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'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))];
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.
I have an NSScrollView with an IKImageView inside to display images. This seems to work.
However, if I make the window smaller than the image, the scrollbars appear as they should, but the BOTTOM of the image is locked to the bottom of the window, instead of the top of the image being locked to the top of the window. In other words, I want the image to not move on the screen when I re-size the window from the bottom right.
I understand why this is, because in All of these classes, the origin is in the lower left, not the upper left. However, It's still behaving wrong. If you look at any other product (including Preview, which I assume is written with some of these libraries) the image/content/whatever, is locked to the top not the bottom.
How do I do this?
I've looked for methods in the NSScrollView and IKImageView. I've considered capturing the scroller events and manually moving the image down or up as appropriate, but I haven't seen a way to do this (Set the selector to a method I write in the controller?) and anyway, that seems very messy...
Is there an easy way to do this?
thanks.
Solution for future reference:
Make a subclass of IKImageView with only one over-ridden method:
-isFlipped()
{
return YES;
}
This subclass will also prove useful if I find that I need to re-implement the rotate:(id) method and the setImage:(NSImage) method which exist in the class (and in the case of rotate are USED IN THE DEMO supplied by Apple) but not documented, and therefore not officially supported...