Re: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
On Fri, 02 Sep 2011 10:04:54 -0700, Jens Alfke j...@mooseyard.com said: On Sep 1, 2011, at 9:26 PM, Julie Porter wrote: Again I am impressed with the help I received here. Hopefully others will be able to read these threads and learn from the experience of others. Julie: Youre welcome! Gang: One result of this is that Im realizing how difficult it is to explain the basic concepts of object-oriented programming to someone whos confused by them. Ive been using them so long, that its like a fish trying to explain how to swim. Id like to be able to point people to a good introduction, either online or in a book, but unfortunately I dont know of any. Can anyone recommend something? (It doesnt have to be Objective-C specific, although ideally it would describe dynamic languages, not static ones like C++ or Java.) Another common stumbling block seems to be nib loading, and the concept of wiring up your non-view objects so they can find each other at runtime. I think Im better at explaining this because I still remember learning it myself, but it would still be good to bookmark some clear descriptions. For nib loading, my iOS book pounds home all the key points (these are *instances* you're making and now you need a way to get *references* to them). The key chapter is available for free online: http://www.apeth.com/iOSBook/ch07.html The book does also introduce OOP concepts, of course, but it those chapters are somewhat spread out and aren't all available free, and are rather tightly tied to Objective-C and the particular behavior of the Cocoa frameworks; you'd have to see the actual book to decide if it's appropriate for your purposes (let me know off-list if you'd like a copy). There's also a fun OOP explanation in my Ruby intro, but it's rather tightly tied to Ruby: http://www.apeth.com/rbappscript/02justenoughruby.html m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
Hello. Jens, please take a look at this site: http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx Regards, Bruno --- Bruno Candido Volpato da Cunha 2011/9/2 Jens Alfke j...@mooseyard.com On Sep 1, 2011, at 9:26 PM, Julie Porter wrote: Again I am impressed with the help I received here. Hopefully others will be able to read these threads and learn from the experience of others. Julie: You’re welcome! Gang: One result of this is that I’m realizing how difficult it is to explain the basic concepts of object-oriented programming to someone who’s confused by them. I’ve been using them so long, that it’s like a fish trying to explain how to swim. I’d like to be able to point people to a good introduction, either online or in a book, but unfortunately I don’t know of any. Can anyone recommend something? (It doesn’t have to be Objective-C specific, although ideally it would describe dynamic languages, not static ones like C++ or Java.) Another common stumbling block seems to be nib loading, and the concept of wiring up your non-view objects so they can find each other at runtime. I think I’m better at explaining this because I still remember learning it myself, but it would still be good to bookmark some clear descriptions. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/brunocandidoo%40gmail.com This email sent to brunocandi...@gmail.com -- Bruno Candido Volpato da Cunha ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
On Sep 1, 2011, at 9:26 PM, Julie Porter wrote: Again I am impressed with the help I received here. Hopefully others will be able to read these threads and learn from the experience of others. Julie: You’re welcome! Gang: One result of this is that I’m realizing how difficult it is to explain the basic concepts of object-oriented programming to someone who’s confused by them. I’ve been using them so long, that it’s like a fish trying to explain how to swim. I’d like to be able to point people to a good introduction, either online or in a book, but unfortunately I don’t know of any. Can anyone recommend something? (It doesn’t have to be Objective-C specific, although ideally it would describe dynamic languages, not static ones like C++ or Java.) Another common stumbling block seems to be nib loading, and the concept of wiring up your non-view objects so they can find each other at runtime. I think I’m better at explaining this because I still remember learning it myself, but it would still be good to bookmark some clear descriptions. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
On Sep 2, 2011, at 10:32 AM, Bruno Candido Volpato da Cunha wrote: Jens, please take a look at this site: http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx Thanks for the link. I’m not thrilled by the writing style (it’s awkward and has a lot of grammatical errors; I think the author’s not a native English speaker) and it seems like a rather dry list of bullet points. I’m not expecting writing as entertaining as “The (Poignant) Guide To Ruby”, but there must be something clearer out there. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
Am 02.09.2011 um 19:04 schrieb Jens Alfke: I’d like to be able to point people to a good introduction, either online or in a book, but unfortunately I don’t know of any. Can anyone recommend something? How about Apple's documentation? Object-Oriented Programming with Objective-C http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/OOP_ObjC/Articles/ooOOP.html Of course it focuses on Objective-C and introduces some concepts that may not be found in certain languages while it ignores others that Objective-C lacks. But I think that will be true, no matter what language you use as an example. And the basic concepts are not that hard anyway. What is difficult is to learn to think in objects. Reminds me of Valve's Portal: Now you are thinking with portals. ;) Another common stumbling block seems to be nib loading, and the concept of wiring up your non-view objects Resource Programming Guide http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/Introduction/Introduction.html Andreas___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]
Just stay away from th e1986 Byte Magazine article describing OOP ... pretty funny actually. -koko On Sep 2, 2011, at 11:04 AM, Jens Alfke wrote: On Sep 1, 2011, at 9:26 PM, Julie Porter wrote: Again I am impressed with the help I received here. Hopefully others will be able to read these threads and learn from the experience of others. Julie: You’re welcome! Gang: One result of this is that I’m realizing how difficult it is to explain the basic concepts of object-oriented programming to someone who’s confused by them. I’ve been using them so long, that it’s like a fish trying to explain how to swim. I’d like to be able to point people to a good introduction, either online or in a book, but unfortunately I don’t know of any. Can anyone recommend something? (It doesn’t have to be Objective-C specific, although ideally it would describe dynamic languages, not static ones like C++ or Java.) Another common stumbling block seems to be nib loading, and the concept of wiring up your non-view objects so they can find each other at runtime. I think I’m better at explaining this because I still remember learning it myself, but it would still be good to bookmark some clear descriptions. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net This email sent to k...@highrolls.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 31/08/2011, at 2:49 PM, Julie Porter wrote:
I have the idea that a class, MyDocument is instantiated with an array
myEvents, each time a file is opened.
No, an OBJECT INSTANCE whose class is MyDocument is created when you open a
file. This document object HAS an array, myEvents. This is another object.
'myEvents' is a variable, in this case an instance variable, because there is a
separate copy of that variable for each instance of MyDocument. You refer to
the NSArray instance through this variable, myEvents, which is simply a pointer
to the array object.
You must understand the difference between a class and an instance. The class
is just the object's type, the instance is the actual thing in memory that has
that type. It's exactly the same as say, an int and a variable whose type is
int.
int;// a type
intmyInt = 3t; // an actual example of an int, called 'myInt', whose
value is 3
Just as a 'naked' int can't exist, you have to have a variable whose type is
int, a naked 'MyDocument' can't exist - you have to have a variable whose type
is 'MyDocument' (or, in Objective-C, the type must be a pointer, hence the *,
but that's just a quirk of Obj-C, and not a key conceptual point).
MyDocument; // a type
MyDocument* anActualDocument = [[MyDocument alloc] init]; // an actual
instance of 'MyDocument*', called 'anActualDocument' whose 'value' is whatever
the document consists of.
A separate class MyView is opened by MyDocument by some sort of magic in the
controller glue.
No. An OBJECT INSTANCE whose class is MyView is created when the document loads
the nib file that contains it. It's not magic, and the term 'open' has no
meaning here.
I can see how the MyView class has no understanding of the myEvents object as
there is no clear connection to the MyDocument class other than the
controller magic.
Correct (apart from the magic bit). The view has no knowledge of the document
object. You need to set up that knowledge in the form of a connection (it's
nothing more than a common-or-garden pointer) to the document.
What I do not get, is why an accessor such as an abstract getObject can not
get the Object from the open and instantiated MyDocument class. I guess it
need to have a link or line to the object in the MyDocument class, since
there is an instance of MyView spawned by the MyDocument, it would seem that
there should be a link between the two, but where is this link hidden? Or do
I need to make it programmatically?
Your view could have an outlet to the document:
@interface MyView : NSView
{
IBOutlet MyDocument* myActualDocumentInstance;
}
@end
In IB, you can connect this outlet to the document (File's Owner).
In your code, you can access the document from your view:
data = [myActualDocumentInstance graphicsData];
This assumes the document has a method called -graphicsData, which you'd
declare:
@interface MyDocument : NSDocument
{
}
- (id) graphicsData
@end
You are asking the instance (not the class) for some data, so you use the name
of the variable that points to the instance, and not the name of the document's
class, which is just its type. While you can send messages to a class, pretend
for the moment that you can't and that [MyDocument graphicsData] is analogous
to int-3 or something - sending a message to an int is nonsensical, you need a
variable of TYPE int.
(Another aside - do not create a method called getObject as a 'getter' - there
are proper naming conventions for property accessors, whether you write them by
hand or otherwise. A getter never includes the word 'get'. If your data
property is called e.g. graphicsData, then the proper accessors would be named
-graphicsData (getter) and -setGraphicsData: (setter))
This is even more confusing, What does IB have to do with my database and
communication between functions? I thought this was for things like buttons
and cells so that when one presses a button the value in a cell is passed to
the function.
It is, but it also is a convenient place to set up simple pointer connections
between objects it knows about. In this case, it 'knows about' both your view
and your document instances, so it's a perfectly good place to forge a simple
connection between the two, by using outlets (the term 'IBOutlet' is a hint
that the variable in question is visible to IB). It makes possible interesting
relationships between objects that might be difficult or even impossible to
establish in code. For example, your view needs to 'know about' your document.
Without a pointer to that document instance, where could it get one? It really
can't in a totally reliable way on its own, so simply making that connection in
IB cuts through an awful lot of difficulty. It could be argued that this is not
strictly to do with 'building an interface' (except in a more abstract sense of
building a programmatic interface between different
Re: Large over 100K pixel high ruler scroll view
Graham and others reading this thread; Jens Alfke and I took this discussion off list. He was able, as we have had similar background at apple to explain things, so that I mostly understand them. Enough to make the connection in interface builder and get my window scrolling. The last few days I have been coding the parts that draw my lines. Everything is now working. I want to express deep appreciation and thank yous to all that helped me get over the hurdle. I am especially impressed with the long response I just received. This sort of reply is the thing that really helps. The word Awesome seems a bit overused at the moment. It does fit here. I may grumble a bit, but I am really liking what Cocoa can do. I am amazed how fast I can scroll through the 25,000 or even 48,000 lines of data. Not only that, but my data model abstractions are compatible with CoreData. This way I can have one window or tab that represents the data graphically as lines. Another window or tab that show the data as events. Pretty nifty as someone at Apple used to say. Again I am impressed with the help I received here. Hopefully others will be able to read these threads and learn from the experience of others. -julie On 9/1/11 8:48 PM, Graham Cox wrote: On 31/08/2011, at 2:49 PM, Julie Porter wrote: I have the idea that a class, MyDocument is instantiated with an array myEvents, each time a file is opened.[ [...] I seem to have told you how to do this about twenty times now. Honestly, it's really simple. Stop looking at the trees and see the forest! --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On Aug 30, 2011, at 9:49 PM, Julie Porter wrote: What I do not get, is why an accessor such as an abstract getObject can not get the Object from the open and instantiated MyDocument class. I think maybe you’re not thinking the right way about “instantiated” (and “open” really doesn’t mean anything here.) “Instantiating” means “creating an instance”, i.e. creating an object that belongs to that class. It’s comparable to malloc. Saying “MyDocument is instantiated” just means that, somewhere in memory, there is an object whose class is MyDocument. It does not imply that there is any way to find that object given only knowledge of the class. There could be millions of MyDocument objects at any moment The getObject accessor is a method of MyDocument, but methods have to be called on objects. Otherwise it’s like calling Carbon’s GetWindowTitle without giving it a WindowPtr. The state that you want to access belongs to an individual MyDocument object, so there is no way to get it without having a reference to that object. What does IB have to do with my database and communication between functions? I thought this was for things like buttons and cells so that when one presses a button the value in a cell is passed to the function. Wiring in IB defines connections between arbitrary objects. It just happens that most of the objects you wire up are views. When you define a connection in a nib, then when the objects are loaded into memory they will be set up to point to each other. I think cocoa is the other way around, Where the document which has the array of dictionaries I want is not visible to the View because the view is not open to the document. Honestly, the metaphor doesn’t apply at all. There is no such thing as “open” or “visible”. There is no state involved. Trying to make analogies to PostScript is just going to confuse you even more. The document and view are fancy structs in memory, and for one to be able to access the contents of another, it has to have a pointer to it as one of its members. Does that make more sense? —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 8/29/11 10:39 PM, Graham Cox wrote:
NSDocument and NSView are totally unrelated classes.
[...]
So your view will be doing stuff like:
[myDocument giveMeDataForLinesInRange:linesRange];// in -drawRect:
and your document will be doing stuff like:
[myView setFrame:theSizeICalculatedFromTheData];
Sorry to keep this going. I am hopelessly lost in the Class and
Instance abstractions here. I do not think I am alone as I feel I have
spent most of the day with google. Reading the fustrations and confusion
of others, who can not quite seem to see the light.
I have an array of dictionaries. This is defined in the MyDocument
class. Inside MyDocument.m I can read, load NSLog and do anything I
want with this structure.
The basic for this is really simple.
code
@interface MyDocument : NSDocument
{
NSMutableArray *CISEvents;
}
/code
Reading a bunch of stuff online, I found how to use X code scripts and
create getters and setters. This gave me a whole bunch of acessors,
most of what make sense. like:
code
- (NSArray *)CISEvents {
if (!CISEvents) {
CISEvents = [[NSMutableArray alloc] init];
}
return [[CISEvents retain] autorelease];
}
/code
Problem is when I want to see this array in my view class file
CISView.m Which is based on the RulerView sample code. I define a
simple logline.
NSLog(@have %lu events.,[[MyDocument CISEvents] count]);
I get the error:
'MyDocument' may not respond to '+CISEvents'
Tried changing the + to - and got 'instance variable '' accessed in
class method.' all over the MyDocument.m file.
After a day of reading I see things saying I may need to create a
singleton. in the CISView.m file. Other more confusing helpful
suggestions have stuff set in interface builder and setting outlets and
such. But I am dealing with the database linedrawing into cliprects
and scrollbars, not calculators iPhone apps and such.
The closest I found was to try something like:
standardCISDocument = [[MyDocument alloc] init];
NSLog(@have %lu events.,[[standardCISIDocument CISEvents] count]);
The code I want to use for my view is based on the NSRuler sample code.
This has a +initialize to set the ruler graticule. I need to set the
ruler graticule dependent on information inside one of the array
dictionaries.
The compiler will not let me put the above code into +initialize as it
complains about instance abstractions that are confusing. the same
'instance variable '' accessed in class method. warning. If one has an
accessor, then why can it not access?
I read all about car and factory methods classes and such. Not to
mention examples relating to apples oranges and bananas.
But no where do I see a clear concise explanation for 35+ year assembly
language postscript C language programmers who still believe with
religious dogma that ints are pointers and pointers are ints! I never
liked private variables, but am open to evangelical conversion if the
arguments are clear.
The apple documentation is so curcumlocutious as to feel like a works
program for out of work document writers. Where are the code examples
next to the class instance declarations. Again what files do things go
into? It is all about where in the files to put things.
I tried putting the above singleton code in -awakefromNib, but I get 0
count. The View awake is called before the MyDocument awake but after
the -readfromURL stuff.
I tried adding a plain -init. This never seems to get called. It seems
like there are too many ways to do things and ever so much overhead,
which is good when paid by the hour. Not so good when writing shareware
and customware for oneself.
I have all of this working in Carbon/Quickdraw. Plus another postscript
file that does exactly what I want. Not sure what is more of a waste of
time, maintaining that or learning cocoa. Problem is my 5 powerpc
computers are not going to be of much use soon, so will need this to run
on what ever I can get.
I keep going over the cocoa tutorials, but they are completely set on
doing what has been done before. I got buttons down, I got
departments and employees down to make great lists of data.
I just can not figure out how to get my data array across multiple *.m
files to initialize frame abstraction and call drawRect. So that I
can scroll 25,000 to 10,000 lines. withouth having to create image data
sources, since my images are lines draw on as as needed basis.
-julie
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On Aug 30, 2011, at 8:43 PM, Julie Porter wrote: NSLog(@have %lu events.,[[MyDocument CISEvents] count]); I get the error: 'MyDocument' may not respond to '+CISEvents' This is the distinction between a class and an object. A class is a kind of template that defines what data objects contain. It doesn’t make any sense to use [MyDocument CISEvents]; it’s like asking “how many spots does the word Leopard have?”. Properties apply to individual objects, not to classes. This is pretty fundamental, and a lot of other things in Cocoa programming (as with Java or many other languages) won’t make sense until you’ve got it down. I think the other thing you’re having trouble with is how to have the different objects (not classes) in your app refer to each other. A pretty common way to do this is for the controller object (the document in your case) to initialize the view right after it loads by telling it where the model object is. In your case I’m assuming the array of events is the data model. So one solution is to give your view class a settable property that’s also an array of events, and have the document set that property on the view after the window loads. Typically you’d give the document class an IBOutlet pointing to the view, and wire that up in IB. Then as soon as the nib loads, the document knows the view and can initialize it. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On Aug 30, 2011, at 8:43 PM, Julie Porter wrote: I just can not figure out how to get my data array across multiple *.m files to initialize frame abstraction and call drawRect. It really has nothing to do with files. You could put your entire program into one source file (in the correct order) and it would compile and run. It has to do with what classes you have and what instance variables, properties and methods those classes have. You can draw this out on paper if it makes it clearer, with boxes for the classes and lines for references between them (i.e. instance variables that are pointers to other objects.) But no where do I see a clear concise explanation for 35+ year assembly language postscript C language programmers who still believe with religious dogma that ints are pointers and pointers are ints! I never liked private variables, but am open to evangelical conversion if the arguments are clear. You might need to back up a bit and find some good introductory books on object-oriented programming. This stuff has been around for a long time (Simula-67 and Smalltalk-72 started it) but it’s become mainstream more recently. It’s definitely a level of abstraction above procedural programming, but it scales much better. Unfortunately I don’t know what books to recommend. I was lucky enough to get into OOP really early (1984, in Smalltalk-80) so it’s like I’m a fish trying to explain how to swim. I wonder if this stuff would click better for you if you read a low-level explanation of how it’s implemented. Classes are tables that associate message names (selectors) with function pointers, and objects are structs that start with an invisible pointer to their class, and calling a method is a lookup that indirects through the object’s class hierarchy one level at a time until it finds the desired selector, then calls the associated function (passing ‘self’ as an invisible parameter pointing to the object.) I’m not sure if Apple’s Objective-C language book goes into this. The classic Smalltalk-80 ‘Blue Book’ does, I’m pretty sure. Anyway, I think the most important thing I can say is that this isn’t something you can plow straight into. You need to back up and absorb some theory, because you’re so used to a very different way of working that you’re not going to be able to absorb the OOP way just in the course of working tutorials. The Wikipedia article on Object-Oriented Programming seems to go into some detail (and links to other articles like Dynamic Dispatch that provide more). It also has a lot of references to useful-sounding books. http://en.wikipedia.org/wiki/Object-oriented_programming —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 8/30/11 8:59 PM, Jens Alfke wrote: On Aug 30, 2011, at 8:43 PM, Julie Porter wrote: NSLog(@have %lu events.,[[MyDocument CISEvents] count]); I get the error: 'MyDocument' may not respond to '+CISEvents' This is the distinction between a class and an object. A class is a kind of template that defines what data objects contain. It doesn’t make any sense to use [MyDocument CISEvents]; it’s like asking “how many spots does the word Leopard have?”. Properties apply to individual objects, not to classes. This is pretty fundamental, and a lot of other things in Cocoa programming (as with Java or many other languages) won’t make sense until you’ve got it down. I think the other thing you’re having trouble with is how to have the different objects (not classes) in your app refer to each other. A pretty common way to do this is for the controller object (the document in your case) to initialize the view right after it loads by telling it where the model object is. In your case I’m assuming the array of events is the data model. I have the idea that a class, MyDocument is instantiated with an array myEvents, each time a file is opened. A separate class MyView is opened by MyDocument by some sort of magic in the controller glue. I can see how the MyView class has no understanding of the myEvents object as there is no clear connection to the MyDocument class other than the controller magic. What I do not get, is why an accessor such as an abstract getObject can not get the Object from the open and instantiated MyDocument class. I guess it need to have a link or line to the object in the MyDocument class, since there is an instance of MyView spawned by the MyDocument, it would seem that there should be a link between the two, but where is this link hidden? Or do I need to make it programmatically? So one solution is to give your view class a settable property that’s also an array of events, and have the document set that property on the view after the window loads. Typically you’d give the document class an IBOutlet pointing to the view, and wire that up in IB. Then as soon as the nib loads, the document knows the view and can initialize it. This is even more confusing, What does IB have to do with my database and communication between functions? I thought this was for things like buttons and cells so that when one presses a button the value in a cell is passed to the function. I think I need to look up the definition of property. That may be what I am not understanding. That I abstract property and key as the same thing. Will attempt to read more on IB Outlet abstractions, but am not sure what an IBOutlet is in relation to my array of events. Which I am pretty sure is the Data Model. (apart from the arrays of dicts I could draw the keys and values using the list view CoreData tools.) In postscript I have a dictionary open on the stack that contains my array of dictionaries. If I open another dictionary on the stack I can read in my array, but any new define instances are declared in local to the new dictionary. When I close that top level dictionary I can no longer access any local changes. I think cocoa is the other way around, Where the document which has the array of dictionaries I want is not visible to the View because the view is not open to the document. I also keep seeing stuff relating to KVO. This relates to the really nifty Departments and employees type list, that sort of seem to happen with bindings. But that system will not let me have arrays of dicts inside arrays of dicts unless I can program them through classes or what ever abstraction I am failing to understand. Problem is I am not writing mail or iTunes, that has already been done. I think KVO is what, in the long term, I want. Connecting things in IB seems even more like going down the wrong path. Again in postscript I have keys and values. This is what is in my dictionary. One key might be @StartLine another key abstracts as @EndLine I have keys and values. I want to observe them between classes. Nothing more, nothing less. Saw the second part relating to OoP as they used to call it. I remember liking smalltalk and Logo, but I was in high school at the time 35 years ago. the world went to procedural programming. A lot of this really feels like a waste of time. Makework for programmers. I thought the point of such was to abstract things so that one can concentrate on the not so common code. There really should be a framework tutorial out there that works for scrolling graphics the same way one can scroll text. A black box where one only has to deal with the drawRect procedure that is file based. -julie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at
Re: Large over 100K pixel high ruler scroll view
One warning about extremely large views is that at some point you will run into floating-point rounding errors, since AppKit and CoreGraphics coords are 32-bit floats and have only 24 bits of precision. Still, that should get you to millions of pixels before the coords stop being pixel-accurate. 64-bit AppKit is much better in this regard than 32-bit. If memory serves, it lets you reliably operate NSScrollViews over dimensions in the billions. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 8/29/11 1:17 PM, wadesli...@mac.com wrote: One warning about extremely large views is that at some point you will run into floating-point rounding errors, since AppKit and CoreGraphics coords are 32-bit floats and have only 24 bits of precision. Still, that should get you to millions of pixels before the coords stop being pixel-accurate. 64-bit AppKit is much better in this regard than 32-bit. If memory serves, it lets you reliably operate NSScrollViews over dimensions in the billions. At the moment I need to support power PC (I have 5 computers.) most at least are running 10.5.8 which helps a lot. I am not to worried about the rounding. Much of this code was coded in postscript. So the graphics already are in floating point. In some ways it is too bad I can not call the cocoa classes from a postscript syntax, considering that the program already defines the data in arrays of dictionaries. I think at one time there was interactive postscript on the NEXT. Not sure if any of that still exists or not. As for the original question. I am not sure I ever got it answered? Simply where, as in what files, do I put the code that creates the super view that describes all my lines? I do have the code working that imports the data into the same array of dictionaries. The imported array comes in at 20713. Now I want to create a view that is 20713 lines high and 2600 lines wide. I am pretty sure I create or subclass NSScrollview do do this? Where do I put the code that sets this frame or clip area (which I think is the superview?) If I make a subclass of NSScrollVew called cisView, I get some basically empty files in the class, with no hints as to where things go or what to override. The Scroll View Programming guide has a code snippet (listing 1) Creating a scroll view programetically. This however uses an ImageView, which would require a data source that would read all the lines at once. I only want to draw or update the lines contained in the array that are visible dependent on where the scroller thumb is located. -julie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 30/08/2011, at 12:18 PM, Julie Porter wrote: On 8/29/11 1:17 PM, wadesli...@mac.com wrote: One warning about extremely large views is that at some point you will run into floating-point rounding errors, since AppKit and CoreGraphics coords are 32-bit floats and have only 24 bits of precision. Still, that should get you to millions of pixels before the coords stop being pixel-accurate. 64-bit AppKit is much better in this regard than 32-bit. If memory serves, it lets you reliably operate NSScrollViews over dimensions in the billions. At the moment I need to support power PC (I have 5 computers.) most at least are running 10.5.8 which helps a lot. I am not to worried about the rounding. Much of this code was coded in postscript. So the graphics already are in floating point. In some ways it is too bad I can not call the cocoa classes from a postscript syntax, considering that the program already defines the data in arrays of dictionaries. I think at one time there was interactive postscript on the NEXT. Not sure if any of that still exists or not. As for the original question. I am not sure I ever got it answered? Simply where, as in what files, do I put the code that creates the super view that describes all my lines? I do have the code working that imports the data into the same array of dictionaries. The imported array comes in at 20713. Now I want to create a view that is 20713 lines high and 2600 lines wide. I am pretty sure I create or subclass NSScrollview do do this? Where do I put the code that sets this frame or clip area (which I think is the superview?) If I make a subclass of NSScrollVew called cisView, I get some basically empty files in the class, with no hints as to where things go or what to override. The Scroll View Programming guide has a code snippet (listing 1) Creating a scroll view programetically. This however uses an ImageView, which would require a data source that would read all the lines at once. I only want to draw or update the lines contained in the array that are visible dependent on where the scroller thumb is located. Use Interface Builder to set up/design your interface. Add a custom NSView, set its class to your subclass. Place it inside a standard NSScrollView. In the -awakeFromNib method of the custom NSView subclass, set the frame size to what you need. The standard NSScrollView will cope, you do not need to subclass NSScrollView (the scrollview doesn't display your content directly, it it is merely a container for another view that does display your content). That's the essence of it. But in practice you'll probably want to have a NSDocument representing this file, in which case it is responsible for opening the file, working out the size and setting the view size as needed. The custom NSView subclass is what is going to do the real work. In the -drawRect: method, which you're obliged to override, you are passed a dirty rectangle. Using that rectangle, which is relative to the view's bounds, which in turn is the size of the total size you calculated from your file, you can work out what lines it is needing to redraw. Perform that calculation and request the data from the file. You'll need various lines of communication between your document and view (the document is the data model) which you can easily establish using outlets. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 8/29/11 7:29 PM, Graham Cox wrote: Use Interface Builder to set up/design your interface. Add a custom NSView, set its class to your subclass. Place it inside a standard NSScrollView. In the -awakeFromNib method of the custom NSView subclass, set the frame size to what you need. The standard NSScrollView will cope, you do not need to subclass NSScrollView (the scrollview doesn't display your content directly, it it is merely a container for another view that does display your content). That's the essence of it. But in practice you'll probably want to have a NSDocument representing this file, in which case it is responsible for opening the file, working out the size and setting the view size as needed. I already have the NSDocument.m which loads the array of dictionaries from the file. Do I place the awakefrom nib in that set of class files, or would they go into the file that I would derive from NSView called cisView.m? Do I need to set up accessors between the myDocument and cisView class files or do they inherit from each other? The custom NSView subclass is what is going to do the real work. In the -drawRect: method, which you're obliged to override, you are passed a dirty rectangle. Using that rectangle, which is relative to the view's bounds, which in turn is the size of the total size you calculated from your file, you can work out what lines it is needing to redraw. Perform that calculation and request the data from the file. You'll need various lines of communication between your document and view (the document is the data model) which you can easily establish using outlets. This is the part I already understand, but am unclear how to get to set up the init and awake overrides to get the 'dirty rectangle' I want. I think you have pointed me in the right direction. -julie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On Aug 29, 2011, at 7:18 PM, Julie Porter wrote: In some ways it is too bad I can not call the cocoa classes from a postscript syntax, considering that the program already defines the data in arrays of dictionaries. I think at one time there was interactive postscript on the NEXT. Not sure if any of that still exists or not. NeXTSTEP used Display PostScript; ripping this out and replacing it with a new graphics system (CoreGraphics aka Quartz) was one of the big tasks in the transition to Mac OS X. There’s some appeal to the idea of sending graphics to the display system as executable code, but it was very inefficient. (It was also proprietary code owned by Adobe, which demanded a fairly steep per-copy licensing fee.) There’s not really any direct correlation between a tree-based data structure (NSArrays/NSDictionaries) and PostScript. You’d just end up translating one representation into another (textual) one before having it rendered; calling CG directly skips that step. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 30/08/2011, at 12:54 PM, Julie Porter wrote: I already have the NSDocument.m which loads the array of dictionaries from the file. Do I place the awakefrom nib in that set of class files, or would they go into the file that I would derive from NSView called cisView.m? Do I need to set up accessors between the myDocument and cisView class files or do they inherit from each other? NSDocument and NSView are totally unrelated classes. This seems rather a basic conceptual area you need to understand. Model-View-Controller or MVC (I'm needing to write this in a very skeletal way because I have to be somewhere else imminently - maybe someone else can take a bit more time here). NSDocument is your model. It manages the file on disk. The View is contained by a window which is controlled by a window controller which is owned by the document. So they're connected, but have very different roles. You need to set up accessors if your view needs to know about your document, and vice versa. Outlets are an easy solution because you can connect them in IB and they'll be set up for you. However, purists might consider this a violation of MVC but for a simple scenario (which despite everything, yours is) will probably suffice. So your view will be doing stuff like: [myDocument giveMeDataForLinesInRange:linesRange]; // in -drawRect: and your document will be doing stuff like: [myView setFrame:theSizeICalculatedFromTheData]; WHEN the document does this is when it reads the file in response to a 'Open' commend - you'll find out how to respond to that properly in the NSDocument documentation. This would be instead of the view's -awakeFromNib - that's a good place if you were just setting the frame size to some large fixed number, but since the actual size really depends on the data in your file, then obviously a better place is when you open that file. At this point, NSDocument is preparing the window and its views from the nib, so they're not yet visible. The file opens, the view size is set (you may need to temporarily store the size, and wait until -windowControllerDidLoadNib: is called to make sure that the window/view is actually there - or do it in the view's -awakeFromNib by querying the document - their are plenty of ways to crack this nut) then the window is shown. Sorry, gotta go…. -Graham___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
I think, if you can use CATiledLayer, things will be a lot more easier. -ev On Aug 24, 2011, at 5:18 AM, Julie Porter wrote: I work with scans of 10 tune Nickelodeon player piano rolls. These can be over 100 yards long when unrolled. My roll images when uncompressed can be 100,000 plus pixels by 2800 pixels. In actual practice the images are made of lines, not pixels. To read these I have programs written in postscript or carbon. My carbon application is getting long in the tooth. I have been reading over this list and the Cocoa program examples and documentation over the last 3 months. I found the NSRulerView sample application. At issue is that interface builder will only let me make a view that is 1 pixels. Searching the web I see suggestions to do this programmatically. I am not sure where the code to create the window would go. I am finding that Cocoa, especially V2.0 obfuscates things, especially where to put things. What examples I have are base on images, but I am drawing lines, based on the scroller positions. I already have postscript and carbon code that tiles the images, So if I have the first set of lines to draw and the last set of lines to draw, I can find these in the file and draw them. How do I do setup the ruler and scrollviews programetically without interface builder? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/ev%40monoceroi.com This email sent to e...@monoceroi.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
if (*ra4 != 0xffc78948) { return false; }
On 23 Aug 2011, at 22:18, Julie Porter wrote:
I work with scans of 10 tune Nickelodeon player piano rolls. These can be
over 100 yards long when unrolled. My roll images when uncompressed can be
100,000 plus pixels by 2800 pixels. In actual practice the images are made of
lines, not pixels.
To read these I have programs written in postscript or carbon. My carbon
application is getting long in the tooth.
I have been reading over this list and the Cocoa program examples and
documentation over the last 3 months.
I found the NSRulerView sample application. At issue is that interface
builder will only let me make a view that is 1 pixels.
Searching the web I see suggestions to do this programmatically. I am not
sure where the code to create the window would go. I am finding that Cocoa,
especially V2.0 obfuscates things, especially where to put things. What
examples I have are base on images, but I am drawing lines, based on the
scroller positions.
I already have postscript and carbon code that tiles the images, So if I
have the first set of lines to draw and the last set of lines to draw, I can
find these in the file and draw them.
How do I do setup the ruler and scrollviews programetically without interface
builder?
Your best bet is to not completely dump IB, but to simply set the contentSize
programatically as soon as you load your document.
I don't really see what you're saying about cocoa obfuscating things, it's one
of the most clear APIs out there, and I'm not sure what you mean by v2.0
either. Re your specific example though – you should not be drawing anything
based on a scroller position. Instead, the NSScrollView will ask for a
specific rectangle of your contentView to be drawn using -
(void)drawRect:(NSRect)r. Simply draw the area you've been asked to draw and
all will go well.
This all said, I'd recommend against using a scroll view here. Extremely long
scroll views can get very difficult for the user to navigate. Instead, it
might be worth considering some kind of scrubbing interface. Maybe something
like a movie editor that shows a miniature visualisation of each section of
roll, and allows the user to easily scrub through.
Bob
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 23 Aug 2011, at 22:18, Julie Porter wrote: How do I do setup the ruler and scrollviews programetically without interface builder? On 8/23/11 2:30 PM, Thomas Davie wrote: Your best bet is to not completely dump IB, but to simply set the contentSize programatically as soon as you load your document. This is what I am having issue with.How and where to put the delegates? Specifically what file would I place them into? Or do I create a new file for the delegate that does this? This all said, I'd recommend against using a scroll view here. Extremely long scroll views can get very difficult for the user to navigate. Instead, it might be worth considering some kind of scrubbing interface. Maybe something like a movie editor that shows a miniature visualisation of each section of roll, and allows the user to easily scrub through. I am not familiar with what a scrubbing interface would be. Can you suggest some examples. Re your specific example though – you should not be drawing anything based on a scroller position. Instead, the NSScrollView will ask for a specific rectangle of your contentView to be drawn using - (void)drawRect:(NSRect)r. Simply draw the area you've been asked to draw and all will go well. I may be unclear here. My existing code is based on what line number of the file to display. Piano rolls are viewed from bottom to top, so I am using a postscript style interface. My understanding once I get the view set up drawRect will give me a rectangle, where the bottom of the rectangle would be the line to start drawing. The top of the rectangle would be the limit to stop drawing at. The rectangle would be in my coordinate space and scaled appropriately. This seems so much better than the carbon way of having to find the scroller position in QD points, then scale them to postscript points. Why I was surprised at the 10K limit. I don't really see what you're saying about cocoa obfuscating things, it's one of the most clear APIs out there, and I'm not sure what you mean by v2.0 either. Simply that there are too many choices to choose from. Ironic in that I am a postscript programmer, a language that is the definition of obfuscation. Perhaps I am thinking backwards here? Do I use delegates or bindings? There are some setup wizards, but when one runs them, there are no code parameters to change. It is like I have to read the mind of the application engineer that defined the class. But I digress .. Bob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On Aug 23, 2011, at 4:19 PM, Julie Porter wrote: Your best bet is to not completely dump IB, but to simply set the contentSize programatically as soon as you load your document. This is what I am having issue with.How and where to put the delegates? Specifically what file would I place them into? Or do I create a new file for the delegate that does this? The scroll view will set its scrolling range based on the size of the frame of its embedded document view, which is the view that you draw into. So there’s no need to set a document size in IB. Just make the document view an instance of your custom view class (drag in a Custom View object, set it to your class, then do Embed In Scroll View). At runtime when you load the data your view can calculate how large it needs to be and set its frame rect appropriately. The scroll view will detect that and change the scroll range. One warning about extremely large views is that at some point you will run into floating-point rounding errors, since AppKit and CoreGraphics coords are 32-bit floats and have only 24 bits of precision. Still, that should get you to millions of pixels before the coords stop being pixel-accurate. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 24/08/2011, at 9:56 AM, Conrad Shultz wrote: You are right about the coordinate space, but remember that NSScrollView does not handle zooming (scaling?) - that is up to you. I have a view subclass that simplifies this task http://apptre.net/gczoomview.htm Drop this into a NSScrollView and it gets you a lot for free (NSScrollView itself will happily accommodate the zoom automatically, and if you have rulers showing, they also adjust properly). I'm not sure about the 10,000 pixel limit - I've never run into it. But I believe that pertains to the view's frame, not its bounds. The bounds is the logical content dimension, not the area shown on screen, which is much smaller for a view that can be scrolled. One reason for a limit is that if the view has to be buffered in a bitmap, a 10,000 limit sets a practical limit on how much memory that could require. But such a buffer only needs to buffer the frame, not the bounds. So In IB, set up your scrollview and content view within, setting it to some arbitrary size. When you actually load the nib, you can set the bounds to the same dimension as the content (in -awakeFromNib for example), and all should be well. Carefully use the parameter to -drawRect: to load only the part of the image that is requested and you should find it all works efficiently - the only part of the image ever in (video) memory is what you see - all the rest is somewhere else (disk, e.g.) Note that when you zoom a view, the frame and the bounds have a further difference, which not only describes the scroll offset, but the scale factor as well. A highly zoomed-in view vastly exceeds the 10,000 pixel limit, yet works just fine. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
I don't see how bindings come into this. I'm also unclear by what you mean by setup wizards - are you referring to Xcode templates, or...? - -- Conrad Shultz This is actually a graphical interface on top of a coredata database (XML) So I used the core data tools and bindings to define my database. There are many parts to this application. One side reads in the image of a Nicelodian piano roll and detects where the holes are. The other side needs to draw either the background image (lines) or the holes dots. A separate part of the program also contains a database of 100s of these Nickelodian Piano rolls. This part works as sort of an iTunes Play list. I set most of this up with the core data document finger paint program thing used in the departments and employees example. Not sure what the finger painting interface is actually called, it really works nice, though for setting up lists of events. Much better than the old list manager. One might think of the database as MIDI, but it quote Doctor Who, That would be wrong. The suggestions as to using CA are interesting since there are similarities to audio and video editing which I had not considered. -julie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
On 24/08/2011, at 10:21 AM, Graham Cox wrote: I'm not sure about the 10,000 pixel limit - I've never run into it. But I believe that pertains to the view's frame, not its bounds. Note that when you zoom a view, the frame and the bounds have a further difference, which not only describes the scroll offset, but the scale factor as well. A highly zoomed-in view vastly exceeds the 10,000 pixel limit, yet works just fine. I should correct this - Jens is right, the frame can exceed 10,000 pixels if you set it programatically, because it's clipped by the NSClipView within the NSScrollView. If the frame and bounds of the content view are the same, the view's scale is 1:1. For zooming, these rectangles change in proportion. The scroll offset is nothing to do with the frame/bounds of the content view itself, but is a function of the scrollview and its clipview. Sorry for the confusion. But the thrust of what I said should work - set it all up in IB with some arbitrary size, then set the real size when the view is loaded. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Large over 100K pixel high ruler scroll view
whoops, sorry... http://apptree.net/gczoomview.htm (note - handling zoom isn't difficult, but this class makes it easier and adds some useful UI-level actions that can be directly hooked to menu commands if you wish). --G. On 24/08/2011, at 10:36 AM, Julie Porter wrote: On 8/23/11 5:21 PM, Graham Cox wrote: I have a view subclass that simplifies this task http://apptre.net/gczoomview.htm your link is broken. -julie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
