I'm using a view based NSTableView which displays a NSTableRowView containing an NSImageView and some NSTextFields. The NSTextFields are having the backgroundColor property set and are drawing correctly. I've tried to draw them with rounded corners by setting
[textfield.layer setWantsLayer: YES];
[textfield.layer setCornerRadius: 5.];
What is working but causes the views with the applied corner radius to flicker while scrolling the table view. Setting the view's layer via textfield.layer [setLayer: [CALayer layer]] or forcing the layer to rasterize by setting [textfield.layer setShouldRasterize: YES] also did not work. Any suggestions how to get rid of the nasty flickering?
I'm developing on Mavericks for Mavericks using Xcode 5.
With the help of uchuugaka's post I was able to fix it using this tutorial: Tutorial
Related
Anyone having problems with your Custom NSView's inside a NSScrollView? I have a NSScrollView with a custom NSView that uses its draw(rect:) function to do all the work.
Before OSX 10.14, each time scrollview was marked with setNeedsDisplay, the documentView would also refresh. On OSX 10.14 I need to specifically mark the doucmentView to setNeedsDisplay too. Looks like its ignoring the NSScrollView.contentView.copiesOnScroll property.
Does anyone have similar issues or point me to release notes? the NSAppKit release notes don't say anything about NSScrollView.
We encountered the same problem. After several days of experimenting, the cause for the problem in our setup was as follows:
The documents we need to draw can be quite large. Therefore we optimised drawing in NSView's drawRect method to paint the visible portions of the document only, according to the clip-rectangle:
NSRect clipRect = [nsClipView bounds];
This worked great before Mojave.
Under Mojave our code would display black for the portions of the document that scrolled into the visible region.
We changed our drawing routines to display exactly the areas indicated by the 'dirty rectangle' of the drawRect method:
- (void)drawRect:(NSRect)dirtyRect
Now scrolling works under Mojave.
I've got a custom NSTableHeaderView of custom NSTableHeaderCell objects that draw a custom header. The problem I'm having is that when the NSScroller bars show up, the header drawn above the scroller is the default, not my custom drawing.
Turns out the view that controls this section (over the scroller, right side of header) is called cornerView and the NSTableView has a -setCornerView:(NSView *)view method to set it. I fixed my problem by subclassing NSView and using custom drawing to draw a corner image into the view, then setting that subclass using the previously mentioned method.
Mac Mojave Left Corner View
Recently when providing support for one of my application on Mac Mojave I find out the culprit behind the top left corner view of table view. this can also be removed if we will set the corner view from xib like below.
This issue produces if Automatically Hide Scroller property is set to YES and no corner view has been set
Solution:
In my app i have UIView that floats at the top of a UITableView (Visualise:Attached to the bottom of the navigation Bar), under iOS5 i was enabling it to float at the top using these lines of code in scrollViewDidScroll
// get the table and buttonView bounds
CGRect tableBounds = self.tableView.bounds;
CGRect buttonViewFrame = self.buttonView.frame;
// make sure the buttonView at the table's original x and y as the content moves
self.buttonView.frame = CGRectMake(tableBounds.origin.x,tableBounds.origin.y,buttonViewFrame.size.width,buttonViewFrame.size.height);
This however no longer seems to work in iOS6, does anyone know why or how to fix the problem? I'm supporting iOS5 and above.
Having looked through the iOS6 release notes i found this...
Note that you can make a subview of the scroll view appear to float (not scroll) over the other scrolling content by creating constraints between the view and a view outside the scroll view’s subtree, such as the scroll view’s superview.
How would I set this up in code as Im not using AutoLayout in storyboards as I'm still supporting iOS5. It would also be great if anyone can enlighten me as to why the code i was using in iOS5 no longer works in 6.
I have made a window with an NSOpenGLView that I am rendering openGL content into.
I want to add some buttons and text fields to the view: I can add NSTextFields and NSButtons using interface builder (or code) but they do not appear.
NSOpenGLView is documented as not being able to have sub views, so I then made my own CustomGLView by deriving directly from NSView and implementing the code to create and use a NSOpenGLContext in it. But the subviews are still not appearing :- the OpenGL context paints over them.
On Windows this problem does not exist:- Windows used to host OpenGL MUST have the WS_CLIPCHILDREN and WS_CHIPSIBLINGS styles set ensuring that any peer, or sub children (views) will not be obscured by the OpenGL surface.
How do I get subviews to display over a NSView thats drawing using OpenGL ?
You have 2 choices:
Create a window just for the text field. Add as a child window of the one hosting the OpenGL view. Major downside is you have to manage positioning it correctly if the Open GL view is moved.
Set up your view hierarchy like so:
Layer-backed view
Layer-hosting view whose layer contains an OpenGL layer
Text field
Simply call -setWantsLayer:YES on the subviews of the NSOpenGLView.
NSOpenGLView cannot have subviews according to the documentation. Even if you subclass the NSOpenGLView, that will change nothing.
What you can do is to create a NSView that will hold both the NSOpenGLView and the NSTextField. You then overlap them in the right order to make one draw atop the other.
I'm not heavily into OpenGL yet, but it's my understanding that you can accomplish the visual effect of subviews with Quartz Extreme using layer-backed views; however, those may be problematic. Since subviews are not supported directly, any solution is liable to be a hack.
Indeed, the solution in that link actually hacks a second window to appear over your OpenGL display, the second window displaying the Cocoa views you desire.
The following code (from the above link) is something I've not tested (again not being an OpenGL guy by nature -- yet), but appears like a fairly clever approach:
// This is the GL Window and view you already have
glWindow = [[GLWindow alloc] initWithContentRect:windowRect];
glView = [[[GLView alloc] initWithFrame:NSMakeRect(0, 0, windowRect.size.width, windowRect.size.height)] autorelease];
[glView translateOriginToPoint:NSMakePoint(glView.bounds.size.width/2, glView.bounds.size.height/2)];
[glWindow setContentView:glView];
// And here's your transparent UI window
uiWindow = [[TransparentWindow alloc] initWithContentRect:windowRect];
uiView = [[[NSView alloc] initWithFrame:NSMakeRect(0, 0, windowRect.size.width, windowRect.size.height)] autorelease];
[uiView translateOriginToPoint:NSMakePoint(uiView.bounds.size.width/2, uiView.bounds.size.height/2)];
uiView.wantsLayer = YES;
[uiWindow setContentView:uiView];
[glWindow addChildWindow:uiWindow ordered:NSWindowAbove];
Again, I've not tested this, but it looks like it will get you the visual effect you desire.
The text can be rendered into a texture -- I just used this for a project, did a lot of looking for sample code, and ultimately found Apple's GLString demo code, which was an absolute trove of how-to:
http://developer.apple.com/library/mac/#samplecode/CocoaGL/Listings/GLString_m.html
I haven't tried adding buttons, but you can, of course, draw your own and comparing the positions of click events with those of your buttons...
This was my solution:
1) Create a parent NSView (let's call it parentView).
2) Add an NSOpenGLView Child to parentView.
3) Add an additional NSView Child to parentView (make sure this is after the OpenGLView within the hierarchy). You can add additional TextFields, etc. to this view.
4) In the ViewController for the parent make sure you call [parentView setWantsLayer: TRUE]; I did this within -(void) viewWillAppear
1) The NSOpenGLView can have a subview. It can have plenty even.
2) The reason some views, controls and other elements are being bullied by NSOpenGLView is due to the loading process when the Application launches. I.e If you add a slider or textfield above and into the content view of the window where the NSOpenGLView also resides, upon Application-Launch that textfield will most likely wind up beneath the NSOpenGLView.
This is an Apple Bug. And they know about it.
You can solve it quite easily even without adding a subview to NSOpenGLView...
In Interface Builder drag i.e. a CustomView into the canvas (Not the view). And set it the way you want it with sliders, text and what not. Then create an outlet (Call it i.e topView) in your view controller. Then somewhere in your code... Perhaps (applicationDidFinishLaunching) add this line...
[_window.contentView addSubview:_topView];
(Do your positioning & layout)
This will do the exact same thing as if you had dragged it into the contentView yourself inside IB. Only it will draw the darn thing in the correct Z position.
You loose IB's constraints this way and have to it manually
One could also just subclass and CAOpenGLLayer and use that as a backing layer inside of a regular NSView. There too it is drawn correctly...
Here is Apple's way of wanting to do that. CALayers are a Godsend ;)
Enter following String ** NSOpenGLLayer** in search and hit enter to get to where it is...
NSOpenGLLayer
Hope this helps....
In my small app for Mac OS X I display some info in system menubar. I use
statusItem = [
[[NSStatusBar systemStatusBar]
statusItemWithLength:NSVariableStatusItemLength]
retain
];
It works very nice and I can change the text with
[statusItem setTitle:[NSString stringWithString:#"Woo-hoo"]];
But it uses the default menu font which is too big for my relatively unimportant info. So I decided to reimplement it with a custom view. I created a view in Interface Builder.
Unfortunately, however, when I set it as a view for my menu item with
[statusItem setView:myView];
it just displays a white bar in the menu instead of my thing. I tried to
[statusItem
drawStatusBarBackgroundInRect:[myView frame]
withHighlight:NO];
with no success.
In trying to figure out whether a problem is with the view itself or with the way I assign it to the menubar, I created a window and did
[myTestWindow setContentView:myView];
This one worked seamlessly. This makes me think my view is OK :-)
So, what else can I try to make the menu item display my own view?
Thanks!
It happened to be some weird side-effects of window-view autosizing setup in Interface Builder (let’s call them size-effects). In the Inspector you can setup how subviews get resized upon superview sizing. And so it was somehow broken in my case, such that when window gets small enough (menuitem-high), my elements just got drawn outside of the window’s frame.
I re-configured the sizing in IB, eliminating all the automatics I don’t need, and now it works perfectly: the view from IB gets displayed inside a menu item.
What is the height of the frame of the view? Maybe your view is taller than the menubar and you are drawing outside of it. The current menubar is 22 pixels, but you should ask the systemStatusBar for it's thickness, just in case it ever changes.
Try drawing a frame around your view to see if you are getting anything.
[[NSColor blueColor] set];
NSBezierPath *path = [NSBezierPath bezierPathWithRect:self.bounds];
[path setLineWidth:4.0f];
[path stroke];
If you get just an 'L' shape (the bottom left corner) of blue then the view is too large. If you get a rectangle but still no text then you may not be drawing the text inside the view, look at the coordinates you are drawing the text at (and review View Geometry). Putting the view in a window may have worked because it is larger.
For an example of using text in a status menu view take a look at Matt Gemmell's NSStatusItemTest project.
EDIT:
Sorry, somehow I missed where you said you created the view in IB. I did a quick test and I can see the white box you mentioned.
The docs for NSStatusItem's setView: states
The custom view is responsible for
drawing itself and providing its own
behaviors, such as processing mouse
clicks and sending action messages.
And status item views go into a special (apple private) window called NSStatusBarWindow that may have different internal behavior than normal windows and certainly seems to not support views from IB.
So yes, I think you need to create a custom NSView subclass and do your own drawing in drawrect:.