Re: NSService - I need a headslap
On Feb 4, 2009, at 2:37 PM, Peter Ammon wrote: On Tiger and earlier, there is no way to avoid needing to log in and out. On Leopard, you can use the function NSUpdateDynamicServices() to immediately scan for new Services. If you're just testing, a quick way to scan for new Services is to run pbs directly: /System/Library/CoreServices/pbs However, pbs has no supported public interface and this will (has already) change, so don't include any reference to pbs in a script. NSUpdateDynamicServices() is the right way to programmatically refresh Services. FYI, I've found that using RubyCocoa is a nice way to do this, for testing: % ruby -rosx/cocoa -e 'OSX.NSUpdateDynamicServices()' -Dave ___ 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: @loader_path and @executable_path
On Jan 12, 2009, at 10:47 AM, Joseph Crawford wrote: I do not know if this is a cocoa question or not, it is an error I get when I hit build go This GDB was configured as i386-apple-darwin.tty /dev/ttys001 warning: Unable to read symbols for @loader_path/../Frameworks/ BWToolkitFramework.framework/Versions/A/BWToolkitFramework (file not found). warning: Unable to read symbols from BWToolkitFramework (not yet mapped into memory). warning: Unable to read symbols for @loader_path/../Frameworks/ Sparkle.framework/Versions/A/Sparkle (file not found). warning: Unable to read symbols from Sparkle (not yet mapped into memory). These are just debugger errors. This is most like due to those frameworks being compiled in Release mode with their debug symbols stripped. It should not affect debugging of your own application. I did some googling and found that people used a tool to use @executable_path rather than @loader_path but I also read that those values should be the exact same so changing them is not the optimal change to make. For an application, they resolve to the same thing. Does anyone have any idea where I can see / set these values? I have checked my Xcode Project Build settings, the framework build settings, etc. and cannot find them. They are set in the frameworks project, not yours. So if you're linking to pre-built versions of Sparkle and BWToolkit, there are no settings in your app that affect this. In general, @loader_path is preferred over @executable_path, as it allows embedded frameworks to work in both an executable and a bundle, plugin, or sub-framework. The only downside is that @loader_path requires 10.4 or newer. If you're on 10.5 or newer, @rpath is even better than @loader_path. -Dave ___ 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: @loader_path and @executable_path
On Jan 12, 2009, at 2:12 PM, Joseph Crawford wrote: I figured out that issuing this command in terminal fixed the issue for this project. install_name_tool -change @loader_path/../Frameworks/ Sparkle.framework/Versions/A/Sparkle @executable_path/../ Frameworks/Sparkle.framework/Versions/A/Sparkle /Users/jcrawford/ Cocoa/TomTom POI Manager/build/Debug/TomTom POI Manager.app/Contents/ MacOS/TomTom POI Manager This is dangerous. Because the string @executable_path is longer than @loader_path, you are probably overwriting parts of the binary which could cause subtle but weird problems down the line. Don't do that. (1) However my question is since this was only for this one particular project, any other project will encounter these errors. Is there a way to make this system wide so that if my build directory is cleared or another project is created this problem will not be encountered? This smells like a bug in gdb, if it's warning for @loader_path but not @executable_path. Just ignore the warnings and file a bug. The only proper way to change from @loader_path to @executable_path is to recompile the frameworks with a different install name. -Dave (1) Unless the frameworks were linked with -header- pad_max_install_names. They probably were not, so hence it's dangerous. ___ 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: @loader_path and @executable_path
On Jan 12, 2009, at 6:33 PM, Dave Dribin wrote: Upon further investigation, the error (file not found) seems to imply that it can't find the file, which is clearly not the correct error message. Furthermore, I took a quick glance at the gdb sources [1], and noticed that it only resolves @executable_path. I'm guessing gdb needs to be updated to properly support @loader_path and @rpath. Namely the dyld_library_basename() looks incorrect. I'm gonna file a bug about this. Err... I meant dyld_resolve_image(). Bug filed: rdar://problem/6491330 http://openradar.appspot.com/6491330 It only seems to happen with @loader_path. @executable_path and @rpath do not give any warnings. Here's the project that I included in the bug report: http://dl.getdropbox.com/u/27036/tmp/2009/AppWithFramework.tbz2 -Dave ___ 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: Thread ID in crash log
On Dec 17, 2008, at 7:37 PM, radj wrote: I see. I'm not trying to be ungrateful (because I really am, thanks for the code), but calling CrashLogThreadID(pthread_t) might be too costly for every call to my custom debugLog(...) because there are alot all over the code (not the best practice, me thinks). But thanks to your intro to task_threads(), I can follow the idea and try my own array of threads. This gives me something to start on! Appreciate it. =) You could cache the thread ID in the pthread context or NSThread dictionary. -Dave ___ 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: Thread ID in crash log
On Dec 17, 2008, at 10:11 PM, Greg Parker wrote: Of course, if the number of threads changes then that cached thread ID may not match the crash log anymore. (And the number of threads in your process may change due to code outside your control.) Ah, right. Never mind. :) -Dave ___ 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: NSInMemoryStoreType: Not really persistent, is it?
On Oct 21, 2008, at 6:53 PM, Bill Bumgarner wrote: The in memory store is actually extremely useful for caches and as a backing store for applications that read/write to/from some kind of server -- typically an XML RPC of some type -- that wants to take full advantage of CD's object graph management infrastructure. The various change hooks on the MOC and coordinator make it possible to easily mirror the changes out to the wire protocol or update the local cache -- the in memory persistent store -- with changes pulled from the other side. I've been using the in-memory persistent store for unit testing a lot lately. In setUp and tearDown, I create and destroy a full core data stack with an in-memory store. It's very fast, and you're guaranteed a clean slate for each unit test. -Dave ___ 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: Multiple persistent store coordinators gotchas?
On Oct 16, 2008, at 3:59 PM, Dave Dribin wrote: On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote: Stale data is unlikely to be a problem unless you're expecting to load it significantly before you actually need it, which would be the same if you were loading it into a separate context on the same coordinator. Just to clarify, stale data is only an issue for long-lived MOCs, not long-lived PSCs. For example, if we create 1 PSC for all the background threads to share for the lifetime of the app, but only create (or reset) MOCs just before report generation, there's minimal chance of stale data. These new/reset MOCs will always have fresh data? I wrote a quick app to test this out and the PSCs are indeed independent, but only if you're using the SQLite store. Creating (or resetting) a MOC does indeed pick up changes that have been saved from another PSC. For XML and binary stores, it seems that the store is completely read into memory when you call addPersistentStoreWithType:. For those types, you need to remove then re-add the persistent store, in addition to calling [moc reset] or creating a new MOC. -Dave ___ 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: Multiple persistent store coordinators gotchas?
Hi Melissa, Thanks for your help. A quick question on this stale data statement: On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote: Stale data is unlikely to be a problem unless you're expecting to load it significantly before you actually need it, which would be the same if you were loading it into a separate context on the same coordinator. Just to clarify, stale data is only an issue for long-lived MOCs, not long-lived PSCs. For example, if we create 1 PSC for all the background threads to share for the lifetime of the app, but only create (or reset) MOCs just before report generation, there's minimal chance of stale data. These new/reset MOCs will always have fresh data? -Dave ___ 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]
Multiple persistent store coordinators gotchas?
Hello, I'm working on a Core Data application that does lots of processing of the data in background threads to generate reports. I'd like to investigate using multiple persistent store coordinators to reduce lock contention, i.e. pattern #2, as described in the multi-threaded chapter of the Core Data guide. I'm thinking it is a good fit in this case as the background threads are doing mainly read-only operations on the data. It does modify transient properties, but I think I can still get away with using a read-only store on the background threads. Is this correct? The documentation is a little thin about using multiple PSCs. Is it just a matter of setting up separate Core Data stacks per thread? What are the downsides, especially compared to 1 PSC/multiple MOCs? Higher memory usage? Separate caches? Stale data? Anything else to watch out for? Thanks, -Dave ___ 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: Multiple persistent store coordinators gotchas?
On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote: If your second thread is doing pure report generation, and whatever transients it sets won't affect anything outside the report generation, this is the solution you're looking for. Great, thanks! The documentation is a little thin about using multiple PSCs. Is it just a matter of setting up separate Core Data stacks per thread? Yes. What are the downsides, especially compared to 1 PSC/multiple MOCs? Higher memory usage? Separate caches? Stale data? Anything else to watch out for? The downside tends to be more memory use, since you'll have two copies of all the data for each object that is loaded into both stacks in addition to the overhead of the stack itself. Stale data is unlikely to be a problem unless you're expecting to load it significantly before you actually need it, which would be the same if you were loading it into a separate context on the same coordinator. Okay, great. This sounds ideal. One clarification. When you say two copies of all the data, doesn't this happen if you had 1 PSC and 2 MOCs, too? Each MOC has it's own copy of the data, since they don't share managed objects, right? Or is there some other data that is shared in the PSC? The big upside is that it decreases the amount of time your UI thread will be blocked on reads being done by the background thread. Precisely. I'm seeing some lock contention between the threads, and I want to reduce/eliminate that. BTW, this is a SQLite store. Do fetches do an exclusive SQL transaction, or is that only done for saves? Just curious if SQLite's locking will affect the threads at all, as we're seeing some fetches take a relatively long time (~3 seconds). Ideally, the SQLite database won't be locked for that period, either, which would also block the UI thread. -Dave ___ 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: NSManagedObject subclass accessor pattern mystery?
On Sep 29, 2008, at 11:44 PM, Michael B Johnson wrote: So I have a CoreData app (10.5.5, 64 bit only) that has a NSManagedObject that has an NSColor* that is part of its data model. Because this color is actually a computed value that we want to cache, it is declared as a property: Have you read the Non-Standard Persistent Attributes of the Core Data guide? It gives you several ways of doing this and even uses NSColor as an example: http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdNSAttributes.html The easiest way, if you can require 10.5, is to use a transformable attribute. Core Data will automatically transform your NSColor to and from NSData using an NSValueTransformer. In other words, I read my document off of disk, and CoreData magically makes sure that my color property is set. But since it never seems to call my setColor: setter, I don't see it happen, which is when I would like to go ahead and cache my separate red, green, and blue properties. Since these are calculated from the color (which is saved), there's no reason to ever store them to disk. If you want to cache the RGB values, you'll probably want to follow the instructions in Custom Code. Perhaps a pre-calculated getter and an immediate-update setter? In awakeFromFetch and setColor: you could update the RGB values as well as the primitive color. -Dave ___ 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 set up a thread listening to performSelector: messages?
On Sep 25, 2008, at 10:53 AM, Oleg Krupnov wrote: Then from the main thread I send: [[worker runLoop] performSelector:@selector(processRequest:) target:worker argument:request order:0 modes:[NSArray arrayWithObject:NSDefaultRunLoopMode]]; You cannot do this. NSRunLoop is not thread safe and the docs say explicitly not to call methods on a different thread. You need to use NSObject's performSelector:onThread:... method. -Dave ___ 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: unable to break out of runloop because timers are fired and then the loop waits
On Sep 24, 2008, at 3:35 PM, Jason Bobier wrote: Thanks Nick. I'm trying to avoid polling tho (since that is the whole point of runloops and mach ports). Take a look a message I posted a few days ago that uses a Mach port to wake up the run loop: http://lists.apple.com/archives/Cocoa-dev/2008/Sep/msg01155.html I never got any replies, but it's working well for me. What you'd do is install a DDRunLoopPoker and then call -pokeRunLoop in your timer callback. That'll force runMode:beforeDate: to return. -Dave ___ 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]
Poking an NSRunLoop with an NSMachPort
Hello,
I'm trying to figure out how to get a blocking call to -[NSRunLoop
runMode:beforeDate:] to return. It seems the best way to do this is
to use a real (non-timer) input source to poke the run loop, as
mentioned by Chris Kane in this post:
http://lists.apple.com/archives/Cocoa-dev/2003/Mar/msg01158.html
To implement this, I've created a class that adds an NSMachPort to the
run loop and then sends it a message to poke the run loop. I based
this class on code from the Configuring a Port-Based Input Source
section of the Threaded Programming Guide [1]. Since I haven't used
NSPorts much, I want to make sure what I'm doing looks proper. A
snippet of code is included.
It all appears to work, but can NSPortMessage's receivePort be set to
nil? The docs aren't clear on this, but I don't care about a getting
replies. I guess I could create a dummy receive port. Does
everything else look sane? Or perhaps there's a better/easier way to
accomplish what I want?
-Dave
[1]: http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/chapter_6_section_5.htm
static const uint32_t kPokeMessage = 100;
@implementation DDRunLoopPoker
- (id)initWithRunLoop:(NSRunLoop *)runLoop;
{
self = [super init];
if (self == nil)
return nil;
_runLoop = [runLoop retain];
_pokerPort = [[NSMachPort port] retain];
[_runLoop addPort:_pokerPort forMode:NSDefaultRunLoopMode];
[_runLoop addPort:_pokerPort forMode:NSModalPanelRunLoopMode];
_pokeMessage = [[NSPortMessage alloc] initWithSendPort:_pokerPort
receivePort:nil
components:nil];
[_pokeMessage setMsgid:kPokeMessage];
return self;
}
- (void)pokeRunLoop;
{
[_pokeMessage sendBeforeDate:[NSDate date]];
}
@end
___
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]
Abusing targetForAction: with non-action selectors
Hello, Is it safe to use -[NSApplication targetForAction:] with non-action selectors? For example, selectors that have more than one argument, non-id first argument, or return values? The documentation for targetForAction:to:from: seems to imply it just does a respondsToSelector: on each object in the responder chain, and it seems to behave this way in my tests. I'd just like to make sure it is safe to rely on this behavior, or if we should find some other approach. Thanks, -Dave ___ 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: Abusing targetForAction: with non-action selectors
On Sep 15, 2008, at 6:30 PM, Julien Jalon wrote:
It's not safe... once the target is found (using
respondsToSelector:, you're right), the action is performed with:
[target performSelector:actionSelector withObject:sender];
which means that anything but an object as a sender will potentially
crash.
The only safe thing you can image is to have an action selector with
no paramater at all.
I'm not actually performing the action, just getting the target, and
then calling the method myself, kinda like a delegate:
id target = [NSApp
targetForAction:@selector(notReallyAnAction:withArgument:)];
if (target != nil)
{
int returnValue = [target notReallyAnAction:foo withArgument:bar];
// Do something with returnValue
}
-Dave
___
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: Abusing targetForAction: with non-action selectors
On Sep 15, 2008, at 6:35 PM, Graham Cox wrote: What exactly are you trying to do? I'd say it's not safe, since that usage isn't anticipated, or necessary. If you could perhaps outline why you think you need it a better solution can be suggested. I've got, say, an info panel that needs to display different stuff based on some object in the responder chain. What I really want to do is search the responder chain for an object that conforms to a specific protocol. I was just picking a method in the protocol as the argument to targetForAction:. I think the safe way is to put a dummy marker action on the protocol and then search the responder chain for that action. Then, check the target to make sure it actually conforms to the protocol. -Dave ___ 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: Abusing targetForAction: with non-action selectors
On Sep 15, 2008, at 6:56 PM, Graham Cox wrote: I think you have this a bit backwards, possibly. You still have to get notified when the first responder changes in order to tell your info panel to reorganise itself, so why not use that notification to directly obtain the correct target? Objects that can be displayed by your info panel will send a notification that they have become active, sending themselves as the notifier. The info panel receives that notification and so already has the desired target. It then just needs to check what protocols or methods the notifier responds to and set up its UI accordingly. It's really not that simple in this case, and the architecture is basically out of my hands. I'm watching first responder changes by listening to NSApplicationDidUpdateNotification, FWIW. -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 27, 2008, at 1:34 AM, Ron Lue-Sang wrote: Woah. If you really want to use a custom cell, you're gonna want a custom column as well. The bindings for the tableColumn come from the tableColumn's dataCell's available bindings. Yea, as you've found, NSActionCell has a value binding, not plain old NSCell. [.. snip ..] Does any of this make sense? Possibly, you've already solved this some other way, but hopefully I've cleared up a couple of things. Yeah, this all mostly makes sense. I'm content just subclassing NSActionCell for this case, though. FWIW, what I am trying to do is create a circular, nondeterminate (pie chart style) progress indicator cell and use it in a table column. So it's just doing some drawing based on objectValue (I'm using nil to mean hide the progress). Of course, I want to use bindings to hook this up to my model, too. Subclassing NSCell and binding the column's value seemed like the best approach. -Dave ___ 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 to use observeValueForKeyPath: context
On Aug 29, 2008, at 10:03 AM, Phil wrote: On Sat, Aug 30, 2008 at 2:56 AM, Dave Dribin [EMAIL PROTECTED] wrote: Is there some benefit to using number values over string constants, or is it just stylistic differences? Using NSStrings (or any other object) will work fine, but comparing two primitive numbers is a lot faster than comparing to strings. As long as the pointers point to unique objects (and they remain valid even in a GC world), you just need to compare their pointer value. So even with this: static NSString *PropertyObservationContext = @Property Context; You can still check (context == PropertyObservationContext) in observeValueForKeyPath:ofObject:change:context:. Personally, I wouldn't use arbitary numbers for any pointer value (even a context variable like this), but that's just my stylistic difference. I generally wouldn't either, unless there's some benefit I'm not seeing. -Dave ___ 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 to use observeValueForKeyPath: context
On Aug 29, 2008, at 11:27 AM, Michael Ash wrote: This (void *)1091 business seems highly dangerous to me. After all, what prevents somebody else from using 1091 too? If everybody uses a pointer value that's guaranteed to be unique (like a unique string literal) then you know you're safe. It really just needs to be unique in your class hierarchy, right? But, yeah, it still seems dangerous. I mean, what number do you start using, and what if your class hierarchy changes? I'm liking Ron's way, because that's guaranteed to be a unique pointer value. I still like the static string, too, but it sounds like in order to ensure uniqueness of the string within a class hierarchy, it may be a good idea to put the class name in there. Two classes using static @Property Context should still be unique, unless the linker does some cross-module string literal optimization so that there's only a single @Property Context string literal in the entire binary. I don't think it does now, but perhaps with LLVM it'll do more aggressive optimizations like this. -Dave ___ 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: Bindings: Specifying the Class of a Con troller’s Content
On Aug 29, 2008, at 12:38 PM, Oleg Krupnov wrote: My question is: what is a real example of a case when the controller needs to create new content objects? -[NSArrayController add:] ? You can use that as an action for a button in IB. -Dave ___ 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 to use observeValueForKeyPath: context
On Aug 29, 2008, at 12:35 PM, Dave Dribin wrote: On Aug 29, 2008, at 12:23 PM, j o a r wrote: The penalty for using constant strings is that they will end up wasting space in your binary... Rons suggestion is probably optimal. I'm definitely leaning towards that way, now. Though I may combine both for debugging. static NSString *PropertyObservationContext = @Property Context; Use PropertyObservationContext as the context. This way you could po *(id *)context in gdb for a human readable context. I've filed rdar://problem/6185473 to update the Key-Value Observing Programming Guide about proper use of the context. The doc doesn't even use the context at all. -Dave ___ 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: NSString and special characters
On Aug 22, 2008, at 3:39 AM, Bill Bumgarner wrote: Have you read this book? http://tinyurl.com/6kxxgc And it's even available online, now: http://www.simson.net/ref/ugh.pdf -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 21, 2008, at 12:45 AM, Ken Ferry wrote: The NSTextValueBinder error message is a bug? Or the fact that NSCell does not have a value binding? Or both? ;) Maybe both.. I meant the first. Well, more information. I found the code that was directly responsible for causing the error. It was in some code that was posing as NSTableView (no, I didn't write it, and I now plan to replace it :), so it was well hidden and I didn't even know it existed. It turns out calling [column infoForBinding:@value] can cause that error message and an exception to be thrown. In this case, I was binding to a column with a text field cell setup in IB, but then changing the cell in code in awakeFromNib. Calling infoForBinding: on this column, after changing the cell, gives that error. From what you said about IB doing text cell specific binding stuff, this isn't overly surprising. So maybe this is not quite a bug after all, as it's more of a hey, this isn't a text cell, you dummy. Though maybe the error message could be a bit more helpful? I meant that you should call bind:toObject:withKeyPath:options: yourself rather than relying on IB to do it. But that's exactly what I am doing. I've got no bindings on the column in IB, and in awakeFromNib, I'm calling bind:toObject:... on the table column. I don't call it on the cell. I'm assuming the table column passes the binding along to the cell somehow. It seems that value can be bound to a NSTableColumn only for certain cells (NSActionCell and subclasses)? Does the table column special case NSActionCell? Here's a stack trace when binding to value of a cell that is a direct NSCell subclass. self at #3 is an NSTableColumn: 2008-08-22 00:16:08.540 CellBinder[69717:10b] [NSTableColumn 0x101ed80 valueForUndefinedKey:]: this class is not key value coding- compliant for the key value. 2008-08-22 00:16:08.540 CellBinder[69717:10b] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[NSTableColumn 0x101ed80 valueForUndefinedKey:]: this class is not key value coding-compliant for the key value.' #1 0x901690fb in objc_exception_throw () #2 0x962dac71 in -[NSException raise] () #3 0x94d03ea3 in -[NSObject(NSKeyValueCoding) valueForUndefinedKey:] () #4 0x94bfb69b in _NSGetUsingKeyValueGetter () #5 0x94bfb1aa in -[NSObject(NSKeyValueCoding) valueForKey:] () #6 0x94c28d2a in -[NSObject(NSKeyValueCoding) valueForKeyPath:] () #7 0x90af02da in -[NSObjectParameterBinder _updateObject:observedController:observedKeyPath:context:] () #8 0x90af0048 in -[NSObjectParameterBinder _observeValueForKeyPath:ofObject:context:] () #9 0x90aefe77 in -[NSBinder _performConnectionEstablishedRefresh] () #10 0x90ae80e8 in -[NSObject(NSKeyValueBindingCreation) bind:toObject:withKeyPath:options:] () #11 0x22e5 in -[CellBinder_AppDelegate awakeFromNib] (self=0x1035680, _cmd=0x90232928) at /tmp/CellBinder/ CellBinder_AppDelegate.m:20 #12 0x962e9955 in -[NSSet makeObjectsPerformSelector:] () #13 0x908fbbe6 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] () #14 0x908f1e12 in loadNib () #15 0x908f1774 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] () #16 0x908f13b7 in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] () #17 0x908f12f5 in +[NSBundle(NSNibLoading) loadNibNamed:owner:] () #18 0x908f0fa4 in NSApplicationMain () #19 0x21f0 in main (argc=1, argv=0xb7c8) at /tmp/CellBinder/ main.m:13 -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 20, 2008, at 3:35 AM, Ken Ferry wrote: FYI, you should avoid using direct subclasses of NSCell in controls on Leopard and previous. Well, that settles that, then. ;) It's somewhat unfortunate, but there are many cases where messages need to flow from a cell up to a view. If your cell isn't an action cell, that message flow won't work. It's usually fine as long as your cell is purely stamped out drawing. If your cell has more complicated interactions with the user, like use of a field editor or rollovers or what have you, you're liable to see problems with non-action cells. This cell is just drawing, but given the bindings issue and the advice above, it looks like staying away from NSCell is a good idea, ATM. I suspect the problem here is that NSCell and NSActionCell don't have a value binding! Check the Cocoa bindings reference. Well, the Cocoa bindings reference does not have an entry for either NSCell or NSActionCell. For the next best thing, I printed out the return value of -exposedBindings for both. For NSCell, we've got these bindings: Exposed bindings: ( editable, enabled, font, fontBold, fontFamilyName, fontItalic, fontName, fontSize ) And for NSActionCell, we've got these: Exposed bindings: ( editable, enabled, font, fontBold, fontFamilyName, fontItalic, fontName, fontSize, value ) Indeed, NSActionCell has a value binding while NSCell does not. The information about how the bindings need to be hooked up may be determined at design time in IB. If IB thinks you have a text cell, you might get a binding set up in a way appropriate for a text cell. In any case, this 'binder' thing should have a bug too, if you please. The NSTextValueBinder error message is a bug? Or the fact that NSCell does not have a value binding? Or both? ;) If you want to go the bindings route, you could implement a value binding on your cell subclass by overriding -bind:toObject: withKeyPath:options: and then bind at runtime. That'd probably do the trick. I tried this, and it does not work. In fact - bind:toObject:withKeyPath:options: never gets called in my NSCell subclass. I even called [self exposeBinding:@value] in +initialize, and bind:toObject:... still does not get called. Is this a different bug? It seems like I should be able to add bindings to an NSCell subclass in this way. In any case, I'm back to subclassing NSActionCell as the way to get this working. -Dave ___ 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]
NSTableColumn not usable with binder of class NSTextValueBinder?
Hello, When I hit the Delete key in one of my table views, I get the following error logged to the console: Object NSTableColumn: 0x256740 is not usable with binder of class NSTextValueBinder I also don't get the typical Beep that happens when a key press goes off the end of the responder chain. What does this error mean? Have I messed up my bindings somehow? The bindings seem to be working just fine, though. I'm using Xcode 3.1 and the 10.5 SDK. Thanks, -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 19, 2008, at 3:27 PM, Dave Dribin wrote: Hello, When I hit the Delete key in one of my table views, I get the following error logged to the console: Object NSTableColumn: 0x256740 is not usable with binder of class NSTextValueBinder Further information: I have one column with a custom NSCell subclass. However, in IB, this column's cell is an NSTextFieldCell, and I replace the cell in awakeFromNib. I don't see a way to set the column's cell to a direct NSCell subclass in IB. As a test, I changed my custom cell to subclass NSTextFieldCell instead of NSCell and the console error goes away and the Delete key actually deletes the row. But this seems wrong as it's not displaying any text, though. -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 19, 2008, at 5:19 PM, Corbin Dunn wrote: You can in IB3; just double click on the cell...then set the class. It's not letting me set it to my custom cell. It just beeps (IB version 3.1, build 670). I think this is because the column is setup a text field cell, and it will only let me set the class to an NSTextFieldCell subclass. There's no plain NSCell in the Library from what I can find. Otherwise, you have to manually set up your binding in code after you set the [tableColumn dataCell]. The binding is specific to the cell type. If you need a code example, I can dig one up. Just tried that, too, and now I get the following error in the console (with -NSBindingDebugLogLevel 1): Cocoa Bindings: Error accessing bound property value of object NSTableColumn: 0x256ca0: [NSTableColumn 0x256ca0 valueForUndefinedKey:]: this class is not key value coding-compliant for the key value. Here's my code, which looks very similar to the ManualBindings sample code: [column bind:@value toObject:controller withKeyPath:@arrangedObjects.whatever options:nil]; Again, what's strange is if I change my cell's superclass to be NSTextFieldCell, this bind: call does not give an error and it all works. I also tried subclassing NSActionCell, and that works, too. Is my cell not implementing some method that bindings expects to be there? Something that is implemented in NSActionCell? -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 19, 2008, at 7:03 PM, Corbin Dunn wrote: It's not letting me set it to my custom cell. It just beeps (IB version 3.1, build 670). I think this is because the column is setup a text field cell, and it will only let me set the class to an NSTextFieldCell subclass. There's no plain NSCell in the Library from what I can find. Yeah, your correct; please log a bug on this and we will try to fix it. A hacky workaround is to temporarily subclass NSTextFieldCell, then set it in iB, then undo the change. But, the binder will probably be wrong...so that doesn't help you too much. FYI, I filed this as rdar://problem/6161481. -Dave ___ 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: NSTableColumn not usable with binder of class NSTextValueBinder?
On Aug 19, 2008, at 5:47 PM, Dave Dribin wrote: Again, what's strange is if I change my cell's superclass to be NSTextFieldCell, this bind: call does not give an error and it all works. I also tried subclassing NSActionCell, and that works, too. Is my cell not implementing some method that bindings expects to be there? Something that is implemented in NSActionCell? Well, scratch that. I just tried using NSActionCell again, and I still get the binder warning. I must have messed up my testing the last time around. Looks like it needs to be an NSTextFieldCell. -Dave ___ 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: KVO notifications and threads
On Jul 14, 2008, at 10:59 PM, Ron Lue-Sang wrote: The argument I'm trying to make is that you, as the app implementor, have everything you need to do what you mean and do it correctly. Imagine this (this is kinda long winded, so buckle up): - You have a view bound to property foo of DataObject. - You also have WorkerObject bound to property foo of DataObject - You have the same view bound to a property bar of WorkerObject which depends on DataObject.foo - WorkerObject is doing it's work with DataObject in a background thread, and the view is drawing in the main thread Okay, following... In the scenario you're asking for, DataObject.foo changes and the view bounces the KVO notification over to the main thread. // // for anyone reading who doesn't realize, this would really mean doing // [self performSelectorOnMainThread:@selector(observeValueForKeyPath:…)… ], and forwarding the method arguments. // Now WorkerObject gets the notification (again, observeValueForKeyPath gets invoked), and it changes it's bar property. This happens in the same thread that the change to DataObject happened. So it could happen before the main thread gets a chance to run and handle that performSelectorOnMainThread call earlier (assuming no wait). But the bar property KVO notification needs to be bounced to the main thread, too, otherwise the view bound to bar gets notified on a background thread, as well. Thus, if the bar notification gets bounced to the main thread, it'll happen after DataObject.foo's notification. Note: I'm assuming that calls to performSelectorOnMainThread: with no wait are queued up in the order they are called. But the behaviour or contents of the bound view depends on BOTH DataObject.foo and WorkerObject.bar. Does the order in which these notifications arrive make a difference? Maybe. AppKit would never know, and the ordering would be indeterminate. So this wouldn't work. What would be a better way to do this? Coalesce the notifications on the background thread yourself. Post both notifications, or just one über notification, in just the order you need. Then, this (sorta contrived) example would work with your KVO-bouncing AppKit, right? Well, it would also work great with our existing regular AppKit too. Because what you meant to happen isn't obvious, so you didn't leave it up to AppKit to infer. Does that make sense? Sort of... I see the point you are making, but the one issue I see is: How do you coalesce KVO notifications? As an object being observed, you have no control over when the KVO notifications are sent. In DataObject's case, the KVO notifications get sent automagically when setFoo: is called. The only way to control which thread the notifications get sent on is to call setFoo: on the desired thread. Thus when WorkerObject calls [DataObject setFoo:], in order to guarantee the notification happens on the main thread, it has to call setFoo: using performSelectorOnMainThread:. Otherwise the KVO notification will get delivered to the bound view on the background thread. Another possibility is to have have another @property option which forces that property to only be updated on the main thread. Or maybe just have the willChange/didChange happen on the main thread. I'm not sure it would make sense to treat the main thread so specially in Foundation/ObjC API. I think this encourages the wrong kind of laziness. Exactly. Plus, I typically restrict my model classes (CoreData or otherwise) to Foundation APIs so that they could be re-used in a non- AppKit application (say, for a command line app or daemon). Putting main thread special cases inside model objects breaks the MVC. Or finally, maybe NSController should take care of bouncing model KVO notifications to the main thread. This wouldn't help in all cases, like when you create your own non- NSController controller. You'd be back to doing what everyone has already suggested - take care of this in your own controller code. The problem is that often you don't have any of your own controller code, when bindings are used: You use one of the NSControllers to mediate between the view and model directly. -Dave ___ 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: KVO notifications and threads
On Jul 11, 2008, at 2:36 PM, Bill Bumgarner wrote: If you have specific enhancement requests, please file a bug via http://bugreporter.apple.com . If your request is make MVC and KVO play nicely with threads, you will need to provide details on exactly what you mean -- exactly how that is to be achieved. I've got a bug filed along these lines: rdar://5953181 (mistakenly filed under OS X Server :/). The main times I've come across this problem is when I want to show the progress of a background operation by binding some property to a progress indicator. Thus, instead of doing this: self.progress = newProgress; I resort to setting progress on the main thread using performSelectonOnMainThread: + no wait, similar to Clark's suggestion. I figure not waiting allows the background thread to continue to maintain decent concurrency. [1] I'm not sure of the best way to make threads + Cocoa bindings play nice. My current thinking is to have AppKit bounce all KVO notifications over to the main thread. It could use NSThread's isMainThread to conditionally bounce the notification to the main thread. It could even coalesce notifications, as Ben suggested. Another possibility is to have have another @property option which forces that property to only be updated on the main thread. Or maybe just have the willChange/didChange happen on the main thread. Or finally, maybe NSController should take care of bouncing model KVO notifications to the main thread. My gut tells me this should be done in AppKit. The model and the view should be completely isolated from each other. Forcing the model to so stuff on the main thread because the view (i.e AppKit) is not thread safe seems like breach of MVC. If AppKit is not thread safe, then AppKit should be responsible for not crashing in the face of threads. Making AppKit thread is not at all the right solution, but bouncing KVO notifications seems to be a decent one. While it may be a performance bottleneck, it's certainly better than nondeterministic crashing, which is what we get with the current behavior. I can always Shark it to improve performance, which I'd rather do than hunt down some non-100%-reproducible crasher. -Dave [1]: I've written a little helper to make performing on the main thread a little easier, especially when dealing with primitive types: http://www.dribin.org/dave/blog/archives/2008/05/22/invoke_on_main_thread/ Thus, you can write: [[self dd_invokeOnMainThread] setProgress:newProgress]; without having to box up newProgress as an NSNumber. It's done for you by forwardInvocation:. ___ 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: Can I use NSString classes SYNCHRONOUSLY?
On May 14, 2008, at 10:22 AM, [EMAIL PROTECTED] wrote: I'm reading up on NSStream; where delegation is used for Asynchronous process. However, I need Synchronous processing. NSInputStream isn't asynchronous + delegate for reading (are you confusing it with another class?), but it's still a pain to read until EOF. Check out dd_readUntilEndOfStream I used on a previous project (MIT license): http://ddribin.googlecode.com/svn/trunk/nsurl/NSInputStream+DDExtensions.m -Dave ___ 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: Can I use NSString classes SYNCHRONOUSLY?
On May 14, 2008, at 5:11 PM, Jens Alfke wrote: On 14 May '08, at 10:03 AM, [EMAIL PROTECTED] wrote: Essentially I want to mimic the Java HTTPConnect example I gave. I also want to be able to change the request property to POST, as in the Java equivalent: connection.setRequestMethod(HttpConnection.POST); If you're doing HTTP, use NSURLConnection instead of trying to re- invent your own HTTP support on top of the basic stream classes. It has a class method that does synchronous requests. Agreed. You can use -[NSMutableURLRequest setHTTPMethod:] to use POST. -Dave ___ 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: Keys dependent on NSArrayController's selection
On May 7, 2008, at 6:58 PM, Sean McBride wrote:
Have you put a breakpoint in 'canEnableButton'? When
'peopleController.selectionIndexes' changes, do you hit the
breakpoint?
I suspect not.
Nope. Well, it does get called once at app startup, but not as the
selection changes.
The docs for keyPathsForValuesAffectingValueForKey say
keyPaths are ok, but mmalc has mentioned on this list provided that
the
path doesn't include to-many relationships. This appears to be
true in
your case, so probably explains it. The docs don't mention this
caveat. :(
I don't believe this falls under the to-many case. That would be
doing something like observing arrangedObjects.firstName to watch
when any first name in the array changes. That is not supported. You
have to observer every object in the array. For kicks, I did try
peopleController.selectionIndex as well as
peopleController.selectedObjects to no avail.
Also, I seem to remember reading that doing willChange/didChange
back-to-
back without actually changing anything is a no-no. You might check
the
archives to confirm my shoddy memory.
Unfortunately, my search foo must be weak. Searching on {will/
did}ChangeValueForKey turns up way to many hits.
-Dave
___
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: F-Script Anywhere can't add to procmod group
On May 8, 2008, at 7:31 PM, David Carlisle wrote: I'm trying to install F-Script Anywhere, but it can't install my developer account into the procmod group. It says not a known DirStatus. I don't speak Unix, but I tried finding some terminal commands on the internet for installing a user into the procmod group via terminal, but I can't find the right command. For example, in one case Terminal responded that niutil was not recognized, so that command must be outdated. Any suggestions? I have an Intel iMac with OS 10.5.2. F-Script Anywhere version 1.3.2. I note F-Script is often recommended here for analyzing Cocoa programs. procmod and niutil are only needed for 10.4 on Intel. Use Robert Chin's FSA, Leopard Edition: http://osiris.laya.com/blog/?p=24 It uses code signing for the deprecated procmod group. It's only version 1.3.1, though. Where did you find version 1.3.2? -Dave ___ 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]
Keys dependent on NSArrayController's selection
Hi All,
I feel like I'm missing something basic here. Say I have a table
bound to an array controller. And also say that each item in the
array controller is a Person with firstName and lastName properties.
Now say, I want to have a button that is only enabled when a Person
with last name beginning with D is selected. In my controller class:
@interface MyController : NSObject {
IBOutlet NSArrayController * peopleController;
}
@property(readonly) BOOL canEnableButton;
@end
In Interface Builder I bind the button's Enabled to
MyController.canEnableButton. The implementation for
canEnableButton is this:
- (BOOL)canEnableButton {
NSArray * selectedPeople = [peopleController selectedObjects];
if ([selectedPeople count] 1)
return NO;
Person * selectedPerson = [selectedPeople objectAtIndex:0];
return [selectedPerson.lastName hasPrefix: @D];
}
Of course, canEnableButton is now dependent on the selection of
NSArrayController. Thus, I added this:
+ (NSSet *)keyPathsForValuesAffectingCanEnableButton {
return [NSSet setWithObjects:
@peopleController.selectionIndexes, nil];
}
However, this does not trigger the button to update when the selection
changes. I've got two workarounds, neither of which I really like.
I'm wondering if there's a better way.
Number 1
In awakeFromNib:
[peopleController addObserver:self
forKeyPath:@selectionIndexes
options:0
context:SelectionIndexesContext];
In observeValueForKeyPath:ofObject:change:context:
if (context == SelectionIndexesContext)
{
[self willChangeValueForKey:@canEnableButton];
[self didChangeValueForKey:@canEnableButton];
}
This works, however, it just seems wrong to use {will/
did}ChangeValueForKey: like this.
Number 2
Add this ivar to MyController:
NSIndexSet * selectionIndexes;
Bind the array controller's Selection Indexes to MyControler.
selectionIndexes. And add this to the implementation:
+ (NSSet *)keyPathsForValuesAffectingCanEnableButton {
return [NSSet setWithObjects: @selectionIndexes, nil];
}
Again, this works, but it seems silly to create an instance variable
that I don't ever use.
Are there any other alternatives that I'm missing?
Thanks,
-Dave
___
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]
