I've got my custom NSView with a bunch of custom buttons in it, the buttons are added as a subView in the NSView's drawRect method.
Now I'm finding that after pressing a button the drawRect of the parent view is repeatedly called. Sometimes it only stops when I quit the app - I know this from a simple log statement in drawRect.
Now I know there are probably bigger architectural issues in my app causing this, where do I go to begin tracking down what's causing this view to be repeatedly redrawn?
Thanks!
First of all you shouldn't be adding subviews in drawRect:.
Are you doing any custom drawing or are you just adding subviews? If you're not doing any drawing, you should not implement drawRect:.
You want to add the subviews in initWithFrame: and then you want to set the frames of the subviews in layoutSubviews based on self.bounds.
If you have any questions, feel free to ask.
EDIT: Just realized that you were asking about NSView and not UIView. I've never used NSView, but perhaps they work similarly.
EDIT 2: I read a bit about NSView and it doesn't seem to have layoutSubviews. Perhaps you should set the frames in drawRect:? I'm still pretty sure you don't want to add subviews in drawRect:.
Related
I'm working on an app made by a NSWindow which own a lot of custom subviews, that could be opaque or not.
Whenever I call SetNeedsDisplay: or SetNeedsDisplayInRect: on a subview, the system calls the drawRect of each single subview starting from the content view of the parent NSWindows.
How can it be avoided? How can I redraw just the dirty subview (it should be the default behaviour)? Is there something that I'm missing maybe in subclassing the NSView? Or in setting the properties or the syle of the parent NSWindow?
Thanks
The that could be opaque or not is the trouble-some bit. Any non-opaque view triggers a redraw of the entire view hierarchy, because the window must restore that views background to a pristine state. Only views set to opaque may not require anything else below them to be redrawn. They might still trigger redraws "above" though, if the opaque view itself is partially covered by other views.
Ok, I think I’ve figured it out. It seems that turning all the subviews into layer-backed views did the trick.
And this is reasonable giving the way the layers are managed by the gpu and how the layer compositing is performed.
But I still don't understand why, using the "classic" NSViews, no matter if they are opaque or not, siblings or children, overlapped or not , I cannot invalidate a single view without the system calls the re-drawing of the entire view hierarchy of the window
I have designed a custom subclass of UITableView. At some point in its use, I need to add a UIView as a direct subview of UITableView, drag it within the table view using my finger, and then remove it from the table view. I use a UILongPressGestureRecognizer to create a view in much a similar manner as the iOS Calendar app, drag it around the tableview by resetting its frame, and then remove it from the table view by adding it to a cell.
This works, but with one caveat. When I move my finger too quickly, I "lose my grip" on the UIView, and it does not catchup to my finger unless I move my finger back within the frame of the view to "pick it up" again.
Since UITableView subclassed from UIScrollView, I tried setting the table view's delaysContentTouchs and canCancelContentTouches properties to NO, while setting the exclusiveTouch property of the UIView being dragged to YES. Nothing has worked.
Ultimately, I want to be able to drag my UIView around inside the table view with just as much responsiveness as the built in iOS Calendar app. Any thoughts?
P.S. I am relatively new to iOS development, so please forgive if there is some major oversight here.
Problem solved! As it turns out, there was nothing inherently wrong with the setup (adding a subview to a UITableView and dragging).
After much digging, I discovered that I had been performing a hitTest every time the view was dragged to a new coordinate. One could see how performing such an intensive operation every second could slow down processing enough on the device to cause this weird behavior. When I changed it, everything worked perfectly.
Ultimately, the lesson to be learned was that my view controller subclass was too complex and therefore not easily readable. There was too much digging necessary to uncover this issue. I have since taken great pains to simplify my code - it has been incredibly rewarding.
I'm placing a few buttons in a simple rectangular NSview which acts as a custom toolbar. On first render the buttons/views come out as expected, but every time a button is pressed (and sometimes with no mouse interaction at all) artefacts start appearing.
Before
After
I can eliminate the artefacts by calling a [self.toolbarView setNeedsDisplay:YES] in all the action and focus methods but this seems like a hack, is there any clean way to deal with this?
It was a beginner's problem. In the drawRect method
- (void)drawRect:(NSRect)dirtyRect
I was using the param dirtyRect for drawing an outline of my view, assuming it was the view's bounds, where in fact it was only the area around the buttons that became dirty when they were pressed. The 'artefacts' were actually my outline being drawn in the wrong place.
By correctly using the bounds of the view
NSRect drawingRect = [self bounds];
the 'artefacts' no longer appeared.
You just try to set focus ring for a buttons to 'none' in IB.
I am pretty new to coding and would like to know how to switch XIB views on a button click. IS there also anyway to add animation when switching?
Thanks,
Kevin
this is totally possible, but there are a few things you'll need to do. I imagine you are already familiar with connecting outlets to objects in your XIB, so the first thing you need to do is create the custom views in your XIB and connect them to outlets in your appDelegate. I suggest that one of the views be dragged into the window and one one be outside the window. That way, when the window loads, it already has one of your custom views as a subview. This just makes it easier to get started.
Then you're going to write an IBAction in the appDelegate and connect it to your button. Assuming that one of the custom views is already being hosted by the window, the IBAction should send a replaceSubviewWith message to the window's contentView animator like this [[window.contentView animator] replaceSubview:firstView with:secondView]; where firstView and secondView are the pointer/outlets that you declared and connected to the views in your XIB.
This is sending the animator proxy of the window's content view a message which tells it to replace the old subview with the new one. The reason for sending the message to the view's animator proxy (and not the view itself) is that the transition will be carried out with the deafult CATransitionAnimation. Because you want it to be animated, right?
The reason why you shouldn't remove one subview and then add another is because animating the removal of a subview is actually quite tricky and requires the implementation of the delegate method animationDidEnd. This is because executing an animation on a view that has been removed from the view heirarchy does not make sense. I don't know why Apple hasn't changed this, but for now it will be one of the enduring quirks of CoreAnimation.
Let me know if that helps. I am happy to clarify! And welcome to Cocoa!
An easy way to do this is to use a tabless NSTabView- you can lay everything out in IB so the pain is minimal.
I have an NSWindow that I want to display as part of another window. It has to be an NSWindow; I don't want to change it to an NSView or anything... I just don't because it involves accessing foreign nib files and the such.
How should I accomplish this if possible? I was thinking along the lines of grabbing the view of the NSWindow and sticking it as the subview of another view in my main window... but I don't think this is possible. Is it?
If you're okay with the window as-is, just add it as a child window to the window in your own app. That will handle positioning and everything, although you might have to patch up the responder chain and such to really get things working properly.