Re: Displaying a number with Quartz
Actually, your pure Objective C version would be to use NSString's drawAtPoint:withAttributes instead of converting to a char* and using CGContextShowTextAtPoint. http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSString_AppKitAdditions/Reference/Reference.html Gunnar - Original Message > From: Pierre Berloquin > To: Sean McBride > Cc: cocoa-dev@lists.apple.com > Sent: Tuesday, May 26, 2009 9:13:26 AM > Subject: Re: Displaying a number with Quartz > > Finally, thanks to Alexander, my pure Objective C solution is > NSString *S = [[NSString alloc] initWithFormat:@"%i", i]; > const char *text = [S UTF8String]; > > and no warning this time except that I should learn more about C > > Thanks > Pierre > > 2009/5/26 Sean McBride > > > On 5/26/09 5:12 PM, Alexander Spohr said: > > > > >> Never ever use sprintf for anything. > > > > > >If you use "%d" and know it will be an int? You know how many chars > > >you'll have at max, no buffer-overflow possible. (You might argue > > >here, that at some time we will habe 128-bit ints, but hey you should > > >recode your app then anyway or just have a buffer large enough to > > >handle that right at the start) > > > > > >And yes - you are right, use snprintf instead... int might become 256 > > >bit. > > > > You can use sprintf safely if you're very careful, I suppose, but using > > snprintf is not harder and so much safer. sprintf is just not worth the > > risk. > > > > -- > > > > Sean McBride, B. Engs...@rogue-research.com > > Rogue Researchwww.rogue-research.com > > Mac Software Developer Montréal, Québec, Canada > > > > > > > > > -- > Blogs : http://bibliobs.nouvelobs.com/blog/jeux-litteraires > http://pierre-berloquin.blogspot.com/ > > Développement durable des neurones par le jeu de réflexion > www.crealude.net > > Sustainable development of neurones through mind games > www.crealude.net/us > > Que fait-on pour les mal-codants ? > ___ > > 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/tonecluster%40yahoo.com > > This email sent to toneclus...@yahoo.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: What's the differnece between API and Framework?
There are also multiple definitions of "framework." Here's Apple's definition: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html "A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package. Multiple applications can use all of these resources simultaneously. The system loads them into memory as needed and shares the one copy of the resource among all applications whenever possible." In the Finder, go to /System/Library/Frameworks. There, you'll find a bunch of directories that end in ".framework". For example, CoreAudio.framework. These are the frameworks the above definition refers to. In the wider software development world, however, the term "framework" has additional nuance: http://en.wikipedia.org/wiki/Software_framework "A software framework, in computer programming, is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality. Frameworks are similar to software libraries in that they are reuseable abstractions of code wrapped in a well-defined API. Unlike libraries, however, the overall program's flow of control is not dictated by the caller, but by the framework. This inversion of control is the distinguishing feature of software frameworks." In this definition, a framework is like a machine that you can plug your custom gears into, while a library is like a box of Legos that you can build stuff out of one block at a time. Cocoa is a framework in both the Mac-specific sense, and the wider, computer science sense. Here's where it gets potentially confusing: some Mac frameworks fit the machine/gears metaphor and some fit the Legos metaphor. As others have said, an API is the "menu" or "blueprint" for how your code should use a framework or set of libraries. Gunnar - Original Message > From: Chunk 1978 > To: cocoa-dev Dev > Sent: Thursday, May 21, 2009 6:38:45 PM > Subject: Re: What's the differnece between API and Framework? > > ok... so an API is like a lower level framework? wikipedia states > that Carbon and Cocoa are APIs on Mac, but i always thought those were > frameworks. > > On Thu, May 21, 2009 at 8:50 PM, Jonathan Hess wrote: > > An API is a set of functions, classes, methods, and other bits that give you > > a method to interface with a piece of software. A framework is one concrete > > way to package a body of software with a set of header files that describe > > its API. A web service is another way to give clients an API to a set of > > software functionality that exists on a far away server. > > > > So, you might think of a framework as one of many methods of delivering a > > package of software with an API. > > > > Jon Hess > > > > On May 21, 2009, at 5:33 PM, Chunk 1978 wrote: > > > >> my learning is still shady on what is actually an API... sounds like a > >> framework to me... ? > >> ___ > >> > >> 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/jhess%40apple.com > >> > >> This email sent to jh...@apple.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/tonecluster%40yahoo.com > > This email sent to toneclus...@yahoo.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: NSToolbarItem with custom view in Interface Builder 3 (Leopard)
I actually went with the alternative suggestion. One caveat with that is that the pasted plain NSView is invisible in Interface Builder, although it does occupy space in the toolbar editor. The custom subclass of NSView does need to implement the NSCoding protocol, as one would expect for -[NSToolbarItem setView]. I filed feedback on the documentation requesting a note that the behavior is broken, with a description of this workaround. Thanks again, Gunnar - Original Message > From: Jonathan Hess > To: Gunnar Proppe > Cc: cocoa-dev@lists.apple.com > Sent: Monday, May 11, 2009 7:38:01 PM > Subject: Re: NSToolbarItem with custom view in Interface Builder 3 (Leopard) > > > On May 11, 2009, at 6:03 PM, Gunnar Proppe wrote: > > > > > Howdy Jon, > > > > Thanks for the tips, I'll give that a try. The first suggestion sounds > > close > to where I was going to go, except I hadn't thought of instantiating the view > in > the NIB file. Great idea. > > > > Your alternative suggestion sounds interesting but I'm not sure I > > understand > it. Would I then set the class name in the Identity pane of this pasted, > plain > NSView to my custom class? > > Yes. > > > What's different about this plain NSView from the "custom view" dragged > > from > the library? > > The "Custom View" has additional behavior beyond an NSView. One way they are > different is that when a custom view is instantiated from a NIB file it > receives > the initWithFrame: message instead of initWithCoder:. > > > > > Is this a bug in Interface Builder, or did I misread the linked > > documentation? > > This is a bug in Interface Builder. > > Jon Hess > > > > > From the doc: > > > > "The procedure for adding a custom view item is very similar to that for a > custom image item. (“Custom” in this context means any object from the > Interface > Builder library as well as instances of a custom NSView subclass.) Just drag > any > view object from the library onto the Allowed Toolbar Items area. Click the > item > once and press Command-1 to display the Attributes pane for the object as a > toolbar item; click again to edit the attributes of the item as itself. You > should modify the size of the custom view item in the Size pane of the > inspector, not directly. If you drag a Custom View object into the > allowed-items > set, click it twice and set the name of the custom NSView class in the > Identity > pane of the inspector (Command-6)." > > > > Gunnar > > > > > > - Original Message > >> From: Jonathan Hess > >> To: Gunnar Proppe > >> Cc: cocoa-dev@lists.apple.com > >> Sent: Monday, May 11, 2009 4:35:49 PM > >> Subject: Re: NSToolbarItem with custom view in Interface Builder 3 > >> (Leopard) > >> > >> Hey Gunnar - > >> > >> You won't be able to make this work with an instance of "custom view" > >> dragged > >> from the library. Here are a couple of suggestions for workarounds: > >> > >> You could add an outlet to the toolbar item you'd like to use a custom view > >> with, and then place the custom view at the top level of your NIB, and > >> also > add > >> an outlet to it. In awakeFromNib, you could call setView: on the toolbar > >> item > >> with the correct view. > >> > >> Alternatively, you could use a view object that wasn't a custom view. > Interface > >> Builder doesn't provide a view object in the library that isn't a specific > >> subclass or NSView, or a custom view, but you can get a hold of a plain > NSView > >> by copying and pasting one from someplace else. For example, copying a > window's > >> content view by using Interface Builder's outline view will get you a > >> vanilla > >> instance of NSView. Paste one into the top level of a document and resize > >> it > to > >> a reasonable size, and and then you can drag it from the document window > >> into > >> the toolbar. > >> > >> Good Luck - > >> Jon Hess > >> > >> On May 9, 2009, at 11:36 AM, Gunnar Proppe wrote: > >> > >>> > >>> I followed the steps described here to set up a toolbar item with a custom > >> view in Interface Builder: > >>> > >> > http://developer.apple.com/documentation/Cocoa/Conceptual/Toolbars/Articles/ToolbarInIB.html &
Re: beginner's question: having problems with saving/loading
I don't know from the information provided why your generic init is being
called, but the name of the class, AppController, is a clue to me. I'd expect a
class called AppController to have a single instance, which would control the
whole app, not to be a class that represents data in documents. My guess is
you've been following along some examples for a non-document-based app and
instantiated this in your xib based on those. You wouldn't want to do that for
document data.
Set a breakpoint on the generic init function and your initWithCoder: is the
self pointer in the debugger the same or different when you break at these
points?
For document data, you almost certainly don't want to call that class
AppController. Instead, call it what the data represents. Eg. Employee (in this
case, TestData or whatever). I suspect your trouble is in the MyDocument class
and how it manages the data object (currently AppController).
There are a few problems with your initWithCoder. It shouldn't call
initWithString. It *should* call super init (or [super initWithCoder:coder] if
the super class conforms to NSCoding, or the super classes designated
initializer if it doesn't).
Here's what I think it should look like:
-(id)initWithCoder:(NSCoder *)coder
{
if (self = [super init])
{ NSLog(@"initWithCoder is being called");
self.theString = [coder decodeObjectForKey:@"theString"];
NSLog(@"theString is %@", self.theString);
}
return self;
}
(If you don't like dot notation use setTheString.)
Some other issues with your code:
You should implement dealloc and call self.theString = nil to release theString.
Read about designated initializers:
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html#//apple_ref/doc/uid/TP30001163-CH22-SW8
Usually the longest initializer is the designated initializer. Your init method
should call initWithString with a default string value (eg. [self
initWithString:@"untitled"]).
Your initWithString is technically correct but not idiomatic. The usual pattern
is as I showed initWithCoder, above. It's best to avoid multiple return paths
in general, especially in init methods. Also, you might as well use your
synthesized setter for theString, which will do the retain for you (eg.
self.theString = aString).
Finally, you forgot to release the old theString and retain the new string in
displayString. Again, just use your nice, convenient, synthesized setter, and
it'll do that housekeeping for you. You'd then also want to remove the
willChangeValueForKey and didChangeValueForKey calls, since the setter also
does that for you.
If you don't have it, I highly, highly recommend getting a copy of Cocoa
Programming for Mac OS X by Aaron Hillegass. It's well worth the money, and
it's a lot easier to learn from than the free online documentation available.
Gunnar
- Original Message
> From: Gabriel Roth
> To: Cocoa-dev@lists.apple.com
> Sent: Monday, May 11, 2009 12:42:01 PM
> Subject: beginner's question: having problems with saving/loading
>
> In my attempt to learn Cocoa programming, I’m working on a tiny app to
> practice saving and loading files. Each document window contains a
> text field, a label, and a button. The user types a string into the
> text field and clicks the button, and the same text appears in the
> label. When the document is saved and reopened, the string that was
> saved with the document should appear in the label. Apart from saving
> and loading, the program works as I expect.
>
> The app contains just one class (besides MyDocument), called
> AppController. The code for AppController is pasted below, followed by
> console output.
>
> When loading a saved document, the application calls initWithCoder.
> This decodes the saved string and uses it in the initWithString
> method. According to log statements, the initWithString method is
> called successfully. But then the program calls the generic init
> method, which sets the string to NULL, so the label in the window
> reverts to the null placeholder set in the xib file.
>
> I don’t know what’s calling the generic init method, or how to prevent
> this from happening, or if I should be avoiding this problem some
> other way. Any explanation of this situation would be appreciated.
>
> === AppController.h ===
> #import
>
>
> @interface AppController : NSObject {
> NSString *theString;
> IBOutlet NSTextField *theInput;
> }
>
> @property (retain) NSString *theString;
> -(IBAction)displayString:(id)sender;
> -(id)initWithString:(NSString *)aString;
>
> @end
>
> === AppController.m ===
> #import "AppController.h"
>
> @implementation AppController
> @synthesize theString;
>
> -(IBAction)displayString:(id)sender
> {
> NSLog(@"displayString is being called");
> [self willChangeValueForKey:@"theString"];
> theString = [theInput stringValue];
> [self didChangeValueForKey:@"theString"];
Re: NSToolbarItem with custom view in Interface Builder 3 (Leopard)
Howdy Jon, Thanks for the tips, I'll give that a try. The first suggestion sounds close to where I was going to go, except I hadn't thought of instantiating the view in the NIB file. Great idea. Your alternative suggestion sounds interesting but I'm not sure I understand it. Would I then set the class name in the Identity pane of this pasted, plain NSView to my custom class? What's different about this plain NSView from the "custom view" dragged from the library? Is this a bug in Interface Builder, or did I misread the linked documentation? From the doc: "The procedure for adding a custom view item is very similar to that for a custom image item. (“Custom” in this context means any object from the Interface Builder library as well as instances of a custom NSView subclass.) Just drag any view object from the library onto the Allowed Toolbar Items area. Click the item once and press Command-1 to display the Attributes pane for the object as a toolbar item; click again to edit the attributes of the item as itself. You should modify the size of the custom view item in the Size pane of the inspector, not directly. If you drag a Custom View object into the allowed-items set, click it twice and set the name of the custom NSView class in the Identity pane of the inspector (Command-6)." Gunnar - Original Message ---- > From: Jonathan Hess > To: Gunnar Proppe > Cc: cocoa-dev@lists.apple.com > Sent: Monday, May 11, 2009 4:35:49 PM > Subject: Re: NSToolbarItem with custom view in Interface Builder 3 (Leopard) > > Hey Gunnar - > > You won't be able to make this work with an instance of "custom view" dragged > from the library. Here are a couple of suggestions for workarounds: > > You could add an outlet to the toolbar item you'd like to use a custom view > with, and then place the custom view at the top level of your NIB, and also > add > an outlet to it. In awakeFromNib, you could call setView: on the toolbar item > with the correct view. > > Alternatively, you could use a view object that wasn't a custom view. > Interface > Builder doesn't provide a view object in the library that isn't a specific > subclass or NSView, or a custom view, but you can get a hold of a plain > NSView > by copying and pasting one from someplace else. For example, copying a > window's > content view by using Interface Builder's outline view will get you a vanilla > instance of NSView. Paste one into the top level of a document and resize it > to > a reasonable size, and and then you can drag it from the document window into > the toolbar. > > Good Luck - > Jon Hess > > On May 9, 2009, at 11:36 AM, Gunnar Proppe wrote: > > > > > I followed the steps described here to set up a toolbar item with a custom > view in Interface Builder: > > > http://developer.apple.com/documentation/Cocoa/Conceptual/Toolbars/Articles/ToolbarInIB.html > > > > Unfortunately my custom view's drawRect is never called. I verified that it > does get initialized. The toolbar item's min and max size are set up > properly. > Just to be safe I had my view conform to NSCoding but initWithCoder and > ecodeWithCoder aren't called. I tried various springs and struts settings > with > no results. > > > > Digging deeper, I subclassed NSToolbarItem and overrode setView and > > setMinSize > so I could break on them. setMinSize is getting called with the correct > values. > Interestingly, setView gets called before my custom view is initialized. I > assume this is the proxy NSView object. Then my custom view is initialized > (initWithFrame) but the NSToolbarItem's setView isn't called again with the > new > view instance. I don't know if this is a bug -- maybe Cocoa does some voodoo > in > the swapping from the proxy NSView object to the custom view. > > > > Standard views work fine: eg. NSButton and NSBox. > > > > Has anyone successfully used IB to create toolbar items with custom views? > > > > Thanks, > > Gunnar > > > > > > > > ___ > > > > 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/jhess%40apple.com > > > > This email sent to jh...@apple.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
NSToolbarItem with custom view in Interface Builder 3 (Leopard)
I followed the steps described here to set up a toolbar item with a custom view in Interface Builder: http://developer.apple.com/documentation/Cocoa/Conceptual/Toolbars/Articles/ToolbarInIB.html Unfortunately my custom view's drawRect is never called. I verified that it does get initialized. The toolbar item's min and max size are set up properly. Just to be safe I had my view conform to NSCoding but initWithCoder and ecodeWithCoder aren't called. I tried various springs and struts settings with no results. Digging deeper, I subclassed NSToolbarItem and overrode setView and setMinSize so I could break on them. setMinSize is getting called with the correct values. Interestingly, setView gets called before my custom view is initialized. I assume this is the proxy NSView object. Then my custom view is initialized (initWithFrame) but the NSToolbarItem's setView isn't called again with the new view instance. I don't know if this is a bug -- maybe Cocoa does some voodoo in the swapping from the proxy NSView object to the custom view. Standard views work fine: eg. NSButton and NSBox. Has anyone successfully used IB to create toolbar items with custom views? Thanks, Gunnar ___ 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
