Re: Send msg to object by nameed NSString;
On Jun 18, 2014, at 4:54 PM, Graham Cox graham@bigpond.com wrote: On 19 Jun 2014, at 4:53 am, Daniel DeCovnick danhd...@mac.com wrote: Yes. You can either use key-value coding: [[self valueForKey:myString] release]; [value release]; These invocations of -release appear to be erroneous. Why do you have them there? If you think they should be there as a matter of routine, your understanding of memory management is probably faulty. I'm following the example in the original message: [myNumber release]; I could do something like: [getProperty(myString) release]; Your first thought is I don’t know memory management? That’s really not very charitable of you. Back on topic: I would think 'copy' would still be ok with this (for example in the case of NSStrings) since that should still be released. For 'assign' I can see the advantage. It’s not just an advantage, it’s avoiding a crasher, most likely, and where it’s not, it’s avoiding silently corrupting an object graph. [(id)someInt release] is not a message you want to ever find yourself sending. So this would be better? for (NSString* key in [self propertyKeys]) [self setValue:nil forKey:key]; No, because unless you also override -setNilValueForKey: for your classes that do this, you will raise an NSInvalidArgumentException. If you are relying on synthesizing the actual ivar, not just the setters/getters, you have little choice, though apparently you can rely on the ivar being the name of the property with a leading underscore. I dislike that sort of hidden magic however. Implicit synthesis creating an ivar with a leading underscore is well documented and hardly hidden magic. Declare your ivars for synthesized properties or don’t, they’ll be available either way, with a leading underscore if implicit synthesis is used, without if an explicit @synthesize is used. Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bindings setup with NSCollectionViews
Thanks. That did it ! On Thu, Jun 19, 2014 at 6:07 PM, Willeke willeke2...@gmail.com wrote: Bind the Selection Indexes of the master collection view to selectionIndexes of the BoardArrayController. I would bind the Contents of the detail collection view to arrangedObjects of the ListArrayController. Willeke Op 18 jun 2014, om 03:40 heeft Hajder Rabiee het volgende geschreven: Hi all I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration Thank you -- Med vänliga hälsningar / Best Regards Hajder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/willeke2007%40gmail.com This email sent to willeke2...@gmail.com -- Med vänliga hälsningar / Best Regards Hajder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
On 20 Jun 2014, at 7:13 pm, Daniel DeCovnick danhd...@mac.com wrote: No, because unless you also override -setNilValueForKey: for your classes that do this, you will raise an NSInvalidArgumentException. That's not the case for object properties, only for scalar properties. It's perfectly fine to pass nil as the value to an object property, and if it's a 'retain' or 'copy' property, it will release the old value. Your first thought is I don’t know memory management? That’s really not very charitable of you. Really? Even though I asked why, included a conditional and hedged with a 'probably'? Your reading of my comment doesn't seem very charitable. In any case I was only responding to the code as you'd written it. Repeating an error from some earlier code is a bit of a strange thing to do. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
I would think 'copy' would still be ok with this (for example in the case of NSStrings) since that should still be released. For 'assign' I can see the advantage. It’s not just an advantage, it’s avoiding a crasher, most likely, and where it’s not, it’s avoiding silently corrupting an object graph. [(id)someInt release] is not a message you want to ever find yourself sending. So this would be better? for (NSString* key in [self propertyKeys]) [self setValue:nil forKey:key]; No, because unless you also override -setNilValueForKey: for your classes that do this, you will raise an NSInvalidArgumentException. None of my properties are ints, doubles, longs or any other non-object type. This class is really a replacement for just using an NSMutableDictionary to store this stuff. All the properties are NSNumber, NSString or NSColor Trygve ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSReleasePool issue
My main() looks like this. Does yours specify an autorelease pool?
int main(int argc, char* argv[])
{
@autoreleasepool
{
return UIApplicationMain(argc, argv, nil,
@MyDelegateClassName);
}
}
On Jun 19, 2014, at 5:45 PM, Varun Chandramohan varun.chandramo...@wontok.com
wrote:
I was playing around with OBJ_DEBUG_MISSING_POOL env variable and set it to
YES. I was able to debug most of the issues in my code where I missed auto
release pools. This is the last one remaining. However I am not sure where
the leak is happening. It looks like NSApplicationMain, do that also need
this auto release pool?
objc[26109]: MISSING POOLS: Object 0x618410e0 of class NSUserDefaults
autoreleased with no pool in place - just leaking - break on
objc_autoreleaseNoPool() to debug
(lldb) bt
* thread #1: tid = 0x3d3c5f, 0x7fff91da8604
libobjc.A.dylib`objc_autoreleaseNoPool, queue = 'com.apple.main-thread', stop
reason = breakpoint 1.1
frame #0: 0x7fff91da8604 libobjc.A.dylib`objc_autoreleaseNoPool
frame #1: 0x7fff91d95488 libobjc.A.dylib`(anonymous
namespace)::AutoreleasePoolPage::autoreleaseSlow(objc_object*) + 72
frame #2: 0x7fff91da8781
libobjc.A.dylib`_objc_rootAutorelease2(objc_object*) + 75
frame #3: 0x7fff895528a3 AppKit`_NSGetBoolAppConfig + 85
frame #4: 0x7fff89571566 AppKit`-[NSApplication
_installMemoryPressureDispatchSources] + 161
frame #5: 0x7fff89565861 AppKit`-[NSApplication run] + 206
frame #6: 0x7fff895507a3 AppKit`NSApplicationMain + 940
* frame #7: 0x00012022 TOS`main(argc=3, argv=0x7fff5fbffa90) +
34 at main.m:13
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSReleasePool issue
Given the backtrace, I'd say the OP is using Mac OS, not iOS. I just created a
new project in Xcode, and main() looks like this on OS X:
int main(int argc, const char * argv[])
{
return NSApplicationMain(argc, argv);
}
On Fri, 20 Jun 2014 09:32:48 -0700, Steve Christensen said:
My main() looks like this. Does yours specify an autorelease pool?
int main(int argc, char* argv[])
{
@autoreleasepool
{
return UIApplicationMain(argc, argv, nil,
@MyDelegateClassName);
}
}
On Jun 19, 2014, at 5:45 PM, Varun Chandramohan
varun.chandramo...@wontok.com wrote:
I was playing around with OBJ_DEBUG_MISSING_POOL env variable and set
it to YES. I was able to debug most of the issues in my code where I
missed auto release pools. This is the last one remaining. However I am
not sure where the leak is happening. It looks like NSApplicationMain,
do that also need this auto release pool?
objc[26109]: MISSING POOLS: Object 0x618410e0 of class
NSUserDefaults autoreleased with no pool in place - just leaking - break
on objc_autoreleaseNoPool() to debug
(lldb) bt
* thread #1: tid = 0x3d3c5f, 0x7fff91da8604
libobjc.A.dylib`objc_autoreleaseNoPool, queue = 'com.apple.main-thread',
stop reason = breakpoint 1.1
frame #0: 0x7fff91da8604 libobjc.A.dylib`objc_autoreleaseNoPool
frame #1: 0x7fff91d95488 libobjc.A.dylib`(anonymous
namespace)::AutoreleasePoolPage::autoreleaseSlow(objc_object*) + 72
frame #2: 0x7fff91da8781 lib
objc.A.dylib`_objc_rootAutorelease2(objc_object*) + 75
frame #3: 0x7fff895528a3 AppKit`_NSGetBoolAppConfig + 85
frame #4: 0x7fff89571566 AppKit`-[NSApplication
_installMemoryPressureDispatchSources] + 161
frame #5: 0x7fff89565861 AppKit`-[NSApplication run] + 206
frame #6: 0x7fff895507a3 AppKit`NSApplicationMain + 940
* frame #7: 0x00012022 TOS`main(argc=3,
argv=0x7fff5fbffa90) + 34 at main.m:13
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Advice on document handling
On 2014 Jun 19, at 22:15, John Brownie john_brow...@sil.org wrote:
Looks like I need to keep a local flag for when the document gets changed and
when it gets saved.
No, you can just use -[NSDocument isDocumentEdited].
Back when Auto Save first appeared, in OS X 10.7, I too found that it was
pestering me too often with autosaves when nothing had changed. Fortunately,
such nuisance autosaves seem to always be cancelable, so it’s easy to fix by
overriding -autosaveWithImplicitCancellability:completionHandler:, like this…
-
(void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable
completionHandler:(void (^)(NSError
*errorOrNil))completionHandler {
if (autosavingIsImplicitlyCancellable) {
if (![self isDocumentEdited]) {
// Cancel it.
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
code:NSUserCancelledError
userInfo:nil]) ;
return ;
}
}
… Here, I add a save operation to my document's operation queue.
… If you don't save that way, probably just invoke super here.
}
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Advice on document handling
On Fri, Jun 20, 2014, at 10:33 AM, Jerry Krinock wrote: On 2014 Jun 19, at 22:15, John Brownie john_brow...@sil.org wrote: Looks like I need to keep a local flag for when the document gets changed and when it gets saved. No, you can just use -[NSDocument isDocumentEdited]. Back when Auto Save first appeared, in OS X 10.7, I too found that it was pestering me too often with autosaves when nothing had changed. As per the documentation, the first thing that -[NSDocument autosaveWithImplicitCancellability:…] does is send -hasUnautosavedChanges to itself and bail if that method returns NO. So I don't see what advantage you gain by overriding this method to check -isDocumentEdited, unless you have somehow broken the relationship between -isDocumentEdited and -hasUnautosavedChanges. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: supportedInterfaceOrientations in Swift
On Jun 19, 2014, at 5:39 PM, Roland King r...@rols.org wrote:
On 20 Jun, 2014, at 5:04 am, Greg Parker gpar...@apple.com wrote:
override func supportedInterfaceOrientations() - Int
{
}
which makes some sense. I'm tripping over myself trying however to return
the correct Int without casting my casts to casts of casts.
Please file a bug report. -supportedInterfaceOrientations should be declared
to return UIInterfaceOrientationMask, not Int. This sort of loose typing
works in C but not in Swift.
OK I've filed (rdar://17387641) - although in this case I'm not sure it would
have made life much better as the constructor takes a UInt the best I would
have been able to do is
return UIInterfaceOrientationMask(
UIInterfaceOrientationMask.Portrait.value +
UIInterfaceOrientationMask.PortraitUpsideDown.value )
which isn't much prettier. I do agree however that returning a
UIIntefaceOrientationMask would be semantically better and it's not hard to
define the '+' and '|' operators on them myself to do the right thing which
would lead to
return UIInterfaceOrientationMask.Portrait +
UIInterfaceOrientationMask.PortraitUpsideDown
which would be very nice (and i suggested in the radar)
The | operator should already work with UIInterfaceOrientationMask and anything
else declared with NS_OPTIONS in Objective-C headers. It would look like this
if -supportedInterfaceOrientations returned UIInterfaceOrientationMask:
override func supportedInterfaceOrientations() - UIInterfaceOrientationMask {
return UIInterfaceOrientationMask.Portrait |
UIInterfaceOrientationMask.PortraitUpsideDown
}
…which is perfectly fine.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Advice on document handling
On 2014 Jun 20, at 10:53, Kyle Sluder k...@ksluder.com wrote: As per the documentation, the first thing that -[NSDocument autosaveWithImplicitCancellability:…] does is send -hasUnautosavedChanges to itself and bail if that method returns NO. I don’t know, Kyle. Indeed, I’ve done more than my share of pushing into the envelope of NSDocument black magic. Maybe this is patching for something else I did, or maybe -isDocumentEdited is more strict than -hasUnautosavedChanges. But it works, and I’m not going to touch it again until Apple breaks 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Advice on document handling
Jerry Krinock wrote:
On 2014 Jun 19, at 22:15, John Brownie john_brow...@sil.org wrote:
Looks like I need to keep a local flag for when the document gets changed and
when it gets saved.
No, you can just use -[NSDocument isDocumentEdited].
Back when Auto Save first appeared, in OS X 10.7, I too found that it was
pestering me too often with autosaves when nothing had changed. Fortunately,
such nuisance autosaves seem to always be cancelable, so it’s easy to fix by
overriding -autosaveWithImplicitCancellability:completionHandler:, like this…
-
(void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable
completionHandler:(void (^)(NSError
*errorOrNil))completionHandler {
if (autosavingIsImplicitlyCancellable) {
if (![self isDocumentEdited]) {
// Cancel it.
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
code:NSUserCancelledError
userInfo:nil]) ;
return ;
}
}
… Here, I add a save operation to my document's operation queue.
… If you don't save that way, probably just invoke super here.
}
That's not going to work for my case. I have a complex document bundle,
and I'm trying to figure out which files within the package have unsaved
changes, and it looks like there's no support for that model in NSDocument.
John
--
John Brownie, john_brow...@sil.org or j.brow...@sil.org.pg
Summer Institute of Linguistics | Mussau-Emira language, Mussau Is.
Ukarumpa, Eastern Highlands Province | New Ireland Province
Papua New Guinea | Papua New Guinea
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Advice on document handling
On Jun 20, 2014, at 16:44 , John Brownie john_brow...@sil.org wrote: I have a complex document bundle, and I'm trying to figure out which files within the package have unsaved changes, and it looks like there's no support for that model in NSDocument. I haven’t been following this thread very closely, so I may misunderstand, but there’s a fairly simple way of doing this that might work for you. The key is to *keep* the top level NSFileWrapper you’re given when opening the (multi-file) document. When creating a new one, just set the kept wrapper ivar or property to nil. When any change is made to the document (so you’d put this in the same place that creates undo actions, I guess), you determine which files within the package are/will be affected, and you *remove* the corresponding sub-wrapper from the store top level wrapper. At save time, you walk your new/intended file hierarchy, creating missing wrappers as you go. By definition, wrappers that aren’t missing represent files that haven’t changed. When you’re done, you return this revised wrapper from your save method. Because you haven’t re-created the wrappers for non-changed files, the NSDocument saving mechanism realizes that those files don’t need to be re-written and hard-links to the existing ones, typically. Thus, if your package contains 100 files but only 1 has changed, a save or autosave will be fast because only 1 file gets written and copied (from the temp save location to its final location). Is that procedure of any use to you? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Advice on document handling
___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
