I had a great system (It worked but was probably not the correct way to accomplish the task) going to animating one NSView over another. The user clicked a button and an NSView flew in over the other "replacing" it. The problem came in with window resizing. Due to the way I set it up, one view was sitting in a non-visible location and animating in with animator, resizing was nearly impossible. I also tried this which seemed promising but failed to deliver a method (and I couldn't come up with one) for handeling window resizes. So how can one accomplish the seemingly simple task of swapping views with a nice transition? Sorry for the long winded question and hopefully I explained the system I had clearly enough.
Thanks for any help/advice
Just add your controller as the window's delegate and implement the windowWillResize:toSize: delegate method.
In your implementation of the method you should set the size of your off-screen view appropriately.
Related
I have been trying to create a simple swipe transition. However buttons seem immune to any CAAnimation that crops.
I am trying to get it so that a bar moves across the screen and as it goes over the button it removes the part it has just gone over.
I have tried bounds.width, size.x and many other key-value paths to achieve the affect but I haven't got what I wanted. It just relocates the text which always remains entirely visible
I have also tried changing the UIButton to a UIImage but the text does not seem to print on a UIImage.
I tried using masks too but I have heard they should be used as infrequently as possible as they consume the phones resources. I didn't really get very far with this either anyway as I hadn't used them much before.
I also tried placing it in a container view and then change the dimensions of that but again all of the text remained entirely visible.
I know I could have a view hide the button but I am trying to reveal the view behind as the bar swipes.
Does anyone have any suggestions of how to achieve a swipe transition on a UIButton?
Help would be much appreciated.
Thanks
I think what you're looking for really is a mask. See the tutorial here:
http://iosdevelopertips.com/cocoa/how-to-mask-an-image.html
What I'd do in your situation is create a custom UIButton class, and add a mask as in the tutorial, then animate the position of the mask. Slide the mask of, nothing shows. Slide it on, part shows until the whole thing is visible.
Edit: I haven't really heard anything about hogging resources, especially since it appears to be simple core graphics.
According to the NSWindow Class Reference, you should "rarely need to invoke" the NSWindow methods "display" or "setViewsNeedDisplay". So what is the usual way to redisplay the window's contents?
EDIT: I am having trouble dealing with resizing events. I just want to have everything scale proportionally. See this question. As no one seems to have any ideas for using masks to get it to happen, I want to redraw the whole thing.
Jason's comment really should be an answer:
Generally you don't need to. Instead, you invalidate whatever view needs to be invalidated for whatever reason within the window.
In addition to that comment, I'd add that you might want to explain why you feel you need to do this. While there are sometimes perfectly valid reasons to force the whole window to redraw, they are rare and you should suspect You're Doing It Wrong™.
Use this method to flag subviews for redisplay:
- setNeedsDisplay:YES
I am trying to create a view for a kind of brainstorming application like, for example, OmniGraffle, with elements that contain textviews and can be dragged around. (Also, the should be connectable with arrows, but that is not (yet) the problem)
I did my homework and searched via google and read books about cocoa, but there seems to be no similar example around.
Since I am also new to cocoa, I’m a bit helpless here.
The thing I am sure of is, that I need a custom view in which I can create my elements - what I tried until now to do that is:
First, I searched for the syntax to add subwindows to a window to create my elements. Subwindows, I imagined, would automatically be movable and come to front and so on.
The problem: As the experienced Cocoa-programmers of you probably are not surprised, I was stunned to find nothing about anything like that - this seems to be something, that is just not intended in Cocoa?!
Then I thought about creating subviews that contain a custom view for the title bar drawing (where the user can click to drag the element) and a NSTextView.
Problems:
I read, that it is not so clever to create dozens of subviews in a window because that would be very slow (or would that be not so bad in this case because all the subviews would be instances of always the same class?).
Also I can’t find out how to load a subview from a nib- or xib-file. Would I need a viewController? Or would that make the dozens-of-instances-problem even worse?
And Apple tells you not to overlap subviews (okay, that would be not so important, but I really wonder how the guys at OmniGroup made OmniGraffle...)
Because of that, I now wanted to do the title-bar-drawing in the surrounding custom view and create the textview programmatically (as I understand, a text-“view“ ist not really a view and takes its functionality from NSCell to reduce all the effort with the views?).
Problems:
Even that failed because I was not able to create a textview that doesn’t fill the complete window (the initWithFrame: of the [[NSScrollView alloc] initWithFrame: aRect] just seems to be ignored or do I get that wrong?).
Also, there should be some buttons on each element in the final application. I imagine that would be easier to accomplish with a subview from a nib-file for each element?
Well, now that nothing works and the more I read, the more problems seem to occur, I am pretty confused and frustrated.
How could I realize such a program? Could someone please push me in the right direction?
I created a class for the draggable elements where I save position, size and text in instance variables. In my view, every new element instance is added to an array (for now, this works without a controller). The array is used to draw all the elements in a loop in drawRect:. For the text of the element I just use a NSTextFieldCell which is set to the saved text from every element in the same loop.
That way it is also possible to overlap the elements.
Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?
I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).
Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.
The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.
Repeat after me: OSX is not iPhoneOS.. :P
Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.
Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.
I have an NSCell subclass that I do all kinds of custom drawing in. The only time things seem to be entirely out of my control is when right clicking a cell to show the associated context menu. While showing it's context menu, the table (or cell - not sure which exactly is doing this) draws a focus rect. I would like to get rid of this, or at least find a way to draw my own version of it that better fits within my interface.
I have tried about 15 different methods that seem like they could give me control over this focus rect drawing itself (various first responder methods, various drawing methods, various highlight color methods, etc.), but I have yet to find something that changes anything about it.
Screenshot of the problem: http://twitpic.com/3zx2t
I am almost annoyed enough to class-dump AppKit and try to find whatever private method it's using to draw this annoying focus rect. Nothing else I do has any effect on it. Any help here would really save both my sanity and lots of future hair pulling.
Thanks so much!
Without completely overriding your table view's -drawRect: this is the only other way I know to get rid of the context menu highlight rect.
- (void)_drawContextMenuHighlightForIndexes:(NSIndexSet *)rowIndexes clipRect:(NSRect)rect {
return;
}
This is the method, used in Leopard at least, to draw the highlight around cells that will be activated upon by a context menu. It is unfortunately called directly by NSTableView's -drawRect: method and as far as I know there is no other way to signal your disinterest in having those highlights drawn.
Of course this is private API, it may stop working in Snow Leopard, or some other release. But at worst that means that somewhere along the way the context menu highlight may start up again in your programs on newer releases or some other functionality using this method may not work later. You have been warned.
On 10.5 and later, NSTableView allows you to bring up a contextual menu on any item in the table (that is, without having the side effect of changing the selection.)
It draws that 'focus rect' to indicate which item(s) are being acted on by the contextual menu.