||Building a Scratch Pad with Cocoa|
|Subject:||I'm going to try to say what's going on|
Response to: How to use scrolling in a NSView Subclass
Here's what I think is going on. If I'm right, I agree with you, I'm confused as you why it doesn't work.
loc, an NSPoint gets assigned, at first, the location of the mousedown. Then, with a c assignment, you take that location relative to the origin and use that for loc. Then scrollPoint, a method of NSView, is supposed to scroll the view. After, setNeedsDisplay, forces a redraw of the view.
It seems that if all that I said above is true, this thing you made should work.
One candidate to make it work would have you go through reading all the methods to see where this thing falls short of the above expectations. That candidate course of action, however, doesn't break the problem into chunks.
A question, however, came out of the blue for me. WIth mousedown so engaged what is the source of the drawing that you are scrolling? If you have the drawing happening in the NSView method (is it drawrect?) then that happens after setNeedsDisplay and so the scrolling can't move it.
I'm thinking that it's possible that scrolling moves screenbits and you don't use setNeedsDisplay to force a draw after scrolling . Is that so?
There's a chunk to find out !
Maybe you could make an additional button and boolean and have a multiuse mousedown and have some sense of conceptual victory. The button and boolean would have two states, one for mousedown draws and other for it scrolls.
Well, I'm sorry, I don't get much more coherent today, New Year's Day. I'm exhausted. I don't dare experiment with my ideas on this today.
Soon (Friday) I go off a week to visit my mother without internet access.
I'm going to try to say what's going on
2002-01-03 08:02:33 zeus [View]