NSOpenGL Full Screen
Okay, I'm feeling a little foolish. I've been so focused on iPhone stuff for the last year and a half that I either didn't notice or just plain forgot that NSView now has a method for displaying in full screen mode. It certainly makes the whole process much easier. I've updated the old NSOpenGL Full Screen sample code to use this method. http://innerloop.biz/code/OpenGL%20Full%20Screen.zip This technique doesn't give you the zooming animation, but I'm not sure how big of a deal that is. I was able to get the zooming working by using a second window instance rather than trying to change the style mask between borderless and regular, but I never fully resolved the problem with the full screen view failing to receive key events until it was clicked the first time, but I stopped trying to figure it out once I realized there was an easier way. Because the technique of placing the window above the menu bar was specifically mentioned at a WWDC session, I've also created another updated version of the OpenGL Full Screen sample code that uses that technique to create a dedicated full-screen app (one that doesn't have the option of windowed mode). You can find the code for that version here: http://innerloop.biz/code/OpenGL%20Dedicated%20Full%20Screen.zip I've also updated the code to compile in 64-bit mode and to use properties and synthesized instance variables. I've also got the texture mapping properly. As I said before, I'm a little rusty on Cocoa, so please don't hesitate to point out improvements or problems. Cheers Jeff ___ 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
Snow Leopard OpenGL Full Screen
The traditional way of doing an OpenGL (gCGLPFAFullScreen, CGLSetFullScreen()) have been deprecated. At WWDC this year, in the Snow Leopard OpenGL session, a new all-Cocoa method was shown where you basically just resize the window containing the NSOpenGLView and layer it above the menu bar. This new method was strongly recommended because it plays more nicely with multiple contexts/screens/graphic cards. The new approach doesn't seem to have made it into the 10.6 API documentation, however, and the OpenGL fullscreen demo source is from like 2002 (ProjectBuilder project) and uses the old technique. I've taken the old NSOpenGLFullScreen sample code and am working on updating it to this new technique. I've gotten full screen working using this new Snow Leopardy approach, and it's great - nice and simple, lots less code to implement, and it's all Cocoa. What doesn't work 100% correctly, however, is zooming from a regular window to a full-screen window and back again. There are two problems with this: 1) I can't get the OpenGL view to programmatically become first responder after full screen becomes active, though it works fine once you click in the window 2) When I zoom back down from full screen, the close/zoom/minimize buttons are missing from the window. Most of the examples I've found online of zooming to full screen and back involved using two different window instances. I may try that approach if I can't get this working with a single instance. Anyway, if you want to check out my in-progress update of the full- screen sample code, it can be downloaded from: http://www.innerloop.biz/code/OpenGL%20Full%20Screen.zip If you are writing a full-screen only application, you can probably get what you need out of that And if anyone has any insight into how I can get the zoom working 100% correctly, I'd appreciate hearing it. I'll post the correct version once I get it figured out. Thanks, all. Jeff BTW: the texture loading from the original sample code is borked under Snow Leopard, probably due to one of the changes made to NSImage, I'm not too concerned about that right now, though I may look at fixing it once I get the full-screen stuff working correctly. ___ 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: Cocoa System Requirements
Every version of OS X and therefore every Mac that can run OS X can run Cocoa apps. Not necessarily any Coco app (certain features like core data or properties only became available with a specific OS release), but some version of Cocoa. I started writing Cocoa on a G3 tower, so anything you've been able to buy this milleniun is fine. Sent from my iPhone On Jul 6, 2009, at 7:45 PM, Joelle Lam j...@aptana.com wrote: Hello, Where can I find the minimum System Requirements for Cocoa. In other words, is there a Mac OS that does not provide Cocoa support (ie Mac OS Tiger on PPC)? Thanks! Joelle -- Joelle Lam j...@aptana.com Twitter: http://twitter.com/aptana Facebook: http://aptana.com/facebook ___ 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/jeff_lamarche%40mac.com This email sent to jeff_lamar...@mac.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: ***Junkmail*** How do I programaticly create a va_list
I can reinforce Bill's advice here. I tried to do this same thing once, fairly recently actually, so that I could subclass a Foundation class that had a variadic init method. I lost several hours of my time and a lot of my sanity trying to find a way to make it work before giving up. On Jan 13, 2009, at 11:48 AM, Bill Bumgarner wrote: On Jan 13, 2009, at 8:32 AM, Horst Jäger wrote: I have a problem concerning the va_list. I don't know how to programaticly create one. I need to do this because I want to use the initWithFormat method of NSString. But I neither know how many args there will be nor are the args Strings - they are selectors the associated methods of which return Strings. ... rest of excellent problem description deleted ... In short, you don't want to do this. Specifically, creating a vaargs list to be passed as a parameter to another method effectively requires encoding the arguments in whatever fashion the compiler would encode them. It is highly architecture specific and is rife with really awesomely tedious details that are easy to screw up. ___ 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: ActiveRecord on Cocoa
Here's another one to consider: http://code.google.com/p/sqlitepersistentobjects/ It's similar to ActiveRecord, but is designed to be zero- configuration. I tend to think of it as reverse-ActiveRecord because instead of populating the object based on the database table, we create the database table based on the properties. Basically, your class becomes both your class and its own migration. It's still in active development, but the basic functionality work quite well and it's very easy to set up, no configuration steps necessary, just subclass an existing class instead of NSObject, and set up Objective-C properties for everything that should be persisted, the framework will do the rest - call save, to save, use a class method to load or query. On Tue, Nov 11, 2008 at 1:52 PM, I. Savant [EMAIL PROTECTED] wrote: I'm searching for a things like ActiveRecord for Ruby in Objective-C (but I don't want to use Core-Data). Anyone can point me to the right solution? I've taken a look at http://www.cocoadev.com/index.pl?DataCrux but seems to be adbandoned. ___ 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 [EMAIL PROTECTED]
[Announce] Cocoa Barcodes is now open source and available on Google Code
I just finished checking in the source code for Barcode Generator, a Cocoa program I wrote a few years ago into Google Code as an open source project (BSD Licensed). It contains a fairly easy-to-use set of classes for generating 2D barcodes. http://code.google.com/p/cocoabarcodes/ Project Description: Cocoa Barcodes is a set of classes (and a test application) for generating two-dimensional barcodes. It supports many of the more common one-dimensional linear barcodes in use today, allows you to export a barcode as a TIFF, EPS, or PDF image, to copy the barcode image to the pasteboard, or to drag it to any other application that accepts standard OS X PDF data from the pasteboard, including TextEdit?. You can also print barcodes directly to any supported printer. Please note that you may not be able to create readable barcodes at all bar widths allowed by a specification. For example, Code 3 of 9 allows a bar width of as small as 7.5 mils, but I haven't had much luck going smaller than 13 mils on ink jet printers. You have a fair amount of control over the final appearance of the barcode, including the bar width (in 1/10 mil increments), bar height, font size, and captioning. The following barcode types are supported: Code 3 of 9 Extended Code 3 of 9 Code 128 Interleaved 2 of 5 Industrial 2 of 5 Codabar PostNet Modified Plessey Modified Plessey (hexadecimal) UPC-A UPC-E EAN-13 EAN-8 Royal Mail Barcode (also known as RM4SCC or CBC) Planet Barcode Japan Post Barcode Cocoa Barcodes is based on Barcode Generator, an open source Mac program which began its life as a test scaffold for a set of Cocoa classes I was writing. I did not initially intend to release it as a standalone program, but by the time I was done testing the code, it had the lion's share of the features available on other OS X barcode programs at the time so I decided to release it. Jeff ___ 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 [EMAIL PROTECTED]
[ANNOUNCE] SQLite Persisted Objects for Cocoa
Greetings all.
I recently created a project at Google Code that I wanted to bring to
your attention.
http://code.google.com/p/sqlitepersistentobjects/
The goal of this project is to create Objective-C data model objects
that automagically know how to persist themselves to a SQLite database
based on their Objective-C 2.0 properties without any need to write
SQL or use the SQLite3 API directly. The version of the source code
that is currently available on Google Code is a solid, functional
beta. The only major feature not currently implemented is the ability
to rollback an object to its saved state, and I'm currently working on
that. If you use it, you should expect to encounter some bugs (it's an
early beta, after all), but it should work for most purposes.
If you've ever used Ruby's ActiveRecord implementation, this is fairly
similar, except that instead of being driven by the database tables,
it's driven by the Object's properties. This allows you to build a
persistable data model without having to create a mapping as Core Data
requires. You just create your classes and all the mapping to and from
the database is done behind the scenes thanks to the superclass.
This supports storing most common object types and scalars in data
fields. It also supports collection classes (NSSet, NSArray,
NSDictionary) using cross-reference tables, and stores references to
other persisted objects as quasi-foreign-key relationships (I couldn't
use the FK constraints in the database because they are table-
specific, don't lend themselves to polymorphism, and aren't enforced
by SQLite3 anyway). It also supports adding indexes to the underlying
tables by overriding a class method.
In order to create persistable objects, you simply add the files from
this project to your Xcode project, link to sqlite3.dylib, then create
subclasses of SQLitePersistentObject, like so:
#import foundation/foundation.h
#import SQLitePersistentObject.h
@interface PersistablePerson : SQLitePersistentObject {
NSString *lastName;
NSString *firstName;
}
@property (nonatomic, retain) NSString * lastName;
@property (nonatomic, retain) NSString * firstName;
@end
Once you've done that, you can just create your objects as usual:
PersistablePerson *person = [[PersistablePerson alloc] init];
person.firstName = @Joe;
person.lastName = @Smith;
Then you can save those objects to the database (the data base and
table will be created automatically) like so:
[person save];
Loading it back in is almost as easy. All persistable object classes
gets dynamic class methods added to them to allow you to search for
instances. So, for example, you could retrieve all the
PersistablePerson objects that had a last name of Smith like so:
NSArray *people = [PersistablePerson findByLastName:@Smith]
Or, we could specify the exact criteria like this:
PeristablePerson *joeSmith = [PersistablePerson
findFirstByCriteria:@WHERE last_name = 'Smith' AND first_name = 'Joe'];
This is licensed under a very liberal license - you can use it in any
software, free or commercial, without limitation. You do NOT have to
give credit and you do NOT have to publish your changes to the source
code (although I'll certainly welcome any bug fixes or enhancements
you wish to give back). The only restriction I've placed on this
project is that if you choose to distribute the source code you must
leave the copyright and license information in the file, though you
are welcome to add additional comments if you wish.
I welcome all comments and/or feedback.
Thanks,
Jeff
___
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 [EMAIL PROTECTED]
sorting two arrays
Hey all... I've got two arrays that are related, so that object 0 in one array corresponds to object 0 in the other array. I'd like to implement a sort based on the values in one array, but to reorder both array so that the order of the two arrays stays in sync and that object x in one array continues to correspond to the same thing as object x in the other array after the sort. I've got a general idea of how to implement the sort, but since I know that there are a few places in the system where array pairs are used like this, I wanted to see if there was any out-of-the-box way of handling this scenario - I'd hate to reinvent the wheel if it's not necessary. Does anyone know if there is any easy way to do this? TIA, Jeff ___ 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 [EMAIL PROTECTED]
Did I reinvent the wheel?
Hey, folks. I needed an easy way to turn dictionaries into objects and
objects into dictionaries based on their properties. I didn't want to
have to custom code this for each of the classes i was using, and I
couldn't find that functionality in any of the existing objects, but I
have this sneaking suspicion that it's in there somewhere. I'd
obviously prefer to use the delivered version if one exists.
So, here's what I'm using now - is this a case of solving a problem
that didn't need to be solved?
code
@implementation NSObject(ToFromDict)
-(NSDictionary *)dictionaryRepresentation {
unsigned int outCount;
NSMutableArray *properties = [NSMutableArray
arrayWithCapacity:outCount];
objc_property_t *propList = class_copyPropertyList([self class],
outCount);
int i;
for (i=0; i outCount; i++)
{
objc_property_t * oneProp = propList + i;
NSString *propName = [[NSString alloc]
initWithCString:property_getName(*oneProp)];
[properties addObject:propName];
[propName release];
}
return [self dictionaryWithValuesForKeys:properties];
}
-(id)initWithDictionary:(NSDictionary *)dict {
if (self=[self init])
{
[self setValuesForKeysWithDictionary:dict];
}
return self;
}
@end
/code
Thanks.
___
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 [EMAIL PROTECTED]
Re: (no subject)
On Jun 16, 2008, at 9:27 PM, Angelo Chen wrote:
- (IBAction)doCopying:(id)sender
{
// how to determine which NSButton is clicked?
}
There are several ways. If this button was called because a button was
pushed, sender will contain a pointer to the button. You can compare
the tag values from the button, or simply compare sender to your
IBOutlet variables to see if it's the one you are expecting.
___
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 [EMAIL PROTECTED]
Accessors Question
Lately, I've started to see accessors of the following sort:
- (NSString *)foo
{
return [[foo retain] autorelease];
}
rather than just
- (NSString *)foo
{
return foo;
}
What is the purpose or benefit of doing this? It seems to me that this
would add things unnecessarily to the autorelease pool, and I can't
see a benefit to be had. I've seen it in places that make me think
there must be a reason (e.g. sample code from Apple), so I'm guessing
I'm missing something. Is there some benefit due to GC? If so, should
this construct be used without GC or only with?
Thanks,
Jeff
___
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 [EMAIL PROTECTED]
Re: Accessors Question
Out of curiosity, does anyone know what the synthesized accessors look
like when you specify retain? Are they
The safe or unsafe ones?
Sent from my iPhone
On Jun 12, 2008, at 12:02 PM, Tito Ciuro [EMAIL PROTECTED] wrote:
Hello,
Although I prefer the safer accessors, there has been one case where
I had no choice but to return the main object pointer:
- (NSString *)foo
{
return foo;
}
In my app I had a method that was populating a custom cell with a
few elements. Depending on the data source, I had to construct the
strings in different ways. Since this string had to be constructed
with up to 5 elements, when the table view had many rows,
performance suffered greatly during sort and memory consumption
spiked tremendously due to a barrage of newly allocated objects.
I ended up writing something like:
// Private version used only for performance
- (NSString *)_foo
{
return foo;
}
// Safer version used in all other cases
- (NSString *)foo
{
return [[foo retain] autorelease];
}
By using '_foo' during sorting I increased speed noticeably, while
reducing the memory footprint.
-- Tito
On 12 Jun 2008, at 11:27 AM, Jens Alfke wrote:
On 12 Jun '08, at 10:41 AM, Andy Lee wrote:
I hadn't thought of this case.
Thanks for the pointer to the docs -- I now see there is a
vulnerability in the accessors I've been writing.
This is kind of a religious issue. Some people like the safer
accessors. Some people see them as a very expensive* workaround for
a problem that rarely occurs.
I'm firmly in the latter camp. I've never used this 'safe' form of
accessor, and have only rarely run into the kind of crash it
prevents; and it was always pretty easy to track down and fix. (The
fix is just for the caller to retain the value it got from the
accessor, then release it when it's done using it.)
Another alternative is to leave the getters simple, but change the
_setter_ methods to autorelease the old value instead of releasing
it; that prevents this same crash, but is less expensive because
setters are much more rarely called than getters (and -autorelease
isn't much more expensive than -release.)
―Jens
* A basic accessor requires one or two machine instructions to do
the actual work; whereas -retain and -autorelease involve extra
method dispatches that each acquire a global lock and do a
hashtable lookup. Obviously any one call isn't going to take a
noticeable amount of time, but accessor calls are so damn
ubiquitous that this can have an overall impact on app performance
in some cases. Not to mention memory usage, since autoreleased
objects have a longer lifespan and can build up during
loops.___
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/tciuro%40mac.com
This email sent to [EMAIL PROTECTED]
___
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/jeff_lamarche%40mac.com
This email sent to [EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: Need help parsing a large text file one line at a time
On Jun 9, 2008, at 2:04 PM, Abel J. Almeida wrote: I need help parsing a large text file. I need to examine the file one line at a time. It's a 128MB text file. I used the stringWithContentsOfFile method from the NSString class, but the file is too large and it doesn't seem very optimized to me, because what I need is parse one line at a time not the entire text file.___ Check out NSFileHandle - it should handle what you need. It won't be quite a simple as using the NSString convenience class, but it's not hard: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSFileHandle_Class/Reference/Reference.html#/ /apple_ref/doc/uid/2304 ___ 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 [EMAIL PROTECTED]
RESTful Web Services PUT
I noticed that there's been some discussion of RESTful web services. I've been having problem with PUT requests using NSMutableURLRequest, one that has been asked about on the list before, but I never saw an answer or workaround posted. After some digging I found a workaround to my problem that I thought I'd share so that anyone searching the archives would find it. The problem I've been experiencing is that when making an HTTP 1.1 PUT request, my form parameters passed in the request body are not being recognized by the web service. A little digging with wireshark showed that the reason for that is that NSMutableURLRequest is not setting the Content-Type parameter for PUT requests, though it is for POST requests. This missing header causes most web services to ignore the request body. The solution is to simply add the following line of code before sending it to the server (req is the NSMutableURLRequest): [req setValue:@application/x-www-form-urlencoded forHTTPHeaderField:@Content-Type]; This issue has been submitted to Apple as problem ID 5988016, but I thought I'd put the workaround here for anyone who's experiencing the problem: ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 21, 2008, at 9:58 PM, Andy Lee wrote: There's already an inherent lower bound on the barrier to entry for Cocoa. You have to understand certain fundamentals -- some conceptual, some procedural. If you don't have those fundamentals, you'll never make Cocoa work. There is also a set of people on this planet who are trying to grasp those fundamentals and are perfectly capable of doing so. To argue that it's better for the platform if those people take a little longer to become proficient at Cocoa seems to me a bit odd. I'm not entirely sure that's exactly what is being argued, but even if it is, weird opinions can be perfectly valid. Graham stated what he intended in his recent e-mail better than I can, so there's no point in me re-hashing it. Suffice it to say, I think there is some merit to this weird idea that you should learn the culture and the conceptual underpinnings in addition to the syntax of the language and names of classes and methods if you want to succeed (and that takes time, no matter how good the documentation). If you come from a background where developers are allowed and encouraged to do things whatever way they see fit, that may seem weird, but I think in the long run, people are doing you a favor by telling you. The Mac market is different and has different expectations, and much of those expectations exist because developers (by and large) do read and understand the conceptual docs and conform to a set of conventions gleaned from them unless there's a compelling reason not to. I don't have a problem with people disagreeing with this opinion, by the way, but I DO think it's important to state that this particular opinion doesn't and shouldn't imply that people who are struggling are unwelcome. Jeff ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 21, 2008, at 3:06 AM, Scott Anguish wrote: I'm not sure that how much is being 'paid' for the documentation is a valid metric. I believe (not speaking for the company of course) that both of these areas are viewed as investments. No, you're right, it's not a good metric, and I certainly don't want you guys thinking that way. I guess my point was just that it's important for us to keep it in perspective that Apple doesn't have unlimited resources to handle the documentation tasks and that there are third-party for-pay options that can fill the gap. Also, I meant to point out that some of the comparisons that have been made in this thread are comparing free offerings to decidedly non-free ones, which isn't necessarily a fair comparison. I just think it's a good idea to keep things in perspective and try and avoid a sense of entitlement when we start discussing the way things should be. ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 21, 2008, at 4:31 AM, Torsten Curdt wrote: Well, they are free to open source XCode and have other people help. Look at Eclipse. You can suggest it to them, but I wouldn't hold your breath. :) Probably shouldn't open up that argument in this thread. Paying for documentation is a weird thought though. Apple should be happy to attract developers to have the platform flourish. That's an investment you have to make if you want to be the controlling entity of an operating system. Yeah, I know... one of the drawbacks of writing late at night - this point was not well stated. I didn't mean to imply Apple should start charging for documentation, just that we (including me) sometimes feel entitled, and I think what we've paid should be kept in mind when we start to feel entitled. I think even for the documentation user generated content could be a good way to spice it up. This worked very well for PHP for example. It would be valuable feedback for the tech writers. Just submitting bugs to the documentation is not the same. We are entering the age of user generated content. Let's not miss the boat here. Cocoadev is great - but too separate. This sounds interesting, but I'm not clear on what your comment about CocoaDev means, to be honest. The problem here, of course, is that somebody has to take the initiative to get it started and nurse it through the difficult start-up times until you get critical mass. I think face-to-face is an important part to overcome the obstacles. And this will become easier the more popular it gets. Amen. I can't tell you how much I sometimes hate having moved away from the SF Bay Area where there are many Cocoa Programmers, and there are NSCoder nights, and CocoaHeads, and other opportunities to meet other Cocoa programmers, to a place where Cocoa is only something you drink after snowmobiling. Then I remember how much bigger my house is here and how much less I paid for it and I feel a little better :) ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 21, 2008, at 9:45 AM, Steve Weller wrote: Don't you see how different the learning experience is for 100,000 iPhone developers in 2008 vs. a few hundred Next developers twenty years ago? And the differences in motivation? And background? And sponsorship? Scott, you *are* doing your best, and you are doing a great job with what you have. But I feel that there is a part of Apple that is in a state of denial, and until that changes, we're stuck with bug reports as a means of trying to change corporate vision. I think there's an assumption implicit in your argument that Apple must or should make it easier for anybody and everybody who wants to code for the Mac or the iPhone to do so quickly and easily. I'm not sure it's necessarily a valid assumption, and I'm not sure Apple is in denial of anything. Lowering the barriers to entry doesn't necessarily serve them or their consumers better, it serves new developers who see the iPhone as an opportunity but, obviously, there is no shortage of people wanting to take advantage of that opportunity, so I'm not sure why Apple would be motivated to change an approach that has worked well for them for many years. In the long run, these initial difficulties and problems, I would argue, actually keep the quality of third party software up, which seems desirable from Apple's point of view. I'm not saying your concerns aren't valid, just that yours is one perspective in a very complex equation, and possibly not as much of a factor in the big picture as you might think. ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 21, 2008, at 1:30 PM, Peter Duniho wrote: My _main_ objection is how newcomers to Mac development are treated. Please, when someone new to the current Mac development environment brings up one or more of these points, don't say well, you're too inexperienced to see why [Obj-C|Cocoa|the documentation| the tools] is/are so great. Don't say you're riff-raff, it's supposed to be hard, we _like_ that it's keeping you out. Don't say you must not have read the conceptual guides, otherwise all this would be clear. Or any of the other condescending, presumptuous things that I've seen said on a semi-regular basis Okay, first, Scott, my apologies - I'm letting the thread die after this -- promise -- but needed to respond to this one tiny point. Pete - you complain that people should treat newcomers better, yet here you are characterizing what many of us have said in a blatantly antagonistic way. Riff-raff? We like that it's keeping you out? Nobody said any such thing. It may be that people won't want to help you now, but not because you're a newcomer, but rather because you're baiting people and unfairly characterizing our words and our intentions. Don't ascribe ill-will to people who tell you things you don't agree with or don't accept as true. I guarantee you that every response was an honest attempt to help. ___ 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 [EMAIL PROTECTED]
Re: Trying to understand -- please help...
On May 21, 2008, at 3:37 PM, Johnny Lundy wrote: I submit that any experienced programmer looking up and turning to a page entitled NSArray Class Reference would expect that a behavior of the class that results in one's created object being deallocated out from under him would be documented in such a Reference. Not an experienced developer who has read and understood the conceptual guide here: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html or more specifically, the rules here: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html While it wouldn't be a bad idea for the NSArray class reference to explicitly document that it returns an autoreleased object, but in absence of explicit documentation otherwise, you should follow the simple, documented memory management rules of the language/framework you are using. If you don't know them, that is not the documentation's fault. ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 21, 2008, at 7:37 PM, Peter Duniho wrote: It's true, the phrase riff-raff wasn't actually used. But it's the essence of what was written. I don't know why it is you guys didn't notice those particular statements, and I agree that they aren't representative of the bulk of the comments. But it's not true that that sort of sentiment is never expressed. I've seen it before, and it came up rather directly in this thread. Not one single member of the community spoke out against the sentiment, which only lends it more Pete Nobody spoke up against those posts because there was nothing inappropriate about them - they were not targeted at you or any individual and they are not even remotely how you've characterized them. Hamish was making a general statement (and stating his opinion) about what he saw as the likely outcome of lowering the barriers to entry. Graham was agreeing with that opinion, again, without targeting any indvidual. About the only thing they are guilty of is disagreeing with you and, I should note, disagreeing with you on something they know a lot more about. Neither of them targeted anyone in particular and both were stating valid opinions. We allow different opinions here, and we don't assume everybody stating an opinion intends it as a vague, oblique insult to everyone who disagrees. You are taking very general statements very personally and then turning around and, generalizing and grossly mischaracterizing things that others have said, and yet you think it's just great for you to do that, but it's accusatory and insulting and unwelcoming for any of us to so much as disagree with your rants. Not everything that doesn't fit exactly with your world view is intended as an insult against you, and not everybody is going to agree with you. That's life. And, hey, here's a thought: when a whole lot of people who know a lot more about something than you do, disagree with you, it might be a good idea to take a step back and re- assess the situation because it's possible, however unlikely, that you might not be 100% right about this thing you've just started learning about. ___ 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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
This is really a fascinating discussion and, unfortunately, a time consuming one =) I can't help but feel that we have two identifiable camps forming, and I'm not sure I like that. Though a range of opinions have been stated, it seems that most of us can be readily identified as being on one side or the other of this quality of documentation debate. I'm really racking my brains to figure out why - why such a division? And I hesitate to state some of my observations because they are likely to be perceived by some as critical. Let me just say that it is not my intention to put anybody down. I'm honestly interested in helping people get over the steep learning curve, and if I say something that irks you, please take a deep breath or two before getting upset with me because I'm just trying to figure out the same thing you are, just maybe from a different perspective. Here's what I think is happening. You are welcome to disagree, if I'm wrong it wouldn't be the first time. Anyway, coming to Cocoa now is not like coming to Cocoa eight years ago when I did, or coming to NextSTEP fifteen years ago like several people on this list. Much of the conceptual underpinnings have remained constant — the same design patterns are used over and over, and there's a conceptual consistency in the Cocoa frameworks that I don't think you see in either Java or .Net. Both of those languages frameworks are more discreetly divided up and are easier to dissect into digestible pieces. Now, those of us who are comfortable with Cocoa and Objective-C don't often experience more than mild discomfort when a new framework comes out or a new OS release changes existing functionality. Usually there's one or two conceptual hurdles, and then we're back to our comfort zone. But over the years, I think Cocoa has become larger than some of us realize, and I think we have to recognize that it is more daunting now than it ever has been in the past to be a newcomer. The complexity makes it harder to form a gestalt... to get a good high-level picture of what's going on. I think it's still true that once you have that 30,000 foot view, it's really quite a nice language to work in with a lot of benefits and, yes, some weaknesses. I don't think it's possible for me, or those with even more experience using Cocoa/Objective-C to grok what it's like coming to it now, and perhaps we're a little insensitive to the plight of newcomers as a result. On the other hand, I think that at least some people coming to Cocoa right now are getting unsettled by the complexity and the fact that there are substantial differences from what they've done before, causing them to be way outside of their programming comfort zone, perhaps for the first time in many years. Maybe I'm wrong, but it looks to me like at least some people are looking to blame the documentation more than is fair. By fair, I mean a few things. First, how much are you paying for the documentation? How much did you pay for the IDE? I mean, I'd love everything to be perfect for everybody, but let's be realistic here. Apple doesn't derive any direct income from the documentation or from Xcode, and as much as we might think that shouldn't matter, Apple's a corporation, so it's going to matter. That's reality, and it's not going to change. Resources are limited, and considering the resources that are available for API documentation, I think they do a phenomenal job, and I honestly hate that some of the comments in this thread could be read as disparaging their work, even if unintentionally. Secondly, people learn differently. Not everybody learns at the same speed or in the same way. That's the challenge of any kind of education, and it's especially pronounced when you're creating searchable, hyperlinked documentation, which has all the drawbacks of written documentation, but without being able to rely on the fact that the reader is going to go through the documentation sequentially. Thirdly, who is the target audience for the documentation. As long as OS X has existed, there's been a fairly stable, slowly growing group of developers, many of whom know each other and support each other here and at things like CocoaHeads and NSCoder nights. This recent influx of new coders is quite a sudden change to the demographic. Apple can't be expected to adjust to that change instantaneously. I don't think it's even completely clear yet who's coming to the platform right now and why. To the extent that people are trying to give feedback to Apple so they know how best to proceed with future revisions to the documentation, I think this discussion is valuable, but at times we veer dangerously close to a pissing match mentality, and when that happens, I don't think it's productive (even when it's me doing it :) ) To put it bluntly, getting to a point where you truly understand
Re: Cocoa et al as HCI usability problem
Boy, I've been really refraining myself from jumping into the fray here. It's an interesting discussion which has been handled respectfully, but it seems to me that we've reached the point of diminishing returns on this. I think the lines have been drawn, and most people have chosen one side of the line or the other and I don't think there's much convincing going on. About 2-3 years ago, we had a similar discussion on this list, which got rather heated and it got kind of nasty (with some of the blame for that clearly falling on me), but since that argument I've been primarily a lurker here, and have become a little gunshy about issues like this. Nonetheless, I feel a need to put in a few comments. Before I do that, I'll throw my bias up front - I think Apple, for the most part, is doing an excellent job on the documentation. There is room for improvement in places, but given the enormity of the job and the target audience, I think they're doing great. I rarely have problems I can't get an answer to either in the documentation or, when that fails, from one of the helpful people here or one of the blogs maintained by one of the people here. I think what we are seeing is a combination of cultural and technological (or, perhaps, architectural) differences coming to the surface thanks to the influx of new programmers to our platform. Unlike many of the Cocoa developers on this list, I have one foot squarely in the other world - a good chunk of my income comes from large corporate (think Fortune 100) clients, and I work regularly in a number of language and on a number of platforms including .Net and Java. I think this gives me closer to an objective view of the situation than most, though I clearly still have my biases. In many ways, Cocoa/Obj-C is an oddity, and certainly the approaches that Microsoft, Sun, and Apple have taken with their development tools is different. Microsoft has architected .NET, especially (but not only) Visual Basic, to lower the bar for learning the most common and most basic tasks by hiding some of the complexity involved. They market heavily to large corporate and governmental entities that you don't need experienced programmers, you can just send someone out to certification and they'll be able to write whatever you need. They push the ROI of doing that, since a junior tech makes less than an experienced programmer. I'm not making this up, their Enterprise salesforce uses this type of argument excessively with large corporate clients: Because .Net is eaiser, they argue, it's cheaper. And it's true, that to design a very simple application in VB or C# is phenomenally easy, but there are tradeoffs. They've changed the shape of the curve, but not the amount of work it takes to become truly proficient, and I've made a lot of money over the years cleaning up (or rewriting) programs written by people with little or no experience other than a certification class. No matter what salespeople will tell you, you can't remove the requirement of experience to become a truly competent programmer, but you can make a programmer who hasn't gained that competence unaware of their ignorance. I would argue that that is one side-effect of Microsoft's approach. That combined with the fact that the sheer number of .Net programmers out there means that almost any specific task you need to do has been done by somebody else, so with some decent Google skills, you can avoid learning to do the hard stuff for quite some time since you can probably find a blog post or code sample somewhere instead of writing your own code. With Cocoa, there's a bunch of hard stuff right up front that you can't avoid. I found that it took a while to get it when I first came to the platform. I was primarily a C, C++, and Java programmer, and I very quickly understood the steps to do basic things, but I didn't always understand why I was doing it. Then, after a few months of pretty regular use, I had this aha! moment and it literally all fell in place, my brain formed a gestalt from all the various pieces I had been playing with. In that one moment, Cocoa went from being hard to being the easiest platform I knew... it was like getting to the top of a hill, and then getting to ride a bicycle down the other side. It's a steeper mountain (learning curve), and it seems much harder until you reach the top, but it's much easier as come down the other side. Probably a silly metaphor, but it feels right to me. Now, I need to say this, because people often misinterpret comments like the ones I've just made: I'm NOT bashing .NET. I'm just stating that the architects have taken a different approach in the construction of the language and libraries, and that there are consequences to that approach. There are phenomenal .Net programmers out there. But, Cocoa is NOT .NET and it's NOT Java, and some of
Re: Cocoa et al as HCI usability problem
On May 19, 2008, at 1:33 PM, Peter Duniho wrote:
NSColor color
{
set
{
undoManager.prepareWithInvocationTarget(this).color =
mColor;
mColor = value;
}
}
Are you sure about this? I'm just a little surprised to see that C#
API has an UndoManager with exactly the same syntax as Cocoa. Or were
you just demonstrating the syntax similarities between C and C#?
___
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 [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
On May 19, 2008, at 1:42 PM, Peter Duniho wrote: I agree with this statement. However, the conclusion is flawed. You are welcome to your opinion, even if flawed ;) Seriously, though, from some of your comments, I'm not sure that I communicated my conclusion very well, because you seem to think I was putting .Net down as somehow inferior to Cocoa. I tried to be careful not to say that because I don't think it's true and even if I did, it wouldn't have been relevant to the discussion that was going on. I do like Cocoa better, which I readily admit, but the two frameworks have different guiding principles and that causes each one to have different strengths and weaknesses. I picked out one specific weakness in the .Net approach because it seemed relevant to the discussion at hand and because I hoped it might help people coming from that background to adjust to a different way of learning and understand WHY they were having a hard time learning. I wasn't saying .Net is flawed, Cocoa is perfect or anything of the sort, I just didn't feel that a laundry list of shortcomings of the two frameworks was relevant to the discussion at hand and wouldn't have helped to get my point across. And my point was simply, Cocoa is different, which was in response to a lot of complaints on the list lately which seemed to me motivated by people making judgments or having expectations based on assumptions that aren't valid when dealing with Cocoa. I originally started addressing your specific points, but after re- reading my responses, I just don't think it's productive to argue the mertis of the two environments here, so I deleted it. The two frameworks are different, on that we can agree, I think. We both have worked with both of them, you like one better, I like the other. I'm not interested in proving to you that Cocoa is better, I'm only trying to help people coming from .Net to Cocoa see that the differences between the two go deeper than method and class names. There are fundamental conceptual differences in the way they are built and documented and clinging to what they know from one can be an obstacles to learning the other. ___ 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 [EMAIL PROTECTED]
Re: Delegates
On May 19, 2008, at 5:00 PM, john darnell wrote: yeah, I know...I'm dating myself with the use of the word grok Huh? You're not dating anything. :P I think grok gets used on this list at least a few times a week. Grok is part of the geek lexicon, even among people who have no idea where it comes from ___ 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 [EMAIL PROTECTED]
Re: The challenge for Cocoa's on-line documentation
On May 17, 2008, at 4:16 PM, Johnny Lundy wrote: I never had any problem with a language's documentation since 1970 with the IBM 360 Reference Manual. That is, until I came across Apple's documentation of Cocoa. I have never been so frustrated in my life. snip The usual pattern for a User Guide Reference Manual is for the User Guide to have chapters corresponding to the areas of the product, and the Reference Manual having a page or so listing all the details of each element. The Apple docs have neither. snip - tag Returns the tag. See also : setTag I do not know where documentation you saw this, but Apple's documentation for NSControl states the following in the method description for tag: Tags allow you to identify particular controls. Tag values are not used internally; they are only changed by external invocations of setTag:. You typically set tag values in Interface Builder and use them at runtime in your application. When you set the tag of a control with a single cell in Interface Builder, it sets the tags of both the control and the cell to the same value as a convenience. That seems pretty darn clear and concise to me. It says something equally clear in setTag: Besides, tags are a fundamental concept in Cocoa. If you don't know what tags are, maybe the API isn't the right place for you to be spending your time right now. I'm sure most of us here don't want to read through a description of what tags are every single time they're mentioned in the documentation. Jeff ___ 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 [EMAIL PROTECTED]
Re: Guidance for Cocoa's steep learning curve
On May 16, 2008, at 9:30 AM, john darnell wrote: I don't mean to be mean, but I agree with Joseph; most Apple documentation is really, really poor. *No, that's not correct.* The documentation is extensive, and comprehensive, but unless you already know what you are reading about, it might as well have been written in Farsi (no offense meant to any who speak Farsi--and if Farsi is your first language, then substitute English for Farsi). I'm curious what you're actually looking for in documentation; what you think Apple or Microsoft could do to make them better, because I'm having trouble accepting this premise and it seems to me that what you want is simply unrealistic. If they were able to make documentation that made you happy, my guess is that the most of us would hate it, because we'd have to slog through fundamental conceptual information in places where it doesn't belong. I am not as familiar with Microsoft's documentation, but my limited experience with it has been fairly positive (as much as I hate to say anything good about Microsoft ;) ) and I find the Apple documentation to be excellent. There have been times where the documentation has lagged behind development and caused some difficulties for developers, especially in the early days of OS X, but overall, I think we are spoiled by the amount of information we have available to us. Personally, I think that the Object-Oriented Programming with Objective-C book on the developer website, which isn't all that changed from the NeXT days, contains one of the clearest explanations of the concepts underlying object-oriented programming that I've seen anywhere, and it is right where it belongs - that type of conceptual material doesn't belong in the API documentation. Hand-holding guides exist; they're called books. Apple even offers several guides to conceptual information, but they are separate from the API documentation. Although I think a reasonably intelligent person could learn everything they needed to know from Apple's official documentation without using other books, those other books clearly exist for a reason, which is to shorten the learning curve a bit and gather up a lot of disparate information into one place. Like I. Savant, my educational background is not in programming, and I am pretty much self taught, so believe me, I understand the challenges of learning this stuff. You have to acquire the foundational knowledge, either from the Apple documentation, or from third-party books. You can't just expect to look at tiny pieces of the puzzle like the API documentation of a class and expect to magically get the big picture from it. Documentation isn't magic. It can't be all things to all people. Considering the complexity and the target audience, I'd say that Apple's documentation is, frankly, stellar. Yes, often understanding one part will require you to do some research to understand a term or concept from another part of the system, or to sit down for a few hours and experiment, or maybe even ask a few questions here. If it could be made so simple that none of that was necessary (without sacrificing functionality), most of the people on this list would be out of a job or, at least, making less money. Too many people assume programming is (or should be) easier than it really is. ___ 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 [EMAIL PROTECTED]
Re: Working through a problem...
On May 16, 2008, at 4:55 PM, john darnell wrote: I am attempting to follow these instructions, but whenever I do, when the cursor hovers over the table view control on the dialog the label that shows is NSTableColumn, and in the info panel the connected button remains grayed out and the message tableView must be of type NSTableView appears on the panel. How do I get IB to select the tableView instead of the columnView? Well, I don't have the current version of this book, but one trick that can help is to change the nib window to hierarchical view, and then expand the tree out until you can see the tableView that you want to connect to, then control-drag to that instead of the table on the column. That's probably the easiest way to get to one item in a nested hierarchy such as you have with the table views. ___ 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 [EMAIL PROTECTED]
Re: Subject: Re: Bypassing Interface Builder
On May 15, 2008, at 1:23 PM, Erik Buck wrote: Dragging any object from a palette (what does IB call palettes these days?) i It's called the Library... ___ 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 [EMAIL PROTECTED]
Re: ANN: CDBStore, a lightweight persistent dictionary
On May 2, 2008, at 9:07 PM, Jens Alfke wrote: CDBStore is a kind of middle ground between simple property-lists or archived objects, and CoreData. There's a very large empty space there, and I kept getting annoyed by having to cobble together yet another bit of code to read and write a dictionary from a file. And I'm not the only one, as evidenced by this message: This is very cool, Jens. I'm looking forward to trying this out. I actually started working on a little different approach to that middle ground you talk about yesterday. What I've done, although it's not production ready yet, is to use some of Objective-C's runtime functions to create a class that if you subclass it, all the properties you declare are automatically saved to a SQLite database. It's implemented as just a single class and a single-method protocol that your application delegate needs to conform to (a method that opens and returns the database). It dynamically generates the SQL to create, delete, insert, and update the database based on the declared properties, so you don't have to write any code and don't have to create a mapping file, or do anything else. It even handles foreign key associations for instance variables that are also subclasses of this class, and uses cross reference tables to store arrays and dictionaries that contain objects that are subclasses. It's similar to the Ruby ActiveRecord implementation, except for being object-driven rather than table driven. I think the concept has a lot of potential, but I've got quite a bit of work to do before I'm comfortable publishing it for others to see. Your solution might work for me, though, and save me some work. :) ___ 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 [EMAIL PROTECTED]
Re: Complex data for webservices
When I try to access your WSDL, I get: Server Error in '/DummyWS' Application. Generally, though, I don't believe the response from a web service is a dictionary - I believe it's usually a string and I'm wondering why you are sending an empty dictionary - it would seem like nil would be a better choice if you want to send without any data. Also, you are leaking memory there since your code will never release the dictionary you allocated in the first line of your method. You need to either release or autorelease when you are done with the dictionary - the stubs will retain it if they need to. Let's see, what else... You say there is some network activity, so why don't you try using tcpdump to see what is being passed back and forth. It would be something like this in a terminal window: sudo tcpdump -s 0 -v -A -i en1 port 80 Changing en1 to the adaptor you're using. Then run your script and you should see what communication with the web service. It's a good idea to close all your Safari windows so that no extraneous AJAX requests get sent by Safari during your run, or you can use Ethereal ( http://www.ethereal.com/ ), which lets you filter by application. It should become pretty obvious from the communication what your stubs are doing with the argument you give it, and what the response is. HTH Jeff On Apr 23, 2008, at 8:41 AM, Niklas Saers wrote: Hi Jeff, and thanks for answering :-) On Apr 21, 2008, at 3:30 PM, Jeff LaMarche wrote: I'm no expert on Web Services on Objective-C, but I've been playing around with them a bit. One thing that I have discovered is that CFTypeRef is not _always_ a dictionary. In some cases, it wants a string. Thanks for the tip! :-) Without knowing what your web service looks like I don't think I can be any more helpful than that. Have you used the debugger to step through the setParameters: method while it's running? You might be able to tell what it's looking for by doing that. That was how I figured out to pass in a space delimited list as an NSString rather than a dictionary. I've made a dummy webservice that looks pretty much like the one I use: http://78.157.102.46:2234/DummyWS/Service1.asmx?WSDL So to generate my stubs I do: WSMakeStubs -x ObjC -name DummyStubs - url http://78.157.102.46:2234/DummyWS/Service1.asmx?WSDL First of all, it generates the functions twice, so I need to delete half of them. :-I It also gives me five warnings saying warning: initialization discards qualifiers from pointer target type, but at least now I'm good to go. Then I make my method: NSString *testStr = (NSString*) [myService testString:[[NSDictionary alloc] init]]; NSLog(@testStr: %@, testStr); NSDictionary *testDict = (NSDictionary*) [myService testString: [[NSDictionary alloc] init]]; NSLog(@testDict count: %d, [testDict count]); When the method is called, there's a bit network activity, but the log sais: Apr 23 14:38:59 MBP SampleApp[1742]: testStr: (null) Apr 23 14:38:59 MBP SampleApp[1742]: testDict count: 0 Cheers Nik ___ 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 [EMAIL PROTECTED]
Re: Complex data for webservices
Niklas:
I'm no expert on Web Services on Objective-C, but I've been playing
around with them a bit. One thing that I have discovered is that
CFTypeRef is not _always_ a dictionary. In some cases, it wants a
string. For example, if you run WSMakeStubs on the National Weather
Service's WSDL :
http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Several of the CFRefType arguments in the class methods actually need
to be specified as NSStrings not as NSDictionary instances, something
I only discovered after a lot of failed attempts to use it.
Unfortunately, the documentation for WSMakeStubs and the web services
part of CoreServices, AFAIK, doesn't give detailed information on how
to know when CFRefType refers to a dictionary and when it's something
else like an NSString in your generated stubs.
Without knowing what your web service looks like I don't think I can
be any more helpful than that. Have you used the debugger to step
through the setParameters: method while it's running? You might be
able to tell what it's looking for by doing that. That was how I
figured out to pass in a space delimited list as an NSString rather
than a dictionary.
Sorry I can't be more helpful,
Jeff
On Apr 21, 2008, at 8:15 AM, Niklas Saers wrote:
Just a short PS
On Apr 21, 2008, at 1:45 PM, Niklas Saers wrote:
TestAuthentication *WS = [[TestAuthentication alloc] init];
[WS setParameters:param];
NSLog(@isComplete == %d, isFault == %d, true == %d, [WS
isComplete], [WS isFault], YES);
I hadn't noticed that static functions were also present in the
stubs, so I tried them but got the same results. I added a NSLog
there as well, and got the same result:
+ (id) TestAuthentication:(CFTypeRef) in_parameters
{
id result = NULL;
TestAuthentication* _invocation = [[TestAuthentication alloc]
init];
[_invocation setParameters: in_parameters];
result = [[_invocation resultValue] retain];
NSLog(@debug: isComplete: %d, isFault: %d, true: %d,
[_invocation isComplete], [_invocation isFault], YES);
[_invocation release];
return result;
}
output: debug: isComplete: 1, isFault: 1, true: 1
To decouple this from the complex types, I wrote a little webservice
in C# for MS-IIS called testInt that I've verified with SOAP Client
from Scandalous Software that behaves correctly:
[WebMethod]
int testInt() {
return 5;
}
that returns
soap:Envelopexmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:xsi=http://www.w3.org/2001/XMLSchema
instancexmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
-soap:Body
-testIntResponse xmlns=webservices.mydomain.com/myService
-testIntResult-5/testIntResult
/testIntResponse
/soap:Body
/soap:Envelope
Again I added debug info to the code:
+ (id) testInt:(CFTypeRef) in_parameters
{
id result = NULL;
testInt* _invocation = [[testInt alloc] init];
[_invocation setParameters: in_parameters];
result = [[_invocation resultValue] retain];
NSLog(@debug: isComplete: %d, isFault: %d, true: %d, [_invocation
isComplete], [_invocation isFault], YES);
[_invocation release];
return result;
}
and again it failed: debug: isComplete: 1, isFault: 1, true: 1
My call in this case was:
[Service1Service testInt:[[NSDictionary alloc] init]];
That is, an empty dictionary, so no parameters. I tried passing nil,
but then it just crashed
For the authentication I called:
NSDictionary *serviceDict = (NSDictionary*) [myServiceService
TestAuthentication:param];
NSLog(@Entries: %d, [serviceDict count]);
and I got: Entries: 0
So either way isFault returns YES, and either way I get an empty
NSDictionary back. Why is this, and how do I get it to return
correctly? (you'd think it'd be easy enough calling an int
function() ;-) )
Cheers
Nik
___
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/jeff_lamarche%40mac.com
This email sent to [EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: is this badly written code?
On Apr 14, 2008, at 10:53 PM, Adam Gerson wrote: In cocoa its very tempting to write a single line of code like: NSManagedObject *selectedTreeObject = [self delegate] mainWindowController] treeController] selectedObjects] objectAtIndex:0]; or to flush it out in to individual lines: NSWindowController *mainWindow = [[self delegate] mainWindowController]; NSTreeController *treeController = [mainWindow treeController]; NSArray *selectedTreeObjects = [treeController selectedObjects]; NSManagedObject *selectedTreeObject = [selectedTreeObjects objectAtIndex:0]; I'm not sure that you're going to find 100% agreement on this topic. I can tell you what I do, but I suspect there's a fair amount of personal preference in this. When I first started writing Objective-C, well, at least once I really started to grok the language, I got into the habit of doing crazy nesting like your first example. Well, maybe not quite that crazy, but still fairly crazy ;) Then I started writing articles on Cocoa for MacTech magazine, and because the series was intended as an introduction to Cocoa for people unfamiliar with Objective-C (basically Carbon / Mac Toolbox programmers), I needed to make the code as clear and easy to understand as possible, so I started writing my code for the articles more like your second example to avoid confusion and there's no doubt the code was easier to read. Nowadays, my style is probably somewhere between your two examples, and I'm sure I'm not completely consistent about it. There are times when it makes sense to nest calls, times when it can cause you problems, and a great many situations where it probably just doesn't matter. I almost never, for example, break out calls to alloc and init into two lines. Sometimes I'll even throw in an autorelease (if appropriate, of course) right on the line. When grabbing a reference to a singleton, I'll typically nest the call to the accessor (e.g. [NSFileHandle defaultFileHandle] in another call unless I'm going to be making many calls on the singleton object. With few exceptions (such as the alloc/init/autorelease and some building of NSString using formats, I don't usually nest more than two message calls. But, as I said, I'm not 100% consistent. I just do what feels right to me and sometimes I'll write it one way and then change it later. As a practical matter, all that your first example really gets you is some vertical space on the page and possibly a meaningless amount of memory to hold a few pointers (I'm not even sure about that - I don't know much about compiler optimizations on modern processors, it could be those chunks of code compile to the exact same end result but even if not, a few pointers on a modern machine is meaningless). The downside to the first example is that it makes the code harder to read and can be much, much harder to debug. When you set a breakpoint at that line of code, for example, it will appear to stay at the same line through several instructions as you step through your code, and if it breaks during one of those nested calls, you'll have a harder time discerning which command it was on when it broke than if they were broken out. I'd say, it's best to follow Wil's advice on this one (Shakespeare, not Shipley, although the latter probably has an opinion on the matter) - and be true to thine own self. Or, would that be YES to tine own self? Sorry, didn't get much sleep last night. I'll shut up now. Peace, Jeff ___ 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 [EMAIL PROTECTED]
Re: is this badly written code?
On Apr 15, 2008, at 10:25 AM, john darnell wrote:
4.) Comment verbosely and often. You may understand now what you are
doing and why, but six months from now, you won't. Don't fool
yourself
by saying I'll add comments later, because, trust me, later never
comes.
I'm not going to argue with you because I think you've given some
pretty good advice here. I'm a fan of white space in my code as well,
and though there are some stylistic differences between us, I concur
with the basic concepts you laid out. I just thought a caveat might
be in order on #4 quoted above. And that caveat is simply don't
overdo it. Comments are good and necessary, and should be done
contemporaneously with coding, on all that I agree completely. But it
can also be frustrating to have to deal with code like the following
hypothetical example (okay, this is may be a bit of an exaggeration,
but I've seen comments not that different from this out of young, well-
meaning programmers who take the comment copiously advice a bit too
seriously):
// This is a loop. It loops through the values in an NSArray
// called myArray. i is the loop variable, which we set
// to zero because arrays are zero-indexed in Obj-c
// we loop until i is less than [myArray count] because
// it is zero-indexed and going past the last item in the
// array will generate an exception. If I had used =
// instead of then we would have iterated past the
// last item in the array. I like puppies, but they can't code.
int i;
NSString *myString
for (i = 0; i [myArray count]; i++)
{
myString = [myArray objectAtIndex:i];
NSLog(@OMG, [EMAIL PROTECTED], myString);
}
// Now that I've looped through my array using a for loop, I will
// ...etc. etc.
I think I would add to the end of your rule, but don't waste time
writing comments to explain what should be obvious to any competent
programmer. Comments are to elucidate what shouldn't be clear.
Unless, of course your code is intended as a teaching tool. In most
cases, if your comment length exceeds your code length by a
significant amount, you might want to step back and ask yourself if
it's all necessary.
___
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 [EMAIL PROTECTED]
Re: Subclassing NSArrayController
On Apr 14, 2008, at 11:53 PM, antikraft clover wrote: If I am subclassing NSArrayController to provide and update an array of objects, which methods do I need to implement ? What are you trying to accomplish. The only time that I regularly subclass NSArrayController is to implement drag and drop. In most cases, you can just use the NSArrayController out-of-the-box and run with it. ___ 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 [EMAIL PROTECTED]
Re: to write to file except NSData*
On Apr 15, 2008, at 10:38 AM, Nick Rogers wrote: Hi, I am creating a file with: NSFileManager *fileManager = [NSFileManager defaultManager]; [fileManager createFileAtPath:path contents:nil attributes:nil]; === then I got a fileHandle as: NSFileHandle *fileHandle = [NSFileHandle fileHandleForWritingAtPath:path]; === NSFileHandle has the method: - (void)writeData:(NSData *)data = but i want to write the length of (NSData *)data, before I write it to file because I will be writing a lot of NSData to the file, so that I will be able to read the length first and then read the following NSData. SO how can I write the length which is an integer to file before I write the NSData. How is your length stored? Is it a short, or an int or an NSUInteger? One way I think you could tackle this would be to create an NSData that contains the length, write that first, then use: [fileHandle truncateFileAtOffset:[aFileHandle seekToEndOfFile]]; which sets the file handle to write at the end of the file - basically to append data, then use writeData: as you said. But there's a caveat here - we currently have both big-endian and little-endian Macs running OS X and NSData doesn't deal with endianness automatically - that's our responsibility. There are ways to convert, such as the byte ordering functions documented here: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html or you could also store the length as a string: NSString *lengthString = [NSString stringWithFormat:@%d, theLength]; NSFileManager *fileManager = [NSFileManager defaultManager]; [fileManager createFileAtPath:path contents:nil attributes:nil]; NSFileHandle *fileHandle = [NSFileHandle fileHandleForWritingAtPath:path[; [fileHandle writeData:[lengthString dataUsingEncoding:NSUTF8StringEncoding]]; [fileHandle truncateFileAtOffset:[fileHandle seekToEndOfFile]]; [fileHandle writeData:myActualNSDataObject]; etc. HTH. This is untested code typed in e-mail, so I suspect there are errors, but hopefully it will point you in the right direction. Jeff ___ 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 [EMAIL PROTECTED]
Re: what is the proper place to store application settings
I'm assuming that these will change, but should not be changed by the user, correct? It seems to me that you'd want to avoid compiling them into your classes using #define, I think a property list included as bundle resource is the way to go. http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/PropertyLists.html On Apr 9, 2008, at 2:19 PM, Laimonas Simutis wrote: I started programming with Cocoa recently. Created an application which makes REST calls and displays the response values in a simple window. For each particular REST function I have a corresponding class which defines functionality for constructing a proper URL needed to call a function, initiating the call and informing the interested delegate object once the REST response is received. Right now I have the host part of the url hardcoded in each class that represents a different REST function call. I know I should store it in one place, not sure what's the recommended place in cocoa apps. I was thinking maybe one class with #defines and then all the REST representing classes would include that? Also I see some docs mentioning plist setting files, could that be a better place? Based on my environment (debug, testing, prod) this url will change as well. Thanks for any recommendations, ___ 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 [EMAIL PROTECTED]
Re: core data and sqlite db store problem
Core data stores metadata as well as data in the sqlite3 file and
follows a very specific naming convention for the regular data tables
and columns. You'd probably be better off writing a small migration
utility to import the data you need than to try create a sqlite3
database in the right format. Also, if you use this mechanism, when
you distribute your app, none of that data will go with it.
Why don't you move out your sqlite3 file and let it create a new one,
then go in and look at the tables and structure, and you'll get an
idea of what I'm talking about.
HTH
Jeff
On Mar 31, 2008, at 12:45 PM, Scott Guyer wrote:
Hi,
I'm just learning core data and have already stumbled on
something. I created a CD application using the XCode template.
I've created a sqlite3 .db file with data and a matching core data
model in xcode. My code fails here...
url = [NSURL fileURLWithPath: [applicationSupportFolder
stringByAppendingPathComponent: @my.db]];
persistentStoreCoordinator = [[NSPersistentStoreCoordinator
alloc] initWithManagedObjectModel: [self managedObjectModel]];
if (![persistentStoreCoordinator
addPersistentStoreWithType:NSSQLiteStoreType configuration:nil
URL:url options:nil error:error]){
[[NSApplication sharedApplication] presentError:error];
}
with an error saying that the db file cannot be opened because it is
not in the right format. The file might be corrupted, truncated,
or in a different format than you expect. That's quite odd to me,
since I can interact with that db file on the command line using
sqlite3 just fine. Anyone have any ideas/suggestions?
Much appreciated!
___
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/jeff_lamarche%40mac.com
This email sent to [EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: Threads and Core Data, bindings results in view corruption
David: I can't speak for Apple (I'll leave that to Ben), but there are a few things to keep in mind here: 1) Core Data is still a relatively new technology. Sure, it came out with Tiger, but since using it keeps your app from running on earlier versions of OS X, a lot of software projects never adopted its use. When using traditional objective-C persistence (e.g. NSCoder) a lot of these issues don't exist, so until we hit critical mass of developers using Core Data in their apps, a lot of these issues will persist (especially if we don't file enhancement requests, as Ben pointed out, something I am admittedly guilty of) 2) Core Data, although relatively new, borrowed a lot conceptually from EOF, which was part of WebObjects, a web application framework. A lot of the concurrency issues we're talking about didn't exist in WebObjects because the UI was all rendered through HTML. The stateless nature of HTTP connections and the types of tasks you do in web apps rendered it mostly a non-issue. 3) Often, there are other ways to deal with UI responsiveness other than threads. Sure, it's the first thing that jumps to mind (at least for me), but two other possibilities that I can think of are timers and run loop callbacks like those used in CFNetwork. In fact, that's how I got around the problem in my app - I simply buffer and process chunks of data in a callback method the way CFFoundation does. Doing that, I lose the performance benefits of threads, but I didn't need that anyway, and my code is much easier to debug and maintain. 4) You can, as Ben mentioned, use performSelector:onMainThread: to actually have the object inserted on the main thread's context. It's a bit of a pain, but threads are always at least a little painful. Just my 2¢... Like you, I'd still like to see Core Data become fully thread-safe, but you can't always have what you want when you want it. Jeff On Mar 31, 2008, at 1:49 PM, David wrote: Thank you very much for the response which is chock full of helpful information. Its taken me some time to try and digest. I must admit being a little demoralized. I've always considered threading to go hand and hand with GUI programming. I'm having trouble envisioning the scenarios where bindings and core data are intended to be used without threads. I'm relatively new to Cocoa. From my previous work in win32 and Java this is the normal scenario, not an unusual one. Can someone point me to some sample code that illustrates how to have a worker thread updating data which is displayed in the UI? In my case I am/was trying to maintain a outline view representing files, storing each node in core data. Based on these responses I'm not sure what technologies I should reasonably be using. Is this too fine grained for Core Data? Should I give up on bindings? Should I give up on NSTreeController? If I try to maintain multiple MOCs, that means I have to save to get it to show up in the other moc, right? The save as binary file can take 15 seconds in my case when I have thousands of nodes. That hangs the UI longer than adding the nodes to start with. Should I try to use a in memory persistent store or will that still be slow or cause an excessive memory penalty? Additional comments below: On Sun, Mar 30, 2008 at 9:50 PM, Ben Trumbull [EMAIL PROTECTED] wrote: If you want multi-threaded work with the view and controller classes in Cocoa, you'll need to perform your background operations, and communicate back to the main thread (view controllers) via the run loop. -performSelectorOnMainThread and its friends in NSThread.h are your best bet. Using a run loop on a background thread and communicating from the main thread to it with the new 10.5 -performSelector... methods is often conceptually simpler (easier to debug) than many other threading patterns. Sharing a MOC with Cocoa Bindings and a background thread will end in tears. Cocoa Bindings doesn't lock its bound MOC, so you're basically SOL. Can I ask why don't bindings lock the bound MOC or provide the option to? I had assumed (incorrectly) that bindings would handle threads OR provide some means to control or configure its threading behavior. Even if it did work, though, it'd be a bad idea. Sharing a MOC means a background thread would still at times block the main thread and SPOB your app. Why doesn't core data support locking at a finer grain? Or to rephrase, it would be very helpful if Core Data could lock at a ManagedObject level. I expected there to be a locking or transaction mode where I can lock it while I fill in an object. Nothing else should require me to worry about core data getting corrupted with multiple threads. These 3 points (can't work, doesn't work, shouldn't work) are why the Core Data Programming Guide says don't do this. The Core Data programming guide in the threading section guidelines states: 3) Pass
Re: Threads and Core Data, bindings results in view corruption
On Mar 31, 2008, at 2:36 PM, David wrote: On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche [EMAIL PROTECTED] wrote: 4) You can, as Ben mentioned, use performSelector:onMainThread: to actually have the object inserted on the main thread's context. It's a bit of a pain, but threads are always at least a little painful. How? Core data says that to use NSManagedObjects between threads you need to pass an ID and access it from another context. But you don't even get an ID until you perform a save on the original context. I'm then back to my original problem where the save itself takes too long. From what I've read so far, my current thinking is that I need to give up on Core data. I can easily create my own objects, handle my own locking or synchronization. I was thinking to still use NSTreeController bound to my objects. Its a shame because core data sounds so cool. I love the data modeling aspects. Nice way to think through the problem even if I end up not using it. Well, I don't know exactly what you're doing in your thread, but you could create a method that that took, for example, a dictionary as an argument, then when you're ready to insert the object in your thread, pass that method the values you need having it fire on the main thread and then create the Core Data entity based on the passed values and then insert it into the main thread's context. If you needed to do further work on that entity, like adding relationships to it, then it would get to be trickier, as you'd also need to get its managedObjectID back to your thread. I'm almost certain it's POSSIBLE to do what you want with Core Data, but it's also altogether possible that it would be easier or more efficient to go with traditional Obj-c persistence. Sorry that I've got no magic bullet for you. :-/ Jeff ___ 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 [EMAIL PROTECTED]
NSFileHandle / NSConcreteFileHandle problem
I'm having an unusual problem with an NSFileHandle. I'm creating an NSFileHandle and initializing it with a file descriptor that's actually a network socket. I'm able to send and receive data using it and it works fine. Then, I pass the NSFileHandle instance as the first argument of an NSInvocation call [invocation setArgument:fh atIndex:2]; When I invoke the invocation, it calls my method with the file handle as the first argument, exactly as it's supposed to, BUT, the file handle doesn't work. I get the following message in the console when my code tries to actually use it: *** +[NSConcreteFileHandle writeData:]: unrecognized selector sent to class 0xa014ba80 The weird thing is, if I call: [invocation target] performSelector:[invocation selector] withObject:fh]; it works just fine. Does anyone have any idea what might be going on here? I've tried creating a new NSFileHandle and initializing it with the descriptor taken from the first argument, and I get the same result doing that. I'm able to work around the problem, but I'd still like to know if I'm doing something wrong. TIA for any help anyone can offer. Jeff ___ 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 [EMAIL PROTECTED]
Re: NSFileHandle / NSConcreteFileHandle problem
On Mar 30, 2008, at 3:30 PM, Jeff LaMarche wrote: [invocation target] performSelector:[invocation selector] withObject:fh]; Actually, that would be: [[invocation target] performSelector:[invocation selector] withObject:con]; missed a bracket when I copied and pasted :) ___ 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 [EMAIL PROTECTED]
Re: Threads and Core Data, bindings results in view corruption
Dave: Are you using separate managed object contexts for each thread? According to the documentation here: http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdMultiThreading.html That's the way to do it - pass managed object IDs between threads, not managed objects, and when you're done, you can call refreshObject:mergeChanges: on the main thread's context with the objects that were changed, then call processPendingChanges on it. With regards to getting the tree controller to update, though, I've had the same problem - I can't get the tree controller to recognize the changes made in the other thread, even though those changes are saved successfully and I tell the main thread's context about them. They do show up the next time I launch the app. I'm actually in the process of rewriting my app to avoid threads in a few places because of this problem (and because it's the right thing to do based on Jens' advice given to somebody else earlier today). If you do figure out the tree controller issue, though, I'd love to know how you got it to work. I've posted the question twice now to this list - once about two years ago, and another time today with no luck. :( Take care, Jeff On Mar 29, 2008, at 11:30 PM, David wrote: I would think this is the normal typical case, but can't figure it out. The UI should run on one thread, another thread should be used for time consuming updates/generation of an object tree maintained using Core Data. I have a NSOutlineView (via NSTreeController subclass) which displays the object tree from Core data. I can not figure out how to make this thread safe. I periodically get random data showing up in the outline view while the core data object tree is being updated. I've tried locking the managedObjectContext when I make additions or changes to the object tree, but I still get erroneous data showing up in the view. I don't understand how NSTreeController and bindings are interacting with Core data to extract the data while I'm populating it. Any suggestions greatly appreciated. I've been reading and rereading the Core Data programming guide and Threading programming guide to no avail. The Core data programming guide says its best to maintain a separate managedObjectContext per thread. But this appears to require the data to be written to persistent store to make it work (file). That not reasonable in my case where I'm adding many objects to an object tree. It takes a significant amount to time to write it out, negating the benefit of trying to make the UI seem responsive. I'm running Leopard. ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: NSDictionary with bool and float
Take a look at NSValue and NSNumber http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSValue_Class/Reference/Reference.html http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSNumber_Class/Reference/Reference.html They can be used to store raw datatypes in collections that require objects. On Mar 28, 2008, at 10:13 PM, Mr. Gecko wrote: Hello I am wondering if there is a way to have a BOOL or a Float in an NSDictionary I know you can in an NSUserDefaults but I need it for NSDictionary so I can save it in a package for themes or whatever. is this possible? Here is my code I tried. NSMutableDictionary *plist = [NSMutableDictionary dictionary]; [plist setObject:@Bob forKey:@name]; [plist setBool:YES forKey:@theme]; [plist setFloat:4.0 forKey:@version]; [plist writeToFile:@/file.plist atomically:YES]; ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Getting view to update from changes made in thread using Core Data
I'm detaching a thread to handle some processing. In that thread, I create a new NSManagedObjectContext using the same NSPersistentStoreCoordinator from the main thread. I pass into the thread the NSManagedObjectID of an entity and my thread creates new entities and adds them as children of the existing entity. When the thread finished, it saves the Managed Object Context, then calls a method on the main thread that tells the application's main MOC to refreshObject :mergeChanges, passing in the managed object that I added child entities to. I specify YES for merge changes (although using NO doesn't change the results), and then tell it to processPendingChanges. The data gets correctly saved, but the NSOutlineView and NSTreeController I'm using to display the object and its children doesn't realize it. If I quit and come back in, all the stuff that was added in the thread shows up, but as long as the application is running, the results never show up. Am I missing some step I need to take in order to tell the outline view or the tree controller that one of the objects it is showing has been updated? TIA, Jeff ___ 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 [EMAIL PROTECTED]
Re: Beginner with Cocoa
On Mar 24, 2008, at 12:44 AM, Sherm Pendley wrote: The main thing you'll have to watch for: Objective-C 2.0 has garbage collection available, like Java and scripting languages you're familiar with, but it's off by default, and earlier Macs don't have it. You'll probably have to learn the old way, retain and release, which is unique to Objective-C. I'g be rather surprised if the Cocoa books took out discussions of traditional objective-C memory managements in their next releases. It's still available for use, and as you mention, necessary for writing to earlier versions of the OS, not to mention for programming that thing that we're allowed to talk about programming for here. The only reason I might discourage someone from buying the older books is not that they've become valueless, but merely because if the person is relatively new to coding, they might find the radical differences between the screenshots taken from the old IB and older versions of XCode / Project Builder to be disconcerting and hard to follow using the current tools. That won't be a big deal for an experienced programmer who wants to brush up on Cocoa, but for someone who doesn't have much experience under their belt, having things be in different places could be quite frustrating. I'm sure some of the books, as an example, show how to create your controller class source files from IB, which is no longer recommended. Also, just personally, I'd be upset if someone recommended to me a book without mentioning that that book was only a few months away from a new edition being released. But all that being said, most of the information, especially the conceptual stuff, in the books available now is still valuable and I apologize if I implied otherwise. Jeff ___ 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 [EMAIL PROTECTED]
Re: Quickly remove contents from NSArrayController
I would think that [itemBrowserArrayCTRL removeAllObjects]; would be your best. By calling arrangedObjects and feeding it to removeObjects:, you're causing your array to sort all 15000 entries before it removes them individually. HTH Jeff On Mar 24, 2008, at 10:16 AM, Martin Linklater wrote: HI. I have an NSArrayController which has over 15000 entries. When I clear the array using [itemBrowserArrayCTRL removeObjects:[itemBrowserArrayCTRL arrangedObjects]]; it takes a long time... like 10+ seconds on my MacBook Pro. Is there a quicker way of clearing the contents ? ___ 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 [EMAIL PROTECTED]
Re: Quickly remove contents from NSArrayController
Doh! You're right if course. How about using removeSelectedIndexes:? Should be faster than sorting the contents before removing them, Sent from my iPhone On Mar 24, 2008, at 10:26 AM, Martin Linklater [EMAIL PROTECTED] wrote: I would think that [itemBrowserArrayCTRL removeAllObjects]; would be your best. By calling arrangedObjects and feeding it to removeObjects:, you're causing your array to sort all 15000 entries before it removes them individually. NSArrayController doesn't have a removeAllObjects method... ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Core Data Passwords
When writing a Core Data application that utilizes Core Data, what is the best way to store sensitive information like a password? My assumption would be that you would make a password attribute, but make it transient, then override the accessor and mutator to utilize Keychain Services so that the value actually gets stored in the keychain, and not in the application's persistent store. Does this make sense? Has anybody tried this? Thanks much, Jeff ___ 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 [EMAIL PROTECTED]
Re: Beginner with Cocoa
On Mar 24, 2008, at 1:43 PM, colo wrote: Well I have to say. None of that sounds like any fun what so ever. In fact it sounds a little anti-constructive with the amount of time it would take to get anything out the door let alone prototyped to a beta. Then don't judge a book by how it sounds. :) Having worked with both garbage collected and non-garbage collected, I can tell you that Objective-C using retain/release is one of the fastest languages for getting something out the door. In fact, it very quickly becomes second nature, and now with Objective-2.0 properties, the bulk of the grunt work around setting up your accessors and mutators properly is gone. With or without garbage collection, Cocoa is a very fast-working set of tools. ___ 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 [EMAIL PROTECTED]
Re: Cocoa Database Connection
Did you include libpq.a from the /lib folder of our PostgreSQL
implementation?
On Mar 24, 2008, at 3:21 PM, Western Botanicals wrote:
Thank you to everyone who has responded so far. I ended up fixing
the problem by importing the postgres_ext.h file into my project
(I wish I could have just done a find for it).
But now with the following code:
#import Cocoa/Cocoa.h
#include libpq-fe.h
int main(int argc, char *argv[])
{
char *conninfo = ;
PGconn *conn;
conn = PQconnectdb(conninfo);
return NSApplicationMain(argc, (const char **) argv);
}
I get the following error when I try to compile:
_PQconnectdb, referenced from:
_main in main.o
symbol(s) not found
collect2: ld returned 1 exit status
Is this code incorrect, or do I need to import something else?
Thank you,
Justin Giboney
___
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/jeff_lamarche%40mac.com
This email sent to [EMAIL PROTECTED]
___
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 [EMAIL PROTECTED]
Re: Height of UIToolbar
I think you missed the memo. We're not to discuss the iPhone SDK on this list because its under NDA and this is a public list. Sent from my iPhone On Mar 23, 2008, at 2:27 PM, Kevin Albrecht [EMAIL PROTECTED] wrote: How do you get the height of a UIToolbar? I am using the UIToolbar similar to the way it is used in the Cocoa Touch Toolbar project included with the SDK. The bounds of the toolbar returns the bounds of the entire window. Thanks, Kevin Albrecht ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: Height of UIToolbar
Unfortunately, not yet :( We've been getting mixed messages from people @Apple on all things iPhone... think they were a little overwhelmed by the response to the SDK. Sent from my iPhone On Mar 23, 2008, at 3:56 PM, Kevin Albrecht [EMAIL PROTECTED] wrote: Ah, sorry. Where can this be discussed? Is there a closed mailing list for discussion of unreleased APIs? Thanks, Kevin I think you missed the memo. We're not to discuss the iPhone SDK on this list because its under NDA and this is a public list. On Sun, Mar 23, 2008 at 11:27 AM, Kevin Albrecht [EMAIL PROTECTED] wrote: (Some stuff regarding the iPhone SDK) ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: base64 NSData to NSString
I really wouldn't do it this way. There are many ways of doing this within your app without spawning a task. LibCrypto offers functions for encoding and decoding Base64 as does LibSSL (which is going to be the same code as you're currently trying to use, but without spawning a task). There are also several categories on NSData floating around out there that will allow you to decode and encode Base64 right in your application, some of which are very well tested. You can find some good discussion on the topic here: http://www.cocoadev.com/index.pl?BaseSixtyFour The category from Colloquy that is discussed has moved to a new location. You can find it at its new location here: http://colloquy.info/project/browser/trunk/Additions/NSBundleAdditions.h http://colloquy.info/project/browser/trunk/Additions/NSBundleAdditions.m HTH Jeff On Mar 22, 2008, at 1:22 PM, Marco Cassinerio wrote: i'm trying to read the com.apple.recentitems.plist file and i found that Alias and Icon key are base64 NSData object. NSData and NSString don't provide methods to manage base64 data. I've searched with Google and i found some pathces for NSString and NSData but they don' t seem to work. I've also tried to write NSData object content to file and pass it to openssl command from bash: openssl base64 -d -in in.txt -out out.txt but it always create a blank file. Any suggestions? ___ 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 [EMAIL PROTECTED]
Re: Beginner with Cocoa
On Mar 21, 2008, at 3:00 PM, Alex Handley wrote: Hi, I have previously programmed in java and a few scripting languages and was wondering if anyone had any suggestion for learning cocoa, most of the tutorials I find are for pervious version Apple has this: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/01Introduction/chapter_1_section_1.html As for books, I believe that a number of the stalwart Cocoa books, such as Aaron Hillegas' are in the process of being revised for the Leopard changes due out this year some time, but I don't think there is anything yet available that deals with the newest stuff like Objective-C 2.0. That being said, the bulk of the conceptual material is still applicable, so you won't be harmed by using one of the books available now. ___ 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 [EMAIL PROTECTED]
Re: Cocoa Database Connection
On Mar 21, 2008, at 7:50 PM, Justin Giboney wrote: So, libpq sounds like a well supported way to go, but when I import libpq-fe.h into my project I get an error that says postgres_ext.h: No such file or directory, along with 30 more errors which I assume are related to the lack of this file. I searched my computer for it and I can't find it. There are actually several header files that make up the libpq; they should be in the lib folder of your Postgresql installation, so just add the missing headers along with libpq-fe.h and the library. ___ 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 [EMAIL PROTECTED]
NSFileHandle and sockets
Thanks to help from several people on the list, I got NSFileHandle working with remote sockets, and wrote a category on NSFileHandle to make it easier to use it that way. Since it would not have been possible to write this without the help of several people on this list, I thought I'd make the category available back to the list. You can download it from http://innerloop.biz/code/NSFileHandle-NetSocket.zip I release all of the original material in this category to the public domain - no license, no attribution necessary. The comments in the header file should give you what you need to use it, but feel free to ping me with any questions or improvements. Jeff ___ 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 [EMAIL PROTECTED]
Re: Network communication with NSFileHandle NSSocketPort
On Mar 19, 2008, at 5:58 AM, Valentin Dan wrote:
I need to send and receive message over the network but I got stuck …
Surprisingly, there is no general-purpose Cocoa wrapper for the
CFNetwork foundation functions. There are several specific wrappers -
such as NSURLConnection and NSURLDownload, but if you want to do low-
level socket communication with a protocol other than HTTP or FTP,
you're going to have to get your hands a little dirty.
You always have the option of using BSD Sockets, of course, if you
want to go old school. Or you can use the CFNetwork functions. There
are a few Objective-C wrappers provided by third parties, including
AsyncSockets, SimpleSockets, and NetSockets, but if you're going to be
doing a lot of network communication in your application, I would
recommend diving in and really learning the way CFNetwork
functionality works. Even though it's implemented with C functions
rather than Objective-C classes, it still has a lot of really nice
functionality, and since it's the basis for most (all?) of the Cocoa
networking classes, it's very robust and well-tested. It offers run
loop integration which allows you to keep from blocking without having
to detach threads . It's conceptually a little hard to wrap your head
around the way it works, but overall, it's probably your best bet
unless your needs are relatively simple, in which case something like
SimpleSockets is probably the way to go.
http://developer.apple.com/documentation/Networking/Conceptual/CFNetwork/Introduction/chapter_1_section_1.html
Here's a little trick for integrating the C callback functions into
your objective-C method. When you create your CFStreamClientContext,
pass a pointer to self in the second argument. Whatever you pass there
will get passed back to your callback function Then, in your callback
function, you can do something like this:
void readStreamCallBack(CFReadStreamRef stream, CFStreamEventType
type, void *controller)
{
id self = (id)controller;
...
If you do that, you can then makes calls against self just as you
would in one of your instance methods. The only other real gotcha is
that you have to implement a buffering scheme. The information comes
in chunks on the read stream, and on the write stream, you sometimes
have to wait and yield to the run loop before you're able to write,
and sometimes have to write in chunks. If you do not pass control back
to the run loop when the stream is not ready, it will never be ready.
Hope this helps,
Jeff
___
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 [EMAIL PROTECTED]
Re: Downloading via FTP and loading images in a NSTableView
On Mar 19, 2008, at 9:50 AM, Valentin Dan wrote: I'd like to know how can I get a file from a server that requires user password ? What classes should I look at ? I believe NSURLDownload can handle FTP URLs. You could also use the CFFTP functions from CFNetwork. ___ 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 [EMAIL PROTECTED]
Re: NSTableView solution feedback and questions
Jay: Well, I've never had this particular situation, but you could try registering for textDidBeginEditing) notification from the table view, then your code will have a way of knowing when the user is editing a table. If it's currently being edited when your timer method starts to do an update, you could use the editedColumn and editedRow methods to determine if the cell being edited is the one you need to update and hold off on doing the reloadData method until after they finish editing (you can use the textDidEndEditing for that one). If the update is in the row they are editing, then you need to figure out how to deal with that, it's going to be specific to your application. You might present them with a sheet that tells them what the update is and let them choose which one to keep. Hope this helps. Jeff On Mar 18, 2008, at 1:17 PM, Jay Martin wrote: All, I'm new to Cocoa (surprise) and I'm now working on a little app, and I've come up with a solution to an issue and I'd like some feedback on that solution. Here's the problem description: I have an NSTableView, bound to an NSArrayController, which is bound to my custom object. So far so good. I can change attributes, add, remove, all that good stuff. Now, my custom object can have one property changed programmatically by an NSTimer. Of course, when the change happens, the object is updated but not the NSTableView. So, I implemented a notification in the set method for that property, and registered a notification listener in my app controller. Now, when the app controller sees the update to that property, it calls reloadData method on the NSTableView. That seems to work nicely. Except one thing: if I'm in the middle of editing a different row when the NSTableView:reloadData method is called, the editing is ended. One obvious way around this is to not allow in-line editing of the data in the table, but rather in a separate set of controls for the object for the selected row. That's where I am currently. So, my first question is, am I missing something fundamental here? Is this the right way of doing it, or is there a better way? I thought maybe KVO might be a solution, but it didn't really seem appropriate to this situation. I suppose you could try to manually update just the cell, right? My second question is more general. I've basically just completed the Cocoa Programming book by Hillegass. Is there a next logical book/document to read, or is it just time to write lots of experimental code and ask questions? Thanks! jay ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
NSTextField value binding (feeling like a newbie)
Working with IB3 to try and get my bearings again, and I know I'm doing something stupid here. I have an NSTextField inside an NSScrollView created in IB3. I have bound the value binding of the NSTextField to an NSString called feedback, exposed as an Objective-C 2.0 property,declared like this: @property (retain, nonatomic) NSMutableString *feedback; In my implementation, use @synthesize to have it build the accessors and mutators. The binding is set to Continuously Updates Values, and is not editable, and has rich text turned off. If I run my program, and make changes to the string (feedback), those are not reflected in the text field even though I can tell through the debugger that the string is changing. I suspect I'm doing something really stupid, but I'm stumped, and nothing in the archives pointed me in the right direction. The Objective-C 2.0 book seems to indicate that properties are KVC compliant, but maybe I missed something? Any thoughts would be much appreciated. Thanks, Jeff ___ 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 [EMAIL PROTECTED]
Re: NSTextField value binding (feeling like a newbie)
On Mar 18, 2008, at 5:33 PM, Jeff LaMarche wrote: . If I run my program, and make changes to the string (feedback), those are not reflected in the text field even though I can tell through the debugger that the string is changing. Just a clarification, if I populate the string with a starting value, that does show up in the text view, so I know the binding is working, partially at least. ___ 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 [EMAIL PROTECTED]
Re: NSTextField value binding (feeling like a newbie)
Quincey - Thanks much. You pointed me in the right direction - I was doing this: [self.feedback appendString:string]; Thanks much for the help! On Mar 18, 2008, at 6:10 PM, Quincey Morris wrote: On Mar 18, 2008, at 14:33, Jeff LaMarche wrote: I have bound the value binding of the NSTextField to an NSString called feedback, Actually, you bind the text field to the property feedback of some object (File's Owner?). When you start using array properties, getting this terminology right will help you avoid a *lot* of grief. (Sometimes a property of an object is really an object, sometimes it's not.) exposed as an Objective-C 2.0 property,declared like this: @property (retain, nonatomic) NSMutableString *feedback; In my implementation, use @synthesize to have it build the accessors and mutators. The binding is set to Continuously Updates Values, and is not editable, and has rich text turned off. If I run my program, and make changes to the string (feedback), those are not reflected in the text field even though I can tell through the debugger that the string is changing. Make changes how? If you're doing 'someObject.feedback = newString', the text field should update. If you're doing (in a someObject method) 'feedback = newString', the text field won't update unless you enclose it in willChangeValueForKey/didChangeValueForKey. ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
interface builder 3 question
So, as I said in an earlier post, I'm getting back into Cocoa development after a little hiatus. I was working in IB today. Boy, it's changed, and for the better, but I can't figure out how to do something I used to do in Interface Builder. I want to create an instance of a custom NSObject subclass, which I've been able to do, but I can't figure out how to specify the superclass. I can, of course, generate the files and then go manually insert the superclass in the class declaration, but it seems to me that I must be overlooking it, or doing something stupid. If anyone could point me to how I can specify the parent class of a new class in IB, I would appreciate it. Thanks much Jeff ___ 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 [EMAIL PROTECTED]
Re: interface builder 3 question
On Mar 17, 2008, at 10:55 PM, Kyle Sluder wrote: I assume you mean you want to specify the class of the instance, because specifying the NSObject's superclass is a nonsensical statement. The field you're looking for is on the Identity pane of the Inspector LOL. Sorry, I shouldn't try and do this stuff so late at night! I meant specifying the new class' superclass. I did use the Identity Pane to change the class from NSObject to another class that doesn't exist, but how do I tell Interface Builder that the new class I'm specifying and intend to have it generate the files for is a subclass of NSObject, or whatever class I want it use as the superclass? I used to be able to use the class hierarchy, right click on NSObject, or NSView or whatever and select create subclass, and then instantiate the subclass. I'm able to create an instance, but I don't know how to tell it that the instance I'm creating should be a new class, or how it fits in the class hierarchy. I hope I made more sense that time. Thanks, Jeff ___ 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 [EMAIL PROTECTED]
[OT?] WWDC
Hey, folks. I'm just diving back into Cocoa after about eighteen months of doing mostly non-Mac programming (I know, I know). To help me jump-start back into Cocoa, I've signed up for WWDC this year. In the past, there used to be unofficial gatherings at WWDC - I think Stepwise used to run one for Cocoa developers... can't remember what they were called, something like Birds of a Feather meetings or something like that. Do these still happen, and how does one find out about them? Thank much! Jeff ___ 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 [EMAIL PROTECTED]
Re: Mail - check email
You may be confusing two separate things. Mail plug-ins are not applications, and they have to use a private, undocumented API. It is not something encouraged by Apple, nor is it a great choice for a Cocoa program. If you're serious, there are several plug-ins with the source code available you can study, like GPGMail http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html Now, if your application just need to communicate with Mail, then you should read up some of the documentation about interapplication communications at the Mac Dev Center. There are several options, including NSPipe and the Scripting Bridge, the latter most likely being a better choice for interacting with Mail. http://developer.apple.com/documentation/Cocoa/Conceptual/ScriptingBridgeConcepts/index.html On Mar 14, 2008, at 9:49 AM, Cocoa wrote: I am new to programming. I studied basic C language, and recently I read the Objective-C Tutorial and Cocoa Fundamental Guide , but i am still confused with how do I connect my the codes with other applications on the mac such as Mail.app. I am planing to write a plug-in for Mail.app. Are there anyway to do this. I have been reading around the stuffs on the net like Application Kit, Foundation. I think I need to use NSApplication, and NSNotification. Am I right? It's a simple plug-in, it only check the Mail if it has new mails, if it has, return a message and display at the center of the monitor, if it doesn't, just do nothings ___ 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 [EMAIL PROTECTED]
Re: Creating Custom Views in Interface Builder
I wrote an article for MacTech a while back on doing this... it may be a little outdated by now since it was written when Tiger was new, but may still contain some useful info: http://www.mactech.com/articles/mactech/Vol.21/21.10/Palettes/index.html On Mar 14, 2008, at 2:46 PM, [EMAIL PROTECTED] wrote: Hi Michael! It seems to me that you should be able to follow the QuickStart for building an InterfaceBuilder plug-in to create your custom NSView: http://developer.apple.com/documentation/DeveloperTools/Conceptual/IBPlugInGuide/Plug-inQuickStart/chapter_3_section_1.html#/ /apple_ref/doc/uid/TP40004323-CH9-SW1 I actually suggest reading through the whole document. It's quite comprehensive. Varun Hello List! I am trying to create a custom view class using Interface Builder that I can then instantiate within my code as many times as needed. In this particular case I have a control that I've created that contains a progress bar, two text fields, two buttons, and an image view. I then want to be able to create any number of these components within my source code and add them to another view dynamically. I'm guessing that this question has been answered before, but my searches have been unsuccessful. If someone could point me in the right direction, that would be a great help. Thanks! Regards, Michael -- OS X 10.5.2 Xcode 3.1 Interface Builder 3.1 ___ 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/varun%40mehtasw.com This email sent to [EMAIL PROTECTED] ___ 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/jeff_lamarche%40mac.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
Re: What is the status on the New Cocoa 2.0 Books?
On Mar 13, 2008, at 5:43 AM, Thomas Engelmeier wrote: Maybe it paid off to be a late adoptor. Inside Macintosh:AppleTalk and New Inside Macintosh:Quicktime / New Inside Macintosh:Interapplication Communication set a very high standard for documentation - far higher than the IBM UI guidelines and the Windows 3.x docs from that time. Inside Macintosh was a great series, but the versions you refer to really were a 2.0 version of the toolbox documentation. The original Inside Macintosh volumes, though far better than much of the developer documentation of the day, came in numbered volumes that were less than perfectly organized. We also had to contend with the fact that all the code examples were written in Pascal early on, long after most developers had switched to C. The current reference might be neat, but IMO it lacks severely what made up the NIM series: Describing the architectural goals of an given API. Pointing out a terse description in one fairly new class (it's new with Leopard) is hardly indicative of the overall quality of the developer documentation, which is excellent. In many places, Apple goes into great detail about the architecture underlying a particular framework. I don't think we would have had ANY documentation in our hands about such a new method so soon after it came out back in the day, and the only hyperlinked API reference available back then (Think Reference) probably wouldn't have had any information about this new method so soon after its release. Back in the day, we would have been digging through header files and trying to figure out what the heck was going on, trying to figure out what some opaque handle was used for or figuring out what the gestalt values were for some new library or extension. Those big books were awesome, but they had quite a lead time and the APIs were a heck of a lot smaller then than they are now and tended to change less often. The fact that even before Leopard shipped to the public, we developers were able to option double click on that class in Xcode and get an accurate description of its methods and properties is pretty amazing, and I find it hard to believe anyone would prefer going back to the days of dead tree Inside Macintosh documentation. The documentation may not be perfect, but I still say we're spoiled. ___ 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 [EMAIL PROTECTED]
Re: What is the status on the New Cocoa 2.0 Books?
On Mar 12, 2008, at 11:03 PM, Jens Alfke wrote: (Actually, the current docs are quite good, all things considered. Back in the day, the system documentation used to consist of badly- Xeroxed copies of napkins that the programmers had scrawled some instructions on, while suffering from exhaustion and caffeine psychosis. And the developer program charged you $1200 a year for those, and didn't even give you a damn binder to put them in. And we lapped it up!) Actually, I've been spending a lot of time reading Apple documentation since last Thursday or so, and I was just thinking that Apple's technical documentation has gotten very, very good - we're downright spoiled, especially all the documentation for that new thing we're not allowed to discuss here yet but could for a few minutes the other day. But it is what it is - it's professional API documentation targeted at third party developers who don't need much handholding on basic concepts. There will always be a market for good books that take the newcomer by the hand and explain things more slowly and and use a lot of examples to drive home important points. Not a very big market, perhaps, in the case of Cocoa or Objective-C books, but a market nonetheless. ___ 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 [EMAIL PROTECTED]
Re: How to run progress bar in a separate thread
On Mar 10, 2008, at 10:08 PM, Nick Rogers wrote: NSThread has one method: + (void)detachNewThreadSelector:(SEL)aSelector toTarget:(id)aTarget withObject:(id)anArgument But its hard to understand as to how to implement it, since its a class method. Don't let the fact that it's a class method scare you, just call it on the class object, like: [NSThread detachNewThreadSelector:@selector(myMethod: toTarget: myClass withObject:nil]; Or, instead of nil,you can supply an object. Apple actually does a darn good job documenting this whole process in the Threads Programming Guide: http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/Multithreading.pdf ___ 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 [EMAIL PROTECTED]
