Re: Observing edits make to a table using bindings
Is it possible [with KVO] to know exactly which array element was
edited, without
registering observers on the entire contents of the array? I figure
it has something to do with the keyPath, but the exact something has
thus far eluded me.
As I see it, there are several ways to get around your problem. The
limits of KVO you are bumping into were probably a good design
decision, but I sympathize! It can sure be annoying.
The "most correct" way IMHO would be to change your model element
class from NSMutableDictionary to your own class, building whatever
logic you want right into it. Not only does it make the MVC gurus here
happy, it saves you from KVO voodoo and its inherent pitfalls/
opaqueness/performance issues. KVO is awesome, but only in moderation
when combined with MVC. Without further ado, here is a demonstration
(you would put "MyKeyValuePair" in the "Class Name" field of
NSArrayController in IB):
@class MyKeyValuePair /*Change the name!*/ {
NSString* name;
NSString* value;
}
@property (copy) NSString* name;
@property (copy) NSString* value;
@end
@implementation MyKeyValuePair
@synthesize name;
@synthesize value;
- (void)setValue:(NSString*)str {
//Do stuff here
}
@end
You could also roll your own controller (by subclassing NSArray
controller or making your own data source). This would be in defiance
of MVC: MVC predicts that fusing controller and model is a path to
failure. I tend to agree. Apple agrees too: their "dumb default" model
is dumb for precisely that reason. Use your own judgement, but I'd shy
away from controller-model unification at the first sign of trouble.
Now, how much cleaner is the MyKeyValuePair class than a glob of KVO
code replete with cryptic options, behind the scenes voodoo, and long
method calls?
:)
-
Jonathan deWerd
http://dew0rd.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: including a cocoa bundle in a carbon app
On Aug 10, 2008, at 5:39 PM, Uli Kusterer wrote: On 10.08.2008, at 19:38, Bob Sabiston wrote: I got my Cocoa bundle to compile on the Intel machine. It still doesn't load within my app, though. Is there something special I need to do to include it in my project? I just dragged it in on the left, amongst all the other types of files, and it gave me a menu of targets from which I selected the correct one. But the load is still failing. I'm using the function below, gotten from Apple's examples. Anyone know what could be the problem? CFBundleCreate is just setting bundlePtr to 0, I don't know why. I've done stuff like that and it worked fine for me (heck, I've loaded CFM bundles into Mach-O apps). What template did you use as a basis for your bundle? You keep saying bundle, but the variable names mention frameworks. Now, there are different ways of building stuff like that. E.g. frameworks contain a path they expect to be loaded at (installation path setting), while bundles as they're used for plugins generally don't. Did you perhaps mix those up? Alternately, are you perhaps mixing debug and release builds? Anything not 100% homogeneous in there? A bundle shouldn't be dragged in on the left in XCode (a framework should). You *might* be getting a bundle already loaded error if that's the case. Try using loadAndReturnError: or CFBundleLoadExecutableAndReturnError (which seems like it doesn't just load executable bundles, aka applications?) to determine what the exact problem is. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ 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/jjoonathan %40gmail.com This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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: compiling a bundle on intel?
On Aug 9, 2008, at 5:22 PM, Bob Sabiston wrote: Hi, I have a Cocoa bundle that I compile with my Carbon program. I used the Apple examples to do it, and I don't have a very thorough understanding of Cocoa or bundles. However, on my G5 w/ Codewarrior compiling (still!), it actually works. I have to compile the bundle using Xcode, but the rest of the app I compile in Codewarrior, just including the bundle as a library. Whoa, it's Bad Karma to mix binaries from two different compilers. It should work, but in my experience it's best to go with a single compiler for everything, be it codewarrior, gcc, gcc-llvm, or whatever the latest popular compiler happens to be. Good job getting it working thus far, and good luck for the future... However, lately I am compiling the whole thing with Xcode on Intel machines, Yay! and today I noticed that my Cocoa Window won't load. I opened the separate little bundle project to try compiling an Intel version, and it opens but the 'Build and Go' button is greyed out. What would cause this? On the G5 I've got Xcode 2.41, whereas on the Intel I've got 3.1. What do I need to do to compile the bundle project on Intel? Are both the build and the build-and-go buttons grayed out? If the build button still works (but not the 'go' button and hence not build +go), the problem is that you have xcode making a bunch of object files but you haven't defined how it should turn those into an executable. Probably the best way to do that would be to make a new carbon project, then import your code into it. Crude, but it's a quick fix if you don't want to mess with targets and custom executables. If that isn't the problem, then try looking at the compilation settings and comparing them to Apple's examples. If you *do* want to mess with targets and custom executables (or magically generated executables), IIRC there is some fairly extensive reading on those subjects in the xcode manual. Thanks Bob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jjoonathan %40gmail.com This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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: I don't understand why this is leaking...
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
This code is leaking:
- (void)saveItemExtensions:(id)sender
{
NSMutableString* itemExtensionsFilePath = [NSMutableString
stringWithString:@"~/Library/Preferences/MyApp/extensions.abc"];
NSDictionary* extensions = [NSDictionary dictionaryWithDictionary:
[itemDataSource itemExtensions]];
[itemExtensionsFilePath setString:[itemExtensionsFilePath
stringByExpandingTildeInPath]];
[[NSArchiver archivedDataWithRootObject:extensions]
itemExtensionsFilePath atomically: YES];
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject: string1];
[coder encodeObject: string2];
[coder encodeObject: string3];
[coder encodeObject: string4];
[coder encodeObject: string5];
[coder encodeObject: string6];
[coder encodeObject: string7];
[coder encodeObject: string8];
}
According to MallocDebug, the leak is in the encodeWithCoder method.
Things I've tried:
1 [coder encodeObject: [string1 autorelease]]; Which, of course,
caused a crash
2 [coder encodeObject: [string1 copy]]; no diff
3 [coder encodeObject: [[string1 copy] autorelease]]; no diff
4 Drinking beer...
Can anyone explain this to me?
Tony
What is coder? It could be that coder is deferring the encoding
(saving copies of string*), and then the coder itself is never getting
released. Have Instruments make sure that the coder is actually going
away after the encoding is done. Also check to make sure the encoded
data is going away when it is no longer needed. Sometimes the leak
isn't exactly where MallocDebug says the object was allocated: -retain
increments the retain count as surly as -alloc. What do the individual
string* histories look like in Instruments? Speaking of Instruments,
could you give us (not the mailing list, I don't think it allows
attachments, but you could email me separately) an instruments session
to look at? It would greatly facilitate proceedings :)
Also, why are you using non-keyed encoding? -encodeObject:forKey: is
the preferred way of doing things nowadays...
___
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/jjoonathan
%40gmail.com
This email sent to [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
___
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: Modules in Objective-C like e.g. OSGi-Bundles in Java
On Aug 7, 2008, at 5:31 PM, Lars Sonchocky-Helldorf wrote: Am 07.08.2008 um 21:45 schrieb Matthias Luebken: Hi I'm new to Cocoa and Objective-C. Please point me to a different group / forum if this mailing-list isn't appropriate. I have a fairly basic language question: Is there a module concept in Objective-C / Cocoa? I'm thinking in terms of OSGi bundles[0]. What would I do if I would like to encapsulate a certain functionality that consists of several classes? Could I define an API how to use this module and make sure private classes of this module aren't visible to the outside? Thanks in advance. Looking forward to learn Obj-C and Cocoa Matthias [0] http://www.osgi.org/About/Technology#Framework see: http://www.google.com/search?ie=utf8&oe=utf8&q=NSBundle first hit (and links therein) regards, Lars I'm not sure if this is what he was asking for – NSBundle doesn't offer the level of encapsulation that OSGi would. All classes are still loaded into the flat namespace, and every function and byte of memory in the process that loads the bundle is available for the bundle's code to access. The only way I am aware of to get "private" functionality would be to prefix each classname with something unique like the reverse DNS system that's so popular with the kernel programmers. Unless there is a way to automatically isolate loaded classes... I'd love to hear it. Magic dyld options are useful to know about :) ___ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([EMAIL PROTECTED]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/objc-language/jjoonathan%40gmail.com This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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: Modules in Objective-C like e.g. OSGi-Bundles in Java
On Aug 7, 2008, at 1:45 PM, Matthias Luebken wrote:
Hi
I'm new to Cocoa and Objective-C. Please point me to a different group
/ forum if this mailing-list isn't appropriate.
I have a fairly basic language question: Is there a module concept in
Objective-C / Cocoa? I'm thinking in terms of OSGi bundles[0]. What
would I do if I would like to encapsulate a certain functionality that
consists of several classes? Could I define an API how to use this
module and make sure private classes of this module aren't visible to
the outside?
Thanks in advance.
Looking forward to learn Obj-C and Cocoa
Matthias
[0] http://www.osgi.org/About/Technology#Framework
No, there is no module system in ObjC, and there is no concrete way to
make methods private. We believe in convention over regulation: it
makes dealing with exceptional cases that much easier.
Class names are prefixed by (usually) two letter codes that identify
the developer or the project. These are remarkably effective at
avoiding name conflicts, the idea being that if your identifier +
classname isn't unique then you should really be extending the other
person's class or renaming yours more specifically. If you were really
pedantic I guess you might even give your classes a reverse DNS prefix
and use macros for convenience.
Similarly, there are no private methods. Convention, however, makes
anything starting with underscores private. You can also add a
category whose interface is only visible inside your implementation
file. That being said, if you really really want private methods, I
would suggest defining C-like functions (static, inline, or prefixed
with the class name to avoid conflict) inside your @implementation:
they can access private variables without warning, like so:
@interface FooClass : NSObject {
int _myVariable;
}
- (void)plusPlus;
@end
//In your .m or .mm file
@implementation FooClass
inline incrementVariable(FooClass* self, int incBy) {
self->_myVariable += incBy;
}
- (void)plusPlus {
incrementVariable(self,1);
}
@end
The overriding philosophy here is that a little verbosity
simultaneously avoids conflicts and makes code more understandable,
while not significantly impacting typing time (this is the age of auto-
complete and tab-triggers, after all). If you're trying to implement a
security system (ala OSGi) that tries to sequester code within a
native process, you're playing a loosing game: since the process is
native, every piece of code has access (however indirect) to every
piece of memory and code within the process. If you really wanted to,
you might be able to mess with the EMMI (see the Kernel Programming
Guide) enough to change that, but it'd be a chore.
In the OSX (and UNIX) security model, you sandbox things at the
process level. If you want your program to make a privileged
modification of the system, for instance, you would probably make a
small command line utility and include it in your app. You then
authorize the utility (through the infamous lock dialog) and call it
from your program to do what you want. You might use IPC (through mach
or the cocoa IPC mechanism) if you need to control a multi-step
privileged subprogram.
If you want to run constrained plugins, you might look into a
scripting language that was designed for such considerations, and
provide proxies that only allow access to certain parts of the parent
program.
Sorry if I got derailed on security: your message does'n mention it
but your link does. In any case, I hope this information was helpful.
___
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/objc-language/jjoonathan%40gmail.com
This email sent to [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
___
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: Command Line Argument - Choosing a Style
I would make plugins of a different type: standard cocoa bundles (there are a handful of tutorials on google). This way, people could install and uninstall using the finder (a little known but helpful feature of the info box), you could use standard cocoa APIs, you wouldn't have to deal with the overhead of spawning a new process, and you could provide a template to get devs started. Then I'd just pass configuration info in a dictionary. If that isn't an option, I would pass a bunch of --key value pairs to retain some semblance of standard-ness :) On Aug 6, 2008, at 4:33 PM, hac wrote: Hi, I'm developing an application to support third-party extensions that filter text. Each filter consists mainly of a property list and an executable. The idea is that the text of the current document goes into the executable along with settings specified in the property list (as arguments); text to replace the document text comes out as the standard output. Right now I am stuck trying to decide how I should pass both the document text and the settings to the executable. I see three options: 1. Have the first argument be the document text, and the second an XML string containing the settings as key-value pairs. 2. Have the first argument be the docucument text, the second a setting key, the third a setting value, the fourth a setting key, etc... 3. Have the first argument be the docucument text, have each successive argument be a setting value, in an order specified in the property list so as to determine the key for each. I can easily set up the application to support any of these methods. My problem is that each one seems to have some inconveniences for the developer of the filter, and I would like to make this as convenient as possible for anyone who makes a filter. Could someone tell me which method would be the most appropriate? 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/jjoonathan %40gmail.com This email sent to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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: remove elements during the iteration on NSMutableDictionary
On Aug 6, 2008, at 10:49 AM, Andrew Merenbach wrote:
On Aug 6, 2008, at 9:30 AM, Roland King wrote:
for (id theKey in aDictionary) {
id anObject = [[aDictionary objectForKey:theKey] retain];
[aDictionary removeObjectForKey:theKey];
// Question: will this removal break or corrupt the loop of
enumerating the
elements?
[anObject someMessage];
[anObject release];
}
Oops, I diid not see that, sorry.
Yup, that works. I prefer:
[id anObject = [[aDictionary objectForKey:theKey] retain]
autorelease];
That allows breaks inside the loop. (And you do not forget the -
release, as you did.)
Amin
or send it a message before you remove it from the dictionary.
for( id theKey in aDictionary ){
id anObject = [[ aDictionary objectForKey:theKey ];
[ anObject someMessage ];
[ aDictionary removeObjectForKey:theKey ];
}
of course as the original response pointed out, you can't really do
this anyway as the modification will cause an exception so you
don't really have the problem, you can't really remove the object
where you're removing it.
One question I had, the mutable guard which raises the exception,
that's only there because of the use of fast-enumeration, am I
right? Had you used an NSEnumerator I believe it's still not safe
to remove objects, but I don't think you get the exception, you
just need to know you mustn't do
it.___
May I suggest the following?
-
NSMutableArray *keysToRemove = [NSMutableArray array];
for (id theKey in aDictionary) {
[keysToRemove addObject:theKey];
}
[aDictionary removeObjectsForKeys:keysToRemove];
You can even use -[NSDictionary objectsForKeys:notFoundMarker:] to
send a single message to the dictionary's objects using -
makeObjectsPerformSelector:
Cheers,
Andrew
You could also use performSelector:withObject:afterDelay: assuming
that you'll reenter the run loop before you need the objects removed.
___
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/jjoonathan
%40gmail.com
This email sent to [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
___
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: Using performSelector: on super
The solution I would use would be to implement a category on super's
class, or rename the method (probably the best option from a design
standpoint). For instance, suppose we have (stretching the objc syntax
a bit)
@implementation FooClass
- (void)sayHi {
NSLog(@"Hi");
}
@end
@implementation BarClass : FooClass
- (void)sayHi {
NSLog(@"Hi there! I am BarClass.");
}
@end
And we have
BarClass* bar = [[BarClass alloc] init];
Then [bar sayHi]; will log "Hi there! I am BarClass". If we want to
call its super's method, then we can implement a category like so
(assuming you don't have the code to FooClass's implementation: if you
do, just change it):
@implementation FooClass (MethodAliasing)
- (void)sayOriginalHi {
static IMP originalHi = nil;
if (!originalHi) originalHi = [FooClass
instanceMethodForSelector:@selector(sayHi:)];
originalHi(self, @selector(sayHi:) /*, additional, args, would, get,
forwarded, here*/);
}
@end
Then you can call (or you can have NSRunLoop call) sayOriginalHi: .
This little hack should be compatible with most living variants of
ObjC that you are likely to encounter (it only uses Apple's official
API after all).
This being said, I will reiterate my suggestion that you look at your
design again. The fact that you are calling super's methods outside of
one of your own (or you are having the run loop do it for you)
indicates that perhaps that method of super should have remained
exposed, and instead of overriding it your subclass should provide an
entirely new method.
smime.p7s
Description: S/MIME cryptographic signature
___
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]
