Re: NSDocument's Open File Panel unresponsive when opening large file from disc
On 28 Jan 2013, at 16:46, Gilles Celli gilles.ce...@ecgs.lu wrote: Please don't be scared ;-) Well I'm little bit in a hurry … will look more closely tonight, but: What I've done til now is inside readFromURL:ofType:error: 1. Open the file and store it NSString currentFileContents 2. Process currentFileContents in a new object myDataFile (withc class DataFileParser) by extracting the data values etc. with NSScanner, this takes most time 3. return YES if everything is OK in readFromURL So I thought that then makeWindowControllers comes in action ?!... In makeWindowControllers: 1. Pass myDataFile if it's not nil create a new MainWindowController and pass myDataFile to it like mainWindowController = [[DataViewerWindowController alloc] initWithDataFile:myDataFile]; [self addWindowController:mainWindowController]; Hope this clarifies a little bit what I'm doing…well doing something wrong ….. That all sounds totally reasonable to me. The point is you're saying the open panel is making your app unresponsive. If the app's unresponsive, that means the main thread is doing too much work. So you need to get from Instruments or similar an answer to the question what is the main thread doing that takes so long? ___ 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: Deadlock in core data fetch?
On 27 Jan 2013, at 06:49, Martin Hewitson martin.hewit...@aei.mpg.de wrote:
(sent again because it was too long and got held for moderation)
Dear list,
Forgive my potential use of bad terminology and ignorance here. I'm about to
talk about concurrency in the context of core data, and I suspect I'm doing
things terribly wrong.
I have an app which does background processing of the entities in a core data
stack of an NSPersistentDocument . Sometimes I get deadlocks (I think) which,
when sampled, look like the excerpt below.
Roughly, what my app does is:
1) When a File entity is created, it creates for itself a MetaData collector
2) The MetaData collector has a timer which fires every second
3) In the timer selector, if a update is no in process, I do:
a) create a new MetaDataOperation (NSOperation subclass)
- the completion block of this operation tries to post a
notification on the main thread like this
dispatch_sync(dispatch_get_main_queue(), ^{
[blockSelf notifyOfUpdate];
blockSelf = nil;
});
b) add operation to operation queue
c) use an SyntaxChecker (which uses an NSTask) to do some other
processing of the File's content
4) When the SyntaxChecker's NSTask completes, it calls back to its delegate,
the MetaData collector, which then posts notification which is observed by a
view controller. I think this is all on the main thread. This view controller
is essentially the same as those I describe next, which handle displaying the
meta data that's gathered in the MetaDataOperation step.
5) When the MetaData collector gets the notification that an update has
completed, it then does some local state clean up and posts a notification
which is received by a number of view controllers, each of which controls the
display of different parts of the meta data. A typical handler in one of
these view controllers looks like this:
- (void) handleMetadataUpdate:(NSNotification*)aNote
{
[self performSelectorOnMainThread:@selector(updateUI) withObject:nil
waitUntilDone:NO];
}
In the updating of the UI, I do things like:
1) get the set of the relevant File entities from the view controller's
delegate
2) compare the meta data in the File entities to a local set of objects
(which hold references to their corresponding entities), and update any if
necessary
3) reload outline view
Naturally, for the sake of brevity, I've simplified the picture a little, but
not much. I believe the salient points are described.
So, now my questions and issues:
1) How can I interpret the call graph shown below? I'm finding it difficult
to extract from that who's blocking whom.
2) Is there something glaringly wrong with the strategy I sketched above? (I
guess so, since it took a lot of experimentation to get it working at all.)
From your sample, I would judge that the main thread is waiting to acquire the
persistent store coordinator's lock. The worker thread is stuck trying to
deliver a message to the main thread, which it can't because the main thread
is currently tied up.
Now, you didn't explain too much what your background operations are doing. Are
they accessing any managed objects at all? If so those managed objects
ABSOLUTELY MUST come from a separate dedicated context. You cannot access Core
Data from multiple threads without using an appropriate technique.
Also, I don't see any need for your completion block to use dispatch_sync.
Async should be fine here.
-
Call graph:
2771 Thread_4677360 DispatchQueue_1: com.apple.main-thread (serial)
+ 2771 start (in TeXnicle) + 52 [0x118e4]
+ 2771 main (in TeXnicle) + 34 [0x11912] main.m:32
+ 2771 NSApplicationMain (in AppKit) + 869 [0x7fff829dfcb6]
+ 2771 -[NSApplication run] (in AppKit) + 517 [0x7fff82a3b283]
+ 2771 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 128
[0x7fff82a43ed2]
+ 2771 _DPSNextEvent (in AppKit) + 685 [0x7fff82a44613]
+ 2771 BlockUntilNextEventMatchingListInMode (in HIToolbox) +
62 [0x7fff8a0e5cd3]
+ 2771 ReceiveNextEventCommon (in HIToolbox) + 356
[0x7fff8a0e5e42]
+ 2771 RunCurrentEventLoopInMode (in HIToolbox) + 209
[0x7fff8a0e60a4]
+ 2771 CFRunLoopRunSpecific (in CoreFoundation) + 290
[0x7fff81aaa6b2]
+ 2771 __CFRunLoopRun (in CoreFoundation) + 789
[0x7fff81aaadc5]
+ 2771 __CFRunLoopDoSources0 (in CoreFoundation) +
445 [0x7fff81a87aed]
+ 2771
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in
CoreFoundation) + 17 [0x7fff81a88101]
+
Re: Deadlock in core data fetch?
On 27 Jan 2013, at 15:04, Martin Hewitson martin.hewit...@aei.mpg.de wrote: 1) How can I interpret the call graph shown below? I'm finding it difficult to extract from that who's blocking whom. 2) Is there something glaringly wrong with the strategy I sketched above? (I guess so, since it took a lot of experimentation to get it working at all.) From your sample, I would judge that the main thread is waiting to acquire the persistent store coordinator's lock. The worker thread is stuck trying to deliver a message to the main thread, which it can't because the main thread is currently tied up. Now, you didn't explain too much what your background operations are doing. Are they accessing any managed objects at all? My managed objects have additional data caches which are properties on the NSManagedObject subclass but are not part of the core data model (is this a bad idea?). One of these data caches is an NSTextStorage which can be updated by text views. The background processes are extracting metadata from the string of the text storage. So I don't think this counts as accessing the managed object, does it? However, I do access another property on the managed object - an NSDate representing the time the text content was last edited. I use this in the background thread to help decide if it's necessary to update the metadata. I also access another boolean property which says if the managed object represents a text file. In principle, neither of these properties needs to be stored in the persistent store, and so don't need to be part of the core data model, but currently they are. Could/would just reading the values cause these issues? As long as you don't touch any modelled properties, you're within Core Data's contract. But it's very easy to do so by accident. Be careful! If so those managed objects ABSOLUTELY MUST come from a separate dedicated context. You cannot access Core Data from multiple threads without using an appropriate technique. So to process the objects in the main managed context, I should create a new one, and copy the objects I want to process into this new context, then pass the new context to the background thread? Currently I'm just passing an array of managed objects. The context is never directly accessed in the background threads. You create a new context that shares the same persistent store coordinator as your main one. If the main context has been saved, that'll both contain the same objects; you just need to use the object IDs to locate the objects in the secondary context. Alternatively, you could setup the second context to be a child of the main context. Or give them both the same parent context. In short, make sure you read the Core Data threading documentation! ___ 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: NSPointerArray on iOS - truly __weak?
On 10 Dec 2012, at 20:26, Matt Neuburg m...@tidbits.com wrote: Bump. I'd still like to hear about this. The docs have a *huge* box saying that iOS NSPointerArray is not doing __weak references, but it sure looks to me like it is. But I don't know how to test. Thanks for any help. m. On Fri, 30 Nov 2012 07:51:57 -0800, Matt Neuburg m...@tidbits.com said: The docs for NSPointerArray say, in a big bold box right at the top: Important: NSPointerArray does not support weak references under Automatic Reference Counting (ARC). However, a [NSPointerArray weakObjectsPointerArray] does NULL an element that has been released through ARC; I can test this directly, and I've also been using NSPointerArray successfully to break retain cycles. So are the docs just lying (in a big bold box right at the top), or is this some other kind of weak reference (i.e. somehow weak, but not ARC-__weak)? I spotted this elsewhere in the docs today: Starting in OS X v10.8, the Foundation framework offers the following features and enhancements: Support for zeroing weak references with enhancements to the NSMapTable, NSHashTable, and NSPointerArray classes. So I guess the regular docs just haven't been updated yet. ___ 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: NSString and file system Re: AppleScript in Sandboxed App
On 16 Jan 2013, at 17:40, Quincey Morris quinceymor...@rivergatesoftware.com
wrote:
On Jan 16, 2013, at 09:12 , jonat...@mugginsoft.com
jonat...@mugginsoft.com wrote:
To be honest I rarely remember to call -fileSystemRepresentation.
The docs seem to indicate that its only purpose is to replace abstract / and
. characters with OS equivalents.
On OS X this would have seem to have no net result.
Is there more to this?
You absolutely have to do it. There may be other things, but the
transformations in 'fileSystemRepresentation' include at least:
1. '/' characters are replaced by ':', for file systems that use '/' as a
path component separator. (':' has always been illegal in file names at the
UI, so the transformation is reversible.)
2. Graphemes with multiple Unicode representations are converted to a normal
form, for file systems that store Unicode file names. (Can't remember which
form -- Unicode normal form D, I think.) That removes indeterminacy when
there are accented characters (graphemes) with equivalent 1- and 2-
character Unicode forms, or characters with multiple accents where the
order of the accents could vary.
If you ever sample -fileSystemRepresentation, you'll see it just calls through
internally to -[NSFileManager fileSystemRepresentationWithPath:], which
documents the unicode handling a little better:
A C-string representation of path that properly encodes Unicode strings for
use by the file system.
___
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: Using a document bundle file type with core data
On 17 Jan 2013, at 03:38, David Brittain websi...@paperetto.com wrote: The code in this blog article enables saving core data files to a package: http://cutecoder.org/featured/asynchronous-core-data-document/ Take a look at the writeSafelyToURL implementation in the gist at the bottom. I haven't tried saving to a bundle myself, but found the article helped me solve some problems with core data and documents. The code in that article is a bit buggy. I did a rewrite, based off our internal code here: https://github.com/karelia/BSManagedDocument Read through the header for full details, and make sure you work with the ksmanageddocument branch for now. There are a lot of tricky edge cases involved in this. About 4 years of discovering them has gone into this! ___ 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: AppleScript in Sandboxed App
On 14 Jan 2013, at 17:50, John Nairn j...@geditcom.com wrote: I have sandboxed an app that allows users to run scripts as a major feeature (i.e., dealbreaker on sandboxing only answer is to delete this feature). I was pleased that I can run AppleScripts fine through the sandboxed app from Apple's Script Editor, but the user experience is much (much, much) better if they can select a script from a menu in my app and run it, but that method fails. Here is more info: 1. Script running code is sound and works fine if app is not sandboxed. 2. Script is compiled, error free, and does not try to send events to any app except my own 3. Script is stored in application support of my container and therefore I should have read and write permission on that file 4. The first step in running the script (which is when is fails) is simply: script = [[NSAppleScript alloc] initWithContentsOfURL:[NSURL fileURLWithPath:scriptPath] error:errorInfo]; The errorInfo dictionary has only NSAppleScriptErrorNumber = -43 and no other details. I could not find this error number in a google search. 5. I have more problems running python scripts using Scripting bridge when sandboxed, but I am working on one problem for now Go watch the sandboxing videos from WWDC this year. They cover automation quite a bit, and all will be made much clearer. ___ 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: Optimal height for WebView
On 14 Jan 2013, at 18:09, Eric Gorr mail...@ericgorr.net wrote:
Sent from my iPhone
On Jan 4, 2013, at 9:45 PM, Steve Christensen puns...@mac.com wrote:
On Jan 4, 2013, at 10:40 AM, Mike Abdullah wrote:
On 4 Jan 2013, at 18:12, Eric Gorr mail...@ericgorr.net wrote:
Good point Mike.
However, after it has completed the layout, is it possible to determine
the height of the content? If so, i could probably work with that
information.
But, I would still think it was possible to provide a method with a fixed
width, have it perform a layout, and return the height - that is
essentially what the stackoverflow solution does, just in a rather
convoluted way.
Well you've got the whole DOM API to play with. I'd have a play around with
computed style etc. to see if you can pull out a useful figure.
Ask the DOM what the height is. I use jquery but you could just as easily
use standard Javascript methods to get the height.
- (void) webViewDidFinishLoad:(UIWebView*)webView
{
height = [[webView
stringByEvaluatingJavaScriptFromString:@$(document).height();]
integerValue];
}
At least for me, this returns a value of zero.
Steve showed an example of how you could do this using jquery. Thus, the above
script will work *only* if the web page has jquery loaded into it. You likely
want to figure out how to do it without jquery.
Ultimately here, web pages are complex beasts. You're going to have to
understand a least a little of the DOM and how it works in order to figure out
the optimum height for a given page.
___
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: Tracking object references
On 12 Jan 2013, at 09:01, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Dear list, I'm still struggling to find the cause of a CoreData could not fulfil a fault error on saving an NSPersistentDocument (see other mail thread coredata count not fulfill fault after object delete). I'm wanting to check if some other object has a strong reference to the deleted objects since this is a primary reason for the could not fulfil a fault error. To help with this, I wondering if there is a way to get a list of all objects in the run-time that have a strong reference to a particular object? Is this something I can do somehow with instruments? The allocations instrument can show you all presently allocated objects. Find the object(s) you're interested in from that list and you can view its history of being retained and (auto)released, to figure out what is still holding onto 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: Issue with Core Data Model
On 11 Jan 2013, at 16:35, David Delmonte ddelmo...@mac.com wrote: I think that now, entities must start with a capital letter.. Amy has an *attribute* named description; not an entity. ___ 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: Cococa-Dev : was [coredata count not fulfill fault after object delete]
On 8 Jan 2013, at 05:53, Martin Hewitson wrote:
On Jan 7, 2013, at 08:44 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote:
On 7 Jan 2013, at 16:35, Martin Hewitson martin.hewit...@aei.mpg.de wrote:
Hi Francisco,
Thanks for the feedback!
What you suggest sounds like it might fix the problem, but I'm wondering
how best to do this. Currently I'm just calling -remove: on the tree
controller to delete the selected object(s). Of course, if I clear the
selection first, then -remove: doesn't do anything. I can grab an array of
the selected objects before clearing the selection then use
NSManagedObjectContext's -deleteObject:. So something like this:
// get a pointer to the selected items
NSArray *items = [self selectedObjects];
// clear selection
[self setSelectionIndexPaths:@[]];
// now delete from the MOC
for (NSManagedObject *item in items) {
[self.managedObjectContext deleteObject:item];
[self.managedObjectContext processPendingChanges];
}
Does that look sensible to you?
Why are you calling -processPendingChanges at each iteration of the loop?
Calling it yourself is rarely needed, and best done only with justification.
I read in that thread that I referenced (I think) that it may be necessary to
do this to avoid/handle objects being deleted twice (if a parent and child
are selected, then deleted). To be honest, I'm just trying things to see what
works. Since this problem only occurs on 10.6.8, I think I'm looking for a
work-around.
Hmm. In my case I go to some lengths to figure out which objects don't need to
be deleted, because an ancestor has already been deleted. It does seem simpler
your way.
I wonder though — I don't believe there is any harm in asking Core Data to
delete an object that's already been marked for deletion. And indeed, you code
is doing that. The difference the -processPendingChanges call makes is that
handling the delete rule will happen during that call, so child objects are
already marked for deletion.
___
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: Cococa-Dev : was [coredata count not fulfill fault after object delete]
On 7 Jan 2013, at 16:35, Martin Hewitson martin.hewit...@aei.mpg.de wrote:
Hi Francisco,
Thanks for the feedback!
What you suggest sounds like it might fix the problem, but I'm wondering how
best to do this. Currently I'm just calling -remove: on the tree controller
to delete the selected object(s). Of course, if I clear the selection first,
then -remove: doesn't do anything. I can grab an array of the selected
objects before clearing the selection then use NSManagedObjectContext's
-deleteObject:. So something like this:
// get a pointer to the selected items
NSArray *items = [self selectedObjects];
// clear selection
[self setSelectionIndexPaths:@[]];
// now delete from the MOC
for (NSManagedObject *item in items) {
[self.managedObjectContext deleteObject:item];
[self.managedObjectContext processPendingChanges];
}
Does that look sensible to you?
Why are you calling -processPendingChanges at each iteration of the loop?
Calling it yourself is rarely needed, and best done only with justification.
___
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: scroll bars and visible rect
On 3 Jan 2013, at 17:54, koko k...@highrolls.net wrote: visibleRect Returns the visible region of the receiver, in its own coordinate space. (read-only) @property(readonly) CGRect visibleRect Discussion The visible region is the area not clipped by the containing scroll layer. And I may have answered my question since it says the visible region is not clipped by the containing scroll layer I assume the scroll bars are inside the visible rect; No it's quite confusing wording. It's saying it's giving the area of the view that isn't clipped. As everyone else has already pointed out though, it sounds like you're using NSScrollView but reading the CGScrollLayer docs, which makes no sense. ___ 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: Optimal height for WebView
On 4 Jan 2013, at 17:19, Eric Gorr mail...@ericgorr.net wrote: Sent from my iPhone On Jan 4, 2013, at 11:34 AM, Keary Suska cocoa-...@esoteritech.com wrote: On Jan 4, 2013, at 9:19 AM, Eric Gorr wrote: It seems like this should be a simple question. I can access the NSScrollView of the WebView and ask the scroll view for the height of its document view, but the height it returns is the current height of the WebView, not the height of the content it currently contains. If I reduce the height of the WebView, eventually the vertical scrollbar will appear, so someone knows the real height of the content the WebView contains. I simple want to be able to obtain that value so I can size the WebView to this height, if it is reasonable to do so. How can I do this? Various proposed solutions I have found do not work. First off, to avoid someone proposing a solution that you have already tried, you should actually mention which proposed solutions you have tried and how they didn't work for your case. So, risking that you have already tried this, what does [[yourWebView mainFrame] webView] frame] give you? The current height of the WebView, not the height of the content - which is smaller. I did just locate a solution that does work, but I am not really happy with it because it seems more complicated then it should be. Check out: http://stackoverflow.com/questions/2675244/how-to-resize-webview-according-to-its-content Note, it does not appear to be necessary to disable the scrolling and it is necessary to first resize the WebView to a small height as mentioned by Miraaj in a comment on the answer. Now, one problem i am having with this solution is that I see a flicker with the WebView shrinking and then growing larger. It really does seem like there should be a way to ask for the height of the content regardless of the current height of the WebView. If there is not, I will probably go ahead and file a bug. The problem you're up against here is that it's possible for web content to lay itself out based on the browser's size. As soon as you run into a webpage that does that, there's no to know the optimal size, short of trying them all. ___ 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: Optimal height for WebView
On 4 Jan 2013, at 18:12, Eric Gorr mail...@ericgorr.net wrote: Good point Mike. However, after it has completed the layout, is it possible to determine the height of the content? If so, i could probably work with that information. But, I would still think it was possible to provide a method with a fixed width, have it perform a layout, and return the height - that is essentially what the stackoverflow solution does, just in a rather convoluted way. Well you've got the whole DOM API to play with. I'd have a play around with computed style etc. to see if you can pull out a useful figure. ___ 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: scroll bars and visible rect
You need to be more specific. What precisely do you mean by the visible rect? On 2 Jan 2013, at 22:53, koko wrote: Are scroll bars inside the visible rect or additive to the visible rect? I ask because we use the visible rect to set the size of a bitmap to display and we are getting some strange behavior from some users and thought they may have scroll bars set to display when scrolling. -koko ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Refreshing the NSOpenPanel?
Is your app sandboxed? If so, does disabling the sandbox make a difference? Sent from my iPad On 30 Dec 2012, at 00:43, C.W. Betts computer...@hotmail.com wrote: After I set an NSOpenPanel's allowed file types while it is open, it doesn't refresh until I move to a different folder. Is there a way to force NSOpenPanel to refresh its openable file type? ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: NSURL bookmark error return
On 18 Dec 2012, at 08:37, Quincey Morris quinceymor...@rivergatesoftware.com
wrote:
Was there a thread recently that listed a couple of Cocoa frameworks methods
that mis-handle the NSError** parameter? What were those methods? The reason
I ask is that the general file system documentation for dealing with
bookmarks:
https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW10
gives this code fragment:
- (NSData*)bookmarkForURL:(NSURL*)url {
NSError* theError = nil;
NSData* bookmark = [url
bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
includingResourceValuesForKeys:nil
relativeToURL:nil
error:theError];
if (theError || (bookmark == nil)) {
// Handle any errors.
return nil;
}
return bookmark;
}
which doesn't follow the rules for testing for errors. The succeeding
fragment is even worse:
- (NSURL*)urlForBookmark:(NSData*)bookmark {
BOOL bookmarkIsStale = NO;
NSError* theError = nil;
NSURL* bookmarkURL = [NSURL URLByResolvingBookmarkData:bookmark
options:NSURLBookmarkResolutionWithoutUI
relativeToURL:nil
bookmarkDataIsStale:bookmarkIsStale
error:theError];
if (bookmarkIsStale || (theError != nil)) {
// Handle any errors
return nil;
}
return bookmarkURL;
}
since it doesn't even check the returned value.
Is this a documentation error, or is the documentation explaining how to code
around a frameworks deficiency?
BTW the NSURL class reference documentation doesn't say anything about this.
It doesn't even mention nil return values.
That sample code scares me. I wrote this recently, if it helps:
http://www.mikeabdullah.net/nsurl-bookmark-error-handling.html
___
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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 17:15, Sean McBride s...@rogue-research.com wrote: On Sun, 16 Dec 2012 21:46:14 -0800, Kyle Sluder said: Thanks Kyle. I know about beginWithCompletionHandler: , but I really need a modal window at that point my application opens the open panel. I have to ask, why? Sometimes it's appropriate. Apple seems to think so, as File Open shows a modal open panel. For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. ___ 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: NSOpenPanel runModal on a dispatch
On 17 Dec 2012, at 23:29, Kyle Sluder k...@ksluder.com wrote: On Mon, Dec 17, 2012, at 03:25 PM, Sean McBride wrote: On Mon, 17 Dec 2012 23:15:15 +, Mike Abdullah said: For what it's worth, OS X v10.8 Mountain Lion finally fixes this by making open panels non-modal. I think apps do need to be built against the new SDK for it, rather than automatically switching over to such behaviour. In in 10.8.2 now, and in TextEdit they are app-modal. It's Info.list shows LSMinimumSystemVersion=10.8. Not the case for you? Certainly not app-modal on my 10.8.2 machine. Nor is it modal in Preview. Maybe you have to be setup with an iCloud account too for the new behaviour? Would be a bit odd if that were true though. ___ 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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 10:45, Tamas Nagy wrote:
Hey,
I'm trying to display an NSOpenPanel on a dispatch, with half-luck. The panel
displays, but no files going to be displayed - the circle just spinning on
the bottom-left corner. Anyone have an idea what going wrong?
Thanks,
Tamas
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
NSMutableArray *filetype = [NSMutableArray arrayWithCapacity:0];
[filetype insertObject:@txt atIndex:0];
[oPanel setAllowedFileTypes:filetype];
[oPanel setDirectoryURL:[NSURL URLWithString:NSHomeDirectory()]];
This line of code is your problem. +URLWithString: is not an appropriate way to
create a URL from a path. +fileURLWithPath:isDirectory: is what you want
instead.
+[NSSavePanel setDirectoryURL:] behaves oddly with non-existing paths, as
covered at http://www.mikeabdullah.net/pre-populating-nssavepanel.html
___
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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 18:32, Kyle Sluder wrote:
On Dec 16, 2012, at 2:45 AM, Tamas Nagy tamas.lov.n...@gmail.com wrote:
dispatch_async(dispatch_get_main_queue(), ^{
NSOpenPanel *oPanel = [NSOpenPanel openPanel];
*Bzzt!* Thou shalt not do UI work on a background thread. You cannot use
dispatch_async here.
*Bzzt* he's not doing UI work on a background thread. In any normal app, this
is running the code on the main thread.
___
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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 17:20, Tamas Nagy wrote: Unfortunately that doesn't help. I think the issue should be related to dispatches, because it won't happen if I just call performSelectorOnMainThread... Can you post that variant of your code then, please? ___ 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: NSOpenPanel runModal on a dispatch
On 16 Dec 2012, at 20:04, Tamas Nagy wrote: Thanks for the approach Kyle, but dispatch_async performs asynchronously, so it should not block the main thread. I fallback to performSelectorOnMainThread: method in my app, but the dispatch way is a bit straightforward in my opinion. I'll fill a rdar on this. Possibly you could still use a block-based API but that uses -performSelector… under the hood, such as https://github.com/karelia/KSThreadProxy ___ 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 validation for NSMutableArray of NSMutableDictionary
I'd strongly advise the OP it's better for them to create a custom class for
their model objects, rather than go down this route of globally modifying
NSMutableDictionary's API.
On 13 Dec 2012, at 22:18, jonat...@mugginsoft.com wrote:
On 13 Dec 2012, at 11:54, jonat...@mugginsoft.com wrote:
I bind an NSArray of NSMutableDictionary instances to an NSTableView and
enable NSTableColumn editing..
How can I best implement KVO based validation when editing the view?
Subclassing NSArray controller is a no go as validateValue:forKeyPath:error
is never called.
Subclassing the NSMutableDictionary model obviously isn't desirable.
I can refactor the NSMutableDictionary instances into custom objects and use
model based validation if needed.
However, binding dictionaries into table views is often convenient so a
working validation strategy would be useful.
Jonathan
The following category enables NSMutableDictionary KVC validation routing to
a delegate.
NSMutableDictionary *connection = [self selectedConnection];
connection.validationDelegate = self;
The delegate then performs validation in:
- (BOOL)validateValue:(id *)ioValue forKey:(NSString *)key error:(NSError
**)outError sender:(NSMutableDictionary *)sender
See https://github.com/mugginsoft/NSMutableDictionary-KVCValidation
Simple refactoring would enable routing of KVC validation for any class.
Jonathan
#import NSMutableDictionary+KVCValidation.h
#import objc/runtime.h
const char validationDelegateKey;
/*
MethodSwizzle()
ref:
http://www.mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html
*/
void MethodSwizzle(Class klass, SEL origSEL, SEL overrideSEL)
{
Method origMethod = class_getInstanceMethod(klass, origSEL);
Method overrideMethod = class_getInstanceMethod(klass, overrideSEL);
// try and add instance method with original selector that points to new
implementation
if (class_addMethod(klass, origSEL,
method_getImplementation(overrideMethod),
method_getTypeEncoding(overrideMethod))) {
// add or replace method so that new selector points to original
method
class_replaceMethod(klass, overrideSEL,
method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
} else {
// class already has an override method so just swap the
implementations.
method_exchangeImplementations(origMethod, overrideMethod);
}
}
@implementation NSMutableDictionary (KVCValidation)
/*
+ load
*/
+ (void)load
{
MethodSwizzle(self, @selector(validateValue:forKey:error:),
@selector(swizzle_validateValue:forKey:error:));
}
/*
- setValidationDelegate:
*/
- (void)setValidationDelegate:(id)validationDelegate
{
objc_setAssociatedObject(self, validationDelegateKey, validationDelegate,
OBJC_ASSOCIATION_RETAIN);
}
/*
- validationDelegate
*/
- (id)validationDelegate
{
return objc_getAssociatedObject(self, validationDelegateKey);
}
/*
- swizzle_validateValue:forKey:error:
*/
- (BOOL)swizzle_validateValue:(id *)ioValue forKey:(NSString *)key
error:(NSError **)outError
{
id validationDelegate = self.validationDelegate;
SEL validationSelector = @selector(validateValue:forKey:error:sender:);
BOOL isValid = NO;
if ([validationDelegate respondsToSelector:validationSelector]) {
isValid = [validationDelegate validateValue:ioValue forKey:key
error:outError sender:self];
} else {
// remember, we swap IMPS at run time
isValid = [self swizzle_validateValue:ioValue forKey:key
error:outError];
}
return isValid;
}
@end
Jonathan
___
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/cocoadev%40mikeabdullah.net
This email sent to cocoa...@mikeabdullah.net
___
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: NSMutableData and Pinned Memory buffers..
Arguably, you'd be better off subclassing NSData directly to add the mutation
APIs that you actually need. That clears up any possible confusion about
methods which might affect the length of the data.
On 14 Dec 2012, at 00:13, Robert Monaghan wrote:
Thanks for the suggestion, Kevin!
I went ahead and created a really crude subclass of NSMutableData. It seems
to work for my situation.
Attached is the code, for posterity. (I am sure I won't be the only one
working around this.)
Any suggestions to make this a bit more Proper are welcome.
bob.
//
// GT_NSMutableData.h
//
// Created by Robert Monaghan on 12/13/12.
// Copyright (c) 2012 Glue Tools LLC. All rights reserved.
//
#import Foundation/Foundation.h
@interface GT_NSMutableData : NSMutableData
{
void *_gt_buffer;
NSUInteger _gt_length;
BOOL _gt_freeWhenDone;
}
@property (readwrite) NSUInteger length;
@end
//
// GT_NSMutableData.m
//
// Created by Robert Monaghan on 12/13/12.
// Copyright (c) 2012 Glue Tools LLC. All rights reserved.
//
#import GT_NSMutableData.h
@implementation GT_NSMutableData
+ (id)dataWithBytesNoCopy:(void *)bytes length:(NSUInteger)length
freeWhenDone:(BOOL)b
{
return [[[GT_NSMutableData alloc] initWithBytesNoCopy:bytes
length:length freeWhenDone:b] autorelease];
}
- (id)initWithBytesNoCopy:(void *)bytes length:(NSUInteger)length
freeWhenDone:(BOOL)b
{
self = [super init];
if (self) {
_gt_buffer = bytes;
_gt_length = length;
_gt_freeWhenDone = b;
}
return self;
}
- (void)dealloc
{
if (_gt_freeWhenDone)
free(_gt_buffer);
[super dealloc];
}
- (void)increaseLengthBy:(NSUInteger)extraLength
{
}
- (void)setLength:(NSUInteger)length
{
}
- (NSUInteger) length
{
return _gt_length;
}
- (const void *)bytes
{
return _gt_buffer;
}
- (void *)mutableBytes
{
return _gt_buffer;
}
- (void)replaceBytesInRange:(NSRange)range withBytes:(const void *)bytes
{
}
- (void)replaceBytesInRange:(NSRange)range withBytes:(const void
*)replacementBytes length:(NSUInteger)replacementLength
{
}
- (void)resetBytesInRange:(NSRange)range
{
}
- (void)setData:(NSData *)data
{
_gt_buffer = (void *)[data bytes];
}
@end
On Dec 13, 2012, at 3:22 PM, Kevin Perry kpe...@apple.com wrote:
NSMutableData currently ignores (and always has, to my knowledge) the
no-copy hint and always copies the bytes into an internal buffer in case
something tries to change the length of the NSMutableData.
It would not be too difficult to make a subclass of NSMutableData that
doesn't copy and throws an exception when something tries to change the
length. That would violate the Liskov substitution principle though, so at
the very least, you want to prevent any code that doesn't understand the
fixed-length restriction from getting ahold of one of these objects.
[kevin perry];
On Dec 13, 2012, at 2:28 PM, Robert Monaghan b...@gluetools.com wrote:
Hi Everyone,
I have just run head long into an issue with NSMutableData and existing
buffers.
I have the following code:
UInt8 *sourcebytes = [clImgEngine srcBuffer];
[self setData:[NSMutableData
dataWithBytesNoCopy:sourcebytes length:[clImgEngine inRangeByteCount]
freeWhenDone:NO]];
UInt8 *resultBytes = [[self data] mutableBytes];
The source is a pinned memory buffer from OpenCL. What I want to do, is to
pass this buffer inside a NSMutableData wrapper and have another object for
some work.
Seems simple enough, except that NSMutableData changes the memory buffer in
the background.
sourcebytes starts with an address such as: 0x00012361b000
and resultBytes returns 0x000136fe2000
Naturally, my work object doesn't see any data from sourcebytes, as
NSMutableData has moved the buffer.
I thought that freeWhenDone:NO prevented ownership of the buffer..
Can anyone suggest a way to prevent this from happening? I need the buffer
to stay pinned.
Thanks in advance!
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:
https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
This email sent to kpe...@apple.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
This email sent to cocoa...@mikeabdullah.net
Re: NSWorkspace recycleURLs:completionHandler error -5000 (afpAccessDenied)
On 14 Dec 2012, at 21:26, Jon Gary wrote: I have a sandboxed app that creates a file in a folder within the app's sandbox container. When the app is done with the file, it is moved to the trash using recycleURLs:completionHandler. A few of our users are reporting the you do not have permision to move the file to the trash. I've checked the permissions on the file itself and the user has read and write accces. We've had them run a shell command to make sure they have write access to their trash directory. None of this helps. I'm stumped. I've asked the user if they are using a networked home directory, but they say no (I'm not sure they understood the question). Any clues? When you say inside the app's sandbox container, where specifically are we talking? ___ 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: URL Request from AppDelegate?
You've given us an error message but no details at all about what your code is actually doing. Show us some code and it will be much much easier to debug. On 13 Dec 2012, at 01:22, berry hunt wrote: Hi gurus, I am pretty new to cocoa development, and would like to ask for help on some questions here that I am struggling with. Any insight will be greatly appreciated. I am trying to establish Facebook login session via my mobile app, but got an error of following message *Error: HTTP status code: 404* * * What got me struggling is that, I think, the error message actually happened before the FB login request was fired from my app. I am suspecting that this is due to some parameter missing in a URL request. However since the source code of the libraries are not available, this makes it a guessing game. Here are my questions: - where in the AppDelegate class would a URL be sent, to somewhere? How do I track it down? - where would the parameters of an URL request be constructed in the actual code, or xcode itself, to make the URL be sent? Thanks a lot guys! Berry ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: blocks and id
On 12 Dec 2012, at 09:57, Andreas Grosam wrote: On 12.12.2012, at 10:19, Charles Srstka wrote: On Dec 12, 2012, at 3:03 AM, Andreas Grosam agro...@onlinehome.de wrote: How can I check at runtime whether an object (id) is actually a block, and not another kind of object? I don't think there's any good way of doing that right now. You could check the class of the block, but since the block classes are completely undocumented AFAIK, there's no guarantee that the class names won't change in some future release of OS X and break your code. Charles Thanks for the reply. I feared that. Currently, I resort to if ([obj isKindOfClass: NSClassFromString(@NSBlock)]) … which evaluates to YES if `obj` is a block. However, NSBlock is not a public class, thus: NSClassFromString(@NSBlock) which works as the time of writing in Mac OS, and returns a class whose name is NSBlock (the real block classes are named differently). Why does your code care if some unknown object is a block? This is a strong sign of a bad design. ___ 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: blocks and id
On 12 Dec 2012, at 13:24, Andreas Grosam wrote:
On 12.12.2012, at 13:02, Mike Abdullah wrote:
On 12 Dec 2012, at 09:57, Andreas Grosam wrote:
Why does your code care if some unknown object is a block? This is a strong
sign of a bad design.
Oh, then a lot of common Cocoa patters like dug typing
I presume you mean duck typing? Duck typing is pretty much the opposite of
what you're trying to do. Duck typing is being handed an object and told it
meets a certain requirement. Rather than trying to test if it really is of the
expected *class*, you message it anyway on the understanding that it will
behave as you expect.
The point is that you care whether the object *behaves like* a duck; not
whether it actually is a duck.
and the usage -respondsToSelector:, -conformsToProtocol:, or any other
introspection are a bad design, too. ;)
These methods contribute to duck typing sort of behaviour in Cocoa, not the
approach you describe below. It's worth noting that Cocoa actually uses these
methods pretty sparingly in practice.
I don't like it either, but the alternative would be a quite elaborate
approach and would require to define categories for every class that is
possibly involved in this particular case.
Writing category methods seems no more elaborate than writing a big series of
if statements checking the class of an object.
AND it would requite a respondsToSelector anyway,
Not true; if the object doesn't implement the selector, you can consider that
to be a programmer error and throw an exception.
AND would require some mechanism that processes a block and the other
objects through sending the object a common single message.
The reason why I would like to have this is a rather generic interface which
shall be as flexible and as convenient as possible. It is used for a network
library when generating HTTP messages. For example, the following snippet
creates a Foundation representation of a multipart/form-data part suitable to
upload a file to a server:
idRXMultipartFormdataPart part6 =
[RXMultipartFormdataSource makeFilePartWithName:@submit
fileName:@data2.txt
headers:@{@content-type:@text/plain}
value:[NSData
dataWithBytes:0123456789 length:10]];
The construction of a valid sequence of bytes constituting various HTTP
headers is more than cumbersome.
In this snipped, the parameter `headers` are defined as a NSDictionary.
However, it could also be a NSData containing a valid sequence of bytes
constituting *one* header, or *many* headers, or an NSArray of NSDatas
constituting a number of headers. And since a header may have a set of
parameters, a header entry in the dictionary may have a params dictionary as
well, and so force. The parameter `headers` (and the others, too) will simply
pass a serialization process, which eventually generates a NSData object -
constituting one or more HTTP message headers.
Likewise, parameter `value` constituting the body part can be anything that
can be eventually converted to something that is a valid byte sequence for
the body data of a multi part, conforming to the context defined through the
headers already set. If the header would be empty, and value would have been
a NSString, the string would be encoded properly with a default encoding
(UTF-8), and the headers would be set accordingly (- Content-Type:
text/plain; charset=utf8).
If the parameter `value` would be NSNumber for instance, the NSNumber would
be first converted to a NSString, and then encoded as mentioned above.
If a Content-Type header with a charset definition has been defined already
and the value is a NSString, the string will be encoded as stated in the
charset parameter value (e.g. charset=utf8).
The parameter value can be a file URL, too -- in which case a more elaborated
mechanism is used to construct the body of the whole message during the
request is active.
And, it can be a block as well, where the block is responsible to feed the
consumer (the idRXMultipartFormdataPart) with data when it has bytes
available when the request is active.
You can do this with the same method, same API. Well, it MUST, otherwise the
number of combinations of the various types yielding different methods, would
explode.
This is going to end badly, believe me. Look around Cocoa, you will find very,
very few APIs, if any, that behave the way you want this one to. You want
separate methods for the different types of input to handle. If you accomplish
this by defining a protocol that a variety of objects conform to, that's fine;
then you only need to publish two methods — one for blocks, and one for other
object types.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do
Re: blocks and id
On 12 Dec 2012, at 14:14, Jean Suisse wrote: On 12 déc. 2012, at 13:02, Mike Abdullah cocoa...@mikeabdullah.net wrote: Why does your code care if some unknown object is a block? This is a strong sign of a bad design. As far as I am concerned, I can think of at least two or three legitimate reasons to care wether an unidentified object is a block or not. But you seem pretty certain. So you must have had more informations than the rest of us – sorry, just thinking out loud. No extra information; just experience and a knowledge of the Cocoa APIs. To actually answer the question, I fear that not much can be done. Personally, I would go for Andreas' current solution and if the app is commercial, I would make sure to test fix it before each public MAC OS release, so that users can upgrade the app before upgrading the system (and also check the OS version at each launch to detect if they didn't upgrade). Seriously, you'd recommend a fragile solution that relies on private API and needs regular testing, over simply having two or more methods? Otherwise, maybe this could work depending on the situation: -(whatever)processSomething:(id)something andKeepInMindThatsABlock:(BOOL)isBlock; Well once you've done that, surely you might as well just have two separate methods?! ___ 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: FileWrapper iCloud
On 2 Dec 2012, at 01:00, Dave Fernandes wrote: On 2012-12-01, at 5:05 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 1 Dec 2012, at 20:21, Dave Fernandes wrote: NSPersistentDocument always creates a MOC of type NSMainQueueConcurrencyType, even if it is created on a background thread. So as long as things don't go wrong during document opening, everything will be the same as a document opened on the main thread forever after. Whoops! I meant to say NSPersistentDocument always creates a MOC of type **NSConfinementConcurrencyType** -- the legacy type that assumes you know what you are doing and will manage access accordingly. But the Core Data team have said for years that MOCs created on the main thread get some special treatment. I guess I missed that somewhere. Was it on this list? I wish I knew! It's definitely been said to me in person at WWDC, and I expect somewhere more public such as this list or perhaps the dev forums. ___ 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: NSOperation Efficiency
On 5 Dec 2012, at 04:41, Kyle Sluder k...@ksluder.com wrote: NSOperationQueue uses KVO for dependency tracking and queue width management. In 10.7, the implementation was apparently changed to thunk all KVO ops onto the main thread; I'm guessing this fixed a bug by serializing all state changes. It also slowed down enqueueing operations onto our NSOperationQueue from a background thread by a factor of ten or more. I have samples to prove it. Wow, that's a big change! Are there are docs to back it up, or is this purely empirical? ___ 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: Cascading windows
The document architecture already provides proper cascading behaviour. What are you seeing that makes you think you need to implement it yourself instead? On 5 Dec 2012, at 20:55, Peter Teeson ptee...@me.com wrote: Xcode 4.5.2, Lion 10.7.5 My app is a Document app and I implemented -(void)makeWindowControllers. It could have several documents open at the same time. In particular I want to cascade the window when a New document is opened. I've read up on this and am aware of the NSWindow method - (NSPoint)cascadeTopLeftFromPoint:(NSPoint)topLeft]; // in screen coordinates!! So do I implement the cascading algorithm my WindowController? If so in which method? (a) initWithWindowNibName after the nib is instantiated? (b) windowDidLoad? (c) or somewhere else entirely? Finally I am considering an NSPoint (static?) in my appDelegate to store the last used NSPoint. Does this approach seem correct? If not what would you suggest? I did Google for algorithm and code but nothing helpful popped up. TIA for your comments. Peter ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Operations Beachball
You have a performance problem. Thus you should use Instruments to see what is
going on, rather than hope we can tell you from vague snippets of code.
On 4 Dec 2012, at 10:29, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
My app creates lots of MyOperations (subclass of NSOperation) and puts them
into an NSOperationQueue.
I would expect that the app thus remains responsive, but sometimes it is not.
A sure way to beach-ball my app is: start it with a few hundred operations
(which will take about 20 seconds to finish).
Make some other app active.
Try to make my app active again - it's panel stays grey and after a few
seconds the cursor will turn into a beach-ball.
These MyOperations interact with their controller in two ways:
1. they do once at start: [ controller dataStringFor: row ];
The controller has:
- (NSString *) dataStringFor: (NSUInteger)row
{
@synchronized(self)
{
if ( self.stringArray == nil ) { create it - takes some time,
but happens only once};
}
return self.stringArray[row];
}
2. When MyOperations have finished their work they call: [ controller done:
row result: someNumber ];
The controller has:
- (void) done: (NSUInteger) row result: (NSUInteger) someNumber
{
@synchronized(self)
{
[ self.rowsToDo removeIndex: row ]; //
NSMutableIndexSet
};
// sometimes do some logging, update user interface - but only
every few seconds
}
So, why the beach-ball? What am I doing wrong? How to debug this? Why does
the app-switch make the beach-ball appear?
Gerriet.
10.8.2, Arc
___
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/cocoadev%40mikeabdullah.net
This email sent to cocoa...@mikeabdullah.net
___
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: NSOperation Efficiency
If your operations are purely CPU-bound, the whole point of GCD is to manage this for you. With the default number of concurrent operations, NSOperationQueue does exactly that. Have you tried with that setting? On 4 Dec 2012, at 18:15, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: I have an app which uses NSOperations inside an NSOperationQueue. These operations do not do any I/O - just Cpu. No swapping is taking place. When I set [ self.operationQueue setMaxConcurrentOperationCount: 1 ] each operation takes on average 200 msec., measured by NSDate. With 2 concurrent operations, it takes not 100 msec but 110 - an extra 10%. Ok - some overhead is to be expected. With 4 ops it takes 70 instead of 50 - overhead 40% - rather a lot. With 8 ops it takes 60 instead of 25 - overhead 140%. or: 40% of the cpu is used by my operations, 60% is used by whom? And for what? Is this to be expected? Or does my app has some hidden flaws? If so, where should I start looking? Gerriet. ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Dangling reference to an invalid object
On 3 Dec 2012, at 18:13, Nick Zitzmann n...@chronosnet.com wrote: On Dec 1, 2012, at 10:33 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: I've been trying to hunt down a problem where Core Data will occasionally refuse to save with the error Dangling reference to an invalid object. I wrote up the details here: http://www.mikeabdullah.net/dangling-ref-to-an-invalid-object.html Can anyone shed some light on how this might happen? This exception happens if you: 1. Create a new object 2. Create a relationship between the new object and an existing object 3. Turn the new object into a fault before it is officially inserted 4. Save changes So if you're getting this exception, you need to be more careful about using the -refreshObject:mergeChanges: method, because the code is most likely misusing it. One way to fix this is to never refresh an object that has a temporary object ID. Hmmm, we're never calling -refreshObject:… ourselves. Possibly some bit of the frameworks might be, but you'd hope they're not doing anything wrong like that. Also, I neglected to mention in the blog post, that the TextBoxBody object is created as a consequence of creating and inserting a TextBox object. So I still suspect that the TextBox is being deleted from the context, but somehow failing to take the Body with it. From my code it seems impossible that inserting the TextBox could somehow fail, but still succeed at inserting the corresponding Body. Thanks for giving me an extra idea of what to check though! ___ 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: NSOperation Efficiency
On 4 Dec 2012, at 19:01, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: On 5 Dec 2012, at 01:55, Mike Abdullah cocoa...@mikeabdullah.net wrote: If your operations are purely CPU-bound, the whole point of GCD is to manage this for you. With the default number of concurrent operations, NSOperationQueue does exactly that. Have you tried with that setting? I have, and it makes my app unresponsive (i.e unusable) until all operations have finished. Triggered by making other app, active, then again my app. That suggests your operations aren't purely CPU-bound then. They're getting stuck waiting on something else. When that happens, GCD sees it as wasted CPU time so starts off the next bit of work anyway. ___ 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: FileWrapper iCloud
On 30 Nov 2012, at 23:05, Dave Fernandes dave.fernan...@utoronto.ca wrote: On 2012-11-30, at 4:46 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 30 Nov 2012, at 18:59, Dave Fernandes dave.fernan...@utoronto.ca wrote: On 2012-11-30, at 6:42 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context This definitely limits your options. But, is it necessary to support file wrappers and iCloud? (Just trying to educate myself about how documents work.) I don't understand your question here. Are you asking if my list of assumptions are necessary conditions for iCloud and file wrapper support? - works entirely on the main thread This one is already opt-in for both opening and saving, so fragility shouldn't be an issue to upgrading the class. [Aside: As far as I know you *can* actually open an NSPersistentDocument asynchronously. At least I haven't seen anything that says you can't, and it seems to work on every system I've tried it on.] Well you would appear to be breaking Core Data's threading contract by doing so. In theory, MOCs know the thread they were created on. So by creating the document on a background thread, you are also creating the MOC on that thread and giving it the wrong idea about the thread it will be used on. On 10.7+ you can of course tell the context at creation time it's for the main thread, but I'd be a little surprised if NSPersistentDocument is doing that. I also covered the topic fairly recently: http://www.mikeabdullah.net/concurrently-open-core-data-docs.html ___ 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
Dangling reference to an invalid object
I've been trying to hunt down a problem where Core Data will occasionally refuse to save with the error Dangling reference to an invalid object. I wrote up the details here: http://www.mikeabdullah.net/dangling-ref-to-an-invalid-object.html Can anyone shed some light on how this might happen? ___ 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: FileWrapper iCloud
On 1 Dec 2012, at 20:21, Dave Fernandes wrote: NSPersistentDocument always creates a MOC of type NSMainQueueConcurrencyType, even if it is created on a background thread. So as long as things don't go wrong during document opening, everything will be the same as a document opened on the main thread forever after. Whoops! I meant to say NSPersistentDocument always creates a MOC of type **NSConfinementConcurrencyType** -- the legacy type that assumes you know what you are doing and will manage access accordingly. But the Core Data team have said for years that MOCs created on the main thread get some special treatment. Of course they’ve never given us any specifics. The docs state very clearly that MOCs (using the non-private queue types) should be created on the same thread/queue that they’ll be used on. ___ 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: FileWrapper iCloud
On 1 Dec 2012, at 20:12, Dave Fernandes wrote: On 2012-12-01, at 11:42 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context This definitely limits your options. But, is it necessary to support file wrappers and iCloud? (Just trying to educate myself about how documents work.) I don't understand your question here. Are you asking if my list of assumptions are necessary conditions for iCloud and file wrapper support? Yes, that was basically the question. For example, what if you were just using file wrappers to store images outside the persistent store. My understanding is that if you want anything to be persisted outside of Core Data, you get treated just like a regular NSDocument subclass. i.e. no attempt to sync by SQLite changes. On OS X the docs state that NSPersistentDocument is flat-out not supported for iCloud. On iOS, the docs state that UIManagedDocument does not support additional content when used for iCloud. I assume the reason is that the moment you add into the mix some data outside of Core Data’s control/knowledge, iCloud has no smart way to sync it, so you’re giving up that major benefit of Core Data. Of course Core Data supports externally stored data attributes these days, so that does improve the situation. At that point I figure it’s best and easiest to subclass NSDocument afresh to add Core Data support, rather than try to bend NSPersistentDocument to your bidding. This is what I have done with BSManagedDocument. I believe, the window controller and view objects are always created on the main thread after the MOC has been initialized, so there won't be any contention with trying to access the MOC from different threads at the same time. Correct. The UI doesn’t get created until -makeWindowControllers is called, which happens on the main thread and is a standard feature of the document architecture. ___ 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: FileWrapper iCloud
On 30 Nov 2012, at 01:16, Sean McBride s...@rogue-research.com wrote: On Fri, 30 Nov 2012 00:43:36 +, Mike Abdullah said: With all the different features of the document system these days, it can be pretty hard to slot them all in nicely with Core Data. People may find https://github.com/karelia/BSManagedDocument pretty handy for this (the real meat is in the header file at present) Wow, that looks pretty awesome if it does all that is advertised. It's only 700 LOC, which really does make me wonder why NSPersistentDocument can't do all these things. Core Data didn't get any love in 10.8 at all. The conspiracy theorist in me wonders... One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. ___ 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: FileWrapper iCloud
On 30 Nov 2012, at 18:59, Dave Fernandes dave.fernan...@utoronto.ca wrote: On 2012-11-30, at 6:42 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context - works entirely on the main thread - only ever saves on top of itself, or to a new location using Save As I wonder if there's simply too much fragility in the existing subclasses that people have shipped, which make it a royal pain to try and modernise. ___ 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: FileWrapper iCloud
On 10 Nov 2012, at 18:28, Sean McBride wrote: On Sat, 10 Nov 2012 18:09:58 +, Luke Hiesterman said: File wrappers don't make it inherently easier or harder to deal with iCloud. File packages (which you would use file wrappers to represent) can be elegant means of wrapping up document data because it allows for easy separation of distinct components, and are usually recommended if they at all make sense for your application. Unless you use NSPersistentDocument, which still, after all these years, and even after the addition of 'external storage' support in 10.7, doesn't support file wrappers. :( It’s worth noting that the docs explicitly say NSPersistentDocument doesn’t support iCloud either. http://developer.apple.com/library/ios/#documentation/General/Conceptual/iCloudDesignGuide/Chapters/DesignForCoreDataIniCloud.html As I understand it (and I may be utterly wrong), if you want Core Data based iCloud documents on OS X, you’re in the same boat as everyone else working with NSDocument directly. i.e. no special syncing or conflict resolution. ___ 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: FileWrapper iCloud
On 10 Nov 2012, at 21:36, Gordon Apple wrote: I don¹t know about iCloud, but I finally got file wrappers working for my NSPersistentDocument subclass. It wasn¹t easy. I use a separate folder for stored files, sibling to my coreData storage, in the same package. I based it losely on the NSPersistentDocumentFileWrappers sample, then let my ³File² entity objects handle the creation and use of the folder. For ³saveAs² I had it copy the folder (if it exists) to the new location after it did the coreData and file package stuff. On 11/10/12 2:00 PM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: On Sat, 10 Nov 2012 18:09:58 +, Luke Hiesterman said: File wrappers don't make it inherently easier or harder to deal with iCloud. File packages (which you would use file wrappers to represent) can be elegant means of wrapping up document data because it allows for easy separation of distinct components, and are usually recommended if they at all make sense for your application. Unless you use NSPersistentDocument, which still, after all these years, and even after the addition of 'external storage' support in 10.7, doesn't support file wrappers. :( With all the different features of the document system these days, it can be pretty hard to slot them all in nicely with Core Data. People may find https://github.com/karelia/BSManagedDocument pretty handy for this (the real meat is in the header file at present) ___ 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: dispatch queues are objects now .. right?
On 25 Nov 2012, at 13:38, Roland King r...@rols.org wrote: I'm pretty sure that when I was watching the WWDC 2012 sessions, dispatch queues are now objects (since iOS6 and OS 10.7/10.8?) and as such I don't have to dispatch_retain() or release them and can just use them like any other object. But I can't find a reference in the documentation which supports that, that still says dispatch_queue_t is a struct. I wandered around the header files a bit but they conflict with each other. The header file (queue.h) says they are reference counted via calls to dispatch_retain() .. but the OS_OBJECT_DECL() macro says something rather different, that they are objects and the trail goes cold there. Am I correct in what I remember, are they now NSSObjects? They are objective-C objects, which doesn't necessarily mean they inherit from NSObject. If you have a deployment target of 10.8 or iOS 6 then ARC is able to manage their lifecycle for 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: removeObserver with keyPath nil
On 20 Nov 2012, at 19:50, Fritz Anderson fri...@manoverboard.org wrote: On 20 Nov 2012, at 11:16 AM, Gordon Apple g...@ed4u.com wrote: What¹s the story on removeObserver:self forKeyPath:nil, called in dealloc? Supposedly, this works. The docs don¹t say you can¹t use nil. However, I have run into at least one place where did not work. We converted from GC to ARC and have a bunch of these. I have seen statements that it worked under GC, but possibly not otherwise. Could you clarify what you mean by supposedly, this works? If the documentation says you can't do it, then Apple does not suppose it works, and Apple is the only one whose suppositions matter. At one time, you liked the undocumented behavior you got, but that doesn't guarantee Apple will always deliver it. The documentation of this method for the collection classes explicitly forbids the use of nil. For what it's worth, the collection classes also tell you not to call the method on them at all. Methinks somebody on the docs team did a bit too much copy and paste. ___ 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: NSFileManager - Incompatible persistent store
On 21 Nov 2012, at 21:16, Tom Miller t...@pxlc.me wrote:
I receive a warning in Xcode about this line of code dealing with the file
manager,
fileManager = [NSFileManager defaultManager];
applicationSupportFolder = [self applicationSupportFolder];
if ( ![fileManager fileExistsAtPath:applicationSupportFolder
isDirectory:NULL] ) {
[fileManager createDirectoryAtPath:applicationSupportFolder
attributes:nil];
}
Care to tell us what the warning actually is?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Getting a .icns file from IconRef data
On 20 Nov 2012, at 12:53, Ken Thomases k...@codeweavers.com wrote: On Nov 19, 2012, at 12:36 PM, Mike Abdullah wrote: On 17 Nov 2012, at 04:09, Ken Thomases k...@codeweavers.com wrote: You should be aware that a bug was introduced to Snow Leopard with its last major update (10.6.8), such that the CGImageDestination API produces corrupt ICNS files. So, if you are maintaining compatibility with that version of the OS, you probably want to use the Icon Family API instead, even though it's obsolete and deprecated. Have a radar number we can dupe? I'm never sure I understand the point of referencing somebody else's Radar number, but... I submitted rdar://problem/9798341 which was closed as a duplicate of rdar://problem/9711622. I also submitted a related bug, rdar://problem/9798414, which is about crashes whenever apps try to obtain the icon for a file and the icon is corrupt in this way. It affects (or, at least, affected at the time) the Finder, the Dock, anything which uses open or save panels, path controls, etc. That was closed as a duplicate of rdar://problem/9672474. Thanks Ken, it allows me to file duplicates for them to show Apple we care. ___ 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: Getting notified of any change to a specific NSManagedObject?
On 16 Nov 2012, at 22:00, Rick Mann rm...@latencyzero.com wrote:
On Nov 16, 2012, at 2:31 , Mike Abdullah cocoa...@mikeabdullah.net wrote:
Why are you trying to avoid a bunch of these calls? Is it just to save
yourself typing?
Typing, and code maintenance. I generally have UI that displays all (or some
subset of) the properties of one of my entities. I'd like that UI to update
if anything updates one of the models. But if there are a dozen properties,
then that's a dozen -addObserver and -removeObserver calls, in each place
where there might be UI associated with it. If I later add a new property to
the entity, I have to be sure to KVO, it, too. If I remove a bit of the UI, I
have to remember to remove the call (not strictly, but I like keeping my code
clean).
Being able to subscribe once for all changes to a single object makes these
problems go away.
This is Core Data. You have all the information available to you automatically:
NSEntity *entity = [someManagedObject entity];
for (NSPropertyDescription *aProperty in [entity properties])
{
[someManagedObject addObserver:self forKeyPath:[aProperty name] …
}
Obviously you can adjust that snippet to focus on just attributes, or skip some
out, as desired.
___
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: Getting a .icns file from IconRef data
On 17 Nov 2012, at 04:09, Ken Thomases k...@codeweavers.com wrote: On Nov 16, 2012, at 9:20 PM, Kyle Sluder wrote: On Nov 16, 2012, at 6:56 PM, John Brownie john_brow...@sil.org wrote: If I use TISGetInputSourceProperty to get the kTISPropertyIconImageURL property of a keyboard layout, it returns nil, so I get the kTISPropertyIconRef property, which gives me an IconRef. I can turn that into an NSImage with -initWithIconRef, but what I really want to do is to write out a file in the .icns format. I have not been able to find documentation on how to do that step. Lack of internet access has also complicated things, but a search just now didn't throw up anything that looked helpful. Look into CGImageDestination (aka ImageIO). If that doesn't help, you might be stuck using the old Carbon resource manager functions. You don't need the Resource Manager. There's the Icon Family API for this: SetIconFamilyData(). You should be aware that a bug was introduced to Snow Leopard with its last major update (10.6.8), such that the CGImageDestination API produces corrupt ICNS files. So, if you are maintaining compatibility with that version of the OS, you probably want to use the Icon Family API instead, even though it's obsolete and deprecated. Have a radar number we can dupe? ___ 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: Core Data fetch performance
On 12 Nov 2012, at 14:15, Joerg Simon j_si...@mac.com wrote: This summs it up really nicely: http://wbyoung.tumblr.com/post/27851725562/core-data-growing-pains Links to radar bug reports are within the blog post. The conclusion it is not usable does not hold under iOS6, since nested contexts work quite wonderfully there, but it shows problems under iOS5. Generally if you use performBlock and not performBlockAndWhait and do not use a fetched results controller at all and some other tricks, you can get it working quite well also under iOS5, but actually the code you produce is uglier than doing it manually the old way using thread confinment and merge by hand. At least in my experience. But under iOS6 nested contexts rock! So to summarise: - Child contexts synchronously route through their parent to perform fetches. The author thinks this is a mistake; I consider it an expected consequence of the design - Making changes into a parent context can be slow with no mention of a radar or details of any possible fix - Child contexts in iOS5/OS X 10.7 are pretty buggy when it comes to propogating changes *down* from their parent. This is where iOS 6/OS X 10.8 appears to have improved matters. ___ 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: Mysterious crash report
On 14 Nov 2012, at 22:10, Graham Cox graham@bigpond.com wrote: On 15/11/2012, at 8:59 AM, Nick Zitzmann n...@chronosnet.com wrote: Oh. I understand how that could happen with GC if the app tried to re-use a finalized object, but the only resurrections I've seen happen under RR or ARC were zombies… Sorry. Well, the crash is actually from libdispatch, so who knows what it's using? Our app actually only makes fairly light use of threads, and does not do any communication over the network, etc, except as might be done behind the scenes by standard classes. Apparently this occurred when cancelling a document save, though it might have nothing directly to do with that. At the time of the crash, NSToolbar was doing something on the main thread... That's the problem with this - even if I fully understood what it meant (I don't) then it's not clear that the issue is in any way fixable in our app's code. I believe the Versions system uses XPC internally. Does your app support Versions? ___ 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: WebPolicyDelegate declared where?
WebPolicyDelegate is still not a formal protocol. There is nothing for you to declare conformance to. On 1 Nov 2012, at 07:44, Gerriet M. Denkmann gerr...@mdenkmann.de wrote: My app delegate (Mac OS X) looks like this: #import WebKit/WebKit.h @interface MyAppDelegate : NSObject NSApplicationDelegate, WebPolicyDelegate But Xcode (4.5.1) complains: Cannot find protocol declarations for WebPolicyDelegate. What am I doing wrong? Gerriet. ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Mystifying index out of bounds error
Well that sounds an impossible problem, but might not be. Give us the crash
report too.
On 1 Nov 2012, at 12:11, Antonio Nunes devli...@sintraworks.com wrote:
Hi,
I have this code in my app:
- (void)keyDown:(NSEvent *)theEvent
{
unichar oneChar;
NSString*theChars = [theEvent charactersIgnoringModifiers];
if ( 0 == theChars.length ) {
return;
}
oneChar = [theChars characterAtIndex:0];
…
}
After about 10 months of the app being available, with this method unchanged,
I received a single crash report that points to a crash on the last line:
-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds
The length property of a string returns an NSUInteger, so it should never be
lower than zero. I don't see how the out of bounds error could ever happen
for index 0, when the string has a length greater than 0. Any ideas?
(Considering that I only ever received a single report for what is an often
exercised bit of code, should I just consider this a freak incident and
ignore it?)
-António
---
Don't believe everything you think
---
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
This email sent to cocoa...@mikeabdullah.net
___
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: Mystifying index out of bounds error
On 1 Nov 2012, at 14:37, Antonio Nunes devli...@sintraworks.com wrote:
On 1 Nov, 2012, at 15:24 , Mike Abdullah cocoa...@mikeabdullah.net wrote:
Well that sounds an impossible problem, but might not be. Give us the crash
report too.
12/10/2012 12:41:10: -[__NSCFConstantString characterAtIndex:]: Range or
index out of bounds
12/10/2012 12:41:10: (
0 CoreFoundation 0x7fff9354a0a6
__exceptionPreprocess + 198
1 libobjc.A.dylib 0x7fff8ba543f0
objc_exception_throw + 43
2 CoreFoundation 0x7fff93549e7c
+[NSException raise:format:] + 204
3 CoreFoundation 0x7fff9350e8ee
-[__NSCFString characterAtIndex:] + 94
4 PDF Nomad 0x00010380b5fe PDF Nomad +
1205758 ( - -[ANBorderedTextView keyDown:] (in PDF Nomad)
(ANBorderedTextView.m:91) )
5 AppKit 0x7fff8a9ba120 -[NSWindow
sendEvent:] + 9687
6 AppKit 0x7fff8a9b5744
-[NSApplication sendEvent:] + 5761
7 AppKit 0x7fff8a8cb2fa
-[NSApplication run] + 636
8 AppKit 0x7fff8a86fcb6
NSApplicationMain + 869
9 PDF Nomad 0x0001036e6f84 PDF Nomad +
8068
)
Unfortunately, I did not receive a full crash report, so I can't show
register contents.
-António
On 1 Nov 2012, at 12:11, Antonio Nunes devli...@sintraworks.com wrote:
Hi,
I have this code in my app:
- (void)keyDown:(NSEvent *)theEvent
{
unichar oneChar;
NSString*theChars = [theEvent charactersIgnoringModifiers];
if ( 0 == theChars.length ) {
return;
}
oneChar = [theChars characterAtIndex:0];
…
}
Well it all looks like your code shouldn't be able to give the above exception.
To check, there's no other calls to -characterAtIndex: in the code you omitted?
And the code you pasted is from ANBorderedTextView?
___
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: More NSFileManager Issues
On 29 Oct 2012, at 09:56, Andreas Grosam agro...@onlinehome.de wrote:
I do have even more weird issues with NSFileManager:
With NSFileManager I've created a file in the temporary directory. Attempting
to delete it, fails:
NSFileManager* fm = [[NSFileManager alloc] init];
NSLog(@tmp file: %@, [_input1000 path]);
BOOL isDirectory;
if ([fm fileExistsAtPath:[_input1000 path]
isDirectory:isDirectory] || isDirectory) {
NSError* error;
if ([fm removeItemAtURL:_input1000 error:error] == NO) {
NSLog(@ERROR: tear down testing environment with error:
%@, error);
}
}
Further to earlier answers, you're wasting your time checking if the directory
exists. Just go ahead and delete it. If the deletion fails, check the error
code domain to see if it's because the directory doesn't exist, and ignore
that specific case.
___
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: ARC question
On 29 Oct 2012, at 10:06, Vincent Habchi vi...@macports.org wrote:
Hi folks,
before aught else, all my thoughts to those of you in the Eastern coast that
are preparing themselves for a bunch of bleak days…
I’ve just a silly question (I know, I don’t post very often and I apologize
for that): I need to convert a HTML style string, with “ escapes” to normal
UTF-8. So I wrote this:
-(NSString *)convertHTMLtoUTF8:(NSString *)aString {
NSString * convertedString = [aString copy];
for (NSString * pattern in [HTMLtoUTF keyEnumerator]) {
convertedString = [convertedString
stringByReplacingOccurrencesOfString:pattern
withString:HTMLtoUTF [pattern]];
}
return convertedString;
}
where HTMLtoUTF is a dictionary of pairs {@…; :
@corresponding_UTF8_char}.
Now, my question is: is that scheme going to work correctly with ARC? Is it
not going to leak each intermediate version of ‘convertedString’?
The code is a fairly inefficient to start with, but no, it's not going to leak.
___
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: createDirectoryAtPath:withIntermediateDirectories:attributes:error: Returns NO when it exists
On 29 Oct 2012, at 09:22, Andreas Grosam agro...@onlinehome.de wrote:
I'm attempting to create a directory with NSFileManager's method. The
directory may already exist.
According the documentation
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html
the method shall return YES if the directory already exists:
Return Value
YES if the directory was created or already exists or NO if an error occurred.
However, when the directory already exists it returns NO with error parameter
set:
NSFileManager* fm = [[NSFileManager alloc] init];
NSString* tmpDir = [NSTemporaryDirectory()
stringByAppendingPathComponent:@Test];
NSError* error;
if (![fm createDirectoryAtPath:tmpDir
withIntermediateDirectories:NO
attributes:nil
error:error]) {
NSLog(@ERROR: setup test environment with error: %@, error);
}
Console:
ERROR: setup test environment with error: Error Domain=NSCocoaErrorDomain
Code=516 The file “Test” couldn’t be saved in the folder “T” because a file
with the same name already exists. UserInfo=0x100600150
{NSFilePath=/var/folders/m9/5p__qm3967qchc9_26tl85kmgn/T/Test,
NSUnderlyingError=0x100602d00 The operation couldn’t be completed. File
exists}
Do I miss something?
Is it possible you've ended up with a *file* there named Test rather than a
directory?
___
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: Sandbox, security bookmarks and trash
On 27 Oct 2012, at 12:07, Simone Tellini cocoa-...@tellini.info wrote: Hello, I need to handle an export function in a document-based application. When the user creates the document, he can also choose a couple of path where to save different exported results (e.g. ~/Documents/exporteddata.xml). The document contains security bookmarks that point to those files, so that when the user reopens the document, he can simply hit export to generated them again, overwriting the previous data. Problem is, if the user moves one of those files to the trash, the next time the application resolves the security bookmark it will point to the deleted file (ie. something like .../.Trash/...). I'd rather like the application to keep on re-creating the file at the path the user has chosen in the first place (ie. ~/Documents/exporteddata.xml). Is it possible? Or how do you handle this scenario in an user-friendly way? You're up against the design of bookmarks here. By default they resolve to the original URL, but if that no longer exists, search the disk by file ID. So in your case, the file in the trash is being found. When creating the bookmark, there is an option to resolve in the opposite order, but that won't help you here. There's also an option to create a minimal bookmark. The docs don't say what's different about that. Have you tried it at all? In a non-sandboxed app, the proper solution would be to instead create a bookmark to the folder for exporting to (e.g. ~/Documents/). You could add in a custom property to the bookmark of the filename to export to. The trick in a sandboxed app is getting write permission to that folder. NSSavePanel only gives you write access to the user-entered filename I believe, not the whole folder. Perhaps you could instead throw up an open panel, asking which folder to export to? Of course, this would have to be an app-scoped bookmark, since the target is a directory. Not sure if that's a problem for your app. Most importantly, file a radar for your needs. Maybe open a DTS incident too. ___ 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: ARC question
On 29 Oct 2012, at 12:01, Vincent Habchi vi...@macports.org wrote: Le 29 oct. 2012 à 12:53, Roland King r...@rols.org a écrit : Does CFURLCreateStringByReplacingPercentEscapes() not do this for you? I often use it going the other way from text to escaped text, not just for URLs. AFAIK, CFURLCreateStringByReplacingPercentEscapes() substitues special chars for % in URLs (e.g: “ ” ↔ “%20”) but does not handle HTML-ampersand escapes (e.g: nbsp; ↔ “ ”). I did a shallow Google search and found nothing except statements that no NSString or other Cocoa object could provide such a service. Indeed, CFURLCreateStringByReplacingPercentEscapes and friends deal in *percent* escaping, not *XML entity* escaping ___ 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: ARC question
On 29 Oct 2012, at 11:44, Vincent Habchi vi...@macports.org wrote: Le 29 oct. 2012 à 12:34, Mike Abdullah cocoa...@mikeabdullah.net a écrit : The code is a fairly inefficient to start with, but no, it's not going to leak. Thanks. I am aware of this, but since this code is going to be part of a didactic article on writing a WMS client, I emphasize clarity over performance (this is a secondary aspect). However, I am interested in knowing how you would write such a translator yourself to make it more efficient. I had initially the idea of copying every char until a ‘’, in which case the following content would be analyzed and replaced if necessary, and so on until the end of the HTML string. That would mean one single pass instead of as many as the number of pairs in the dictionary. Well, you can ask CFXMLCreateStringByUnescapingEntities() to do this on OS X, although if I recall all the CFXML functions have now sadly been deprecated. The source code for it should still be available if you search around. But in general, I would just work my way through the string looking for occurrences of '' and see if that makes up a valid escape sequence. Much of the problem if dealing with HTML rather than XML is that there are a vast range of special sequences. e.g. micro; ___ 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: ARC question
On 29 Oct 2012, at 13:55, Vincent Habchi wrote: Le 29 oct. 2012 à 14:34, Mike Abdullah cocoa...@mikeabdullah.net a écrit : Well, you can ask CFXMLCreateStringByUnescapingEntities() to do this on OS X, although if I recall all the CFXML functions have now sadly been deprecated. The source code for it should still be available if you search around. I wasn’t aware of those calls. They do not seem to be deprecated. However, I have also a lot of accented characters (é, à, û, etc.) to unescape (since the contents are in French), and CFXMLCreateStringByUnescapingEntities() provides a basic dictionary of only five elements; it is extensible, but of course at the expense of creating a custom dictionary, which, added to the necessary conversions between CFStringRef and NSString and vice-versa, would hamper the legibility of the code somewhat. How are those accented characters represented in your HTML? ___ 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: variable problem is driving me nuts
On 28 Oct 2012, at 01:18, M Pulis tooth...@fastq.com wrote: clients is not (yet) a proper NSMutableArray.. Try one of the init methods within the NSMutableArray. I'm sorry? -init is a perfectly reasonable method to call 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: Binding InfoPanel to currentDocument
On 26 Oct 2012, at 10:55, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
On 26 Oct 2012, at 16:11, Kyle Sluder k...@ksluder.com wrote:
On Oct 26, 2012, at 1:52 AM, Gerriet M. Denkmann gerr...@mdenkmann.de
wrote:
On 26 Oct 2012, at 01:11, Seth Willits sli...@araelium.com wrote:
On Oct 25, 2012, at 4:36 AM, Gerriet M. Denkmann wrote:
This works, but I have a strong feeling that there is a very obvious
better solution which I somehow cannot see.
There actually isn't an obvious solution.
Strange.
I thought that having some InfoPanel which shows data of the current
NSDocument would be a fairly common scenario.
But anyway.
I decided to follow your suggestions.
My app delegate now has:
@property (strong) GmdDocument *currentDocument;
In applicationDidFinishLaunching: it registers for
NSWindowDidBecomeMainNotification and NSWindowWillCloseNotification (not
for NSWindowDidResignMainNotification because I want my InfoPanel to keep
it's data when some other app becomes active).
The notification method is:
- (void)someWindowChanged: (NSNotification *)noti
{
NSWindow *window = [ noti object ];
if ( ![ window isMemberOfClass: [ NSWindow class ] ] ) return;//
ignore non-Windows
This check is wrong because it is too strict; it will fail for NSWindow
subclasses including NSPanel. The proper check here is -isKindOfClass:.
I am NOT interested if some panel closes (it probably would not become Main
because being a Panel).
So I use isMemberOfClass because I am not interested in Window subclasses.
This is a fundamental aspect of Cocoa programming. Cocoa is entirely free to
use its own private subclasses of NSWindow if it sees fit, and indeed some bits
of the runtime will dynamically create subclasses too. -isMemberOfClass: is
very rarely the right thing to use, and isn't correct here.
NSWindowController *windowController = [ window windowController ];
if ( windowController == nil ) return;//ignore strange windows
NSWindow has a -document accessor. Use that instead of going though the
window controller.
Yes. I saw that in your previous post. But I asked both AppKiDo and Xcode and
nobody showed me any documentation about this accessor.
So I am wary of using undocumented stuff.
It's actually a method on NSWindowController.
___
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: Need faster approach to load data in NSTableView from a file
What have you tried? You have a performance problem. The very first thing that should ever be done if you have a performance problem is head over to Instruments and find out what is slow and why. And please don't crosspost between lists. On 26 Oct 2012, at 12:17, Abhijeet Singh abhi_...@in.com wrote: Hi,In my application I am reading data from a text file and displaying it in NSTableView. There are 6 columns in my tableview. My problem is when the records in file are more it takes too long to read and display the data. e.g. It takes around 1 min to read and display 70,000 records from the file. I am using NSArrayController to update my NSTableView. Please suggest some solution to make my application faster. Should I read and display only that much data that is visible to the user (like in iphone but i dont know how is it done OSX?) and update my view on scrolling?Thanks Regards AbhijeetGet Yourself a cool, short @in.com Email ID now! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Security-scoped bookmarks linked to code signing?
On 25 Oct 2012, at 00:27, Graham Cox wrote: On 25/10/2012, at 10:05 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote: On 24 Oct 2012, at 23:31, Graham Cox wrote: On 24/10/2012, at 8:47 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: Handling security-scoped bookmarks most certainly relies upon code-signing, as without you can’t create or resolve them. Are you dealing with app or document scoped bookmarks here? App-scoped. In dev and testing no problem was encountered but in the wild we have this crash deep within -[NSURL URLByResolvingBookmarkData:options:.]. The app was incorrectly signed due to a stuff-up with the developer ID certs which was resolved, but that won't help until we get an update published. What's annoying is that the bookmark resolving just crashes rather than handle the problem gracefully, and we're still not certain whether the incorrect signing is the real cause or not (the apps were signed, just not using the correct cert). This deep connection between parts of the OS that behave very differently according to the situation they find themselves in is a recipe for very hard-to-find bugs that easily escape QA. Is it possible http://www.mikeabdullah.net/nsurl-bookmark-error-handling.html is biting you? Hmm, interesting... I wasn't setting error to nil, I am now. However, all I do with the value of error is log it if the URL returns nil. While that could crash in the circumstances your post describes, that isn't where it appears to actually be crashing. (Unfortunately I don't have a stack trace handy). Do you know of a way to force this resolution to fail so I can test it? Oops, I forgot to mention in the post that I’d seen it crash internally too, from trying to do something with the junk pointer being fed in. Sadly I don’t have a stack trace or repro steps handy :( ___ 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: Security-scoped bookmarks linked to code signing?
On 25 Oct 2012, at 22:05, Alex Zavatone z...@mac.com wrote: On Oct 25, 2012, at 11:35 AM, Sean McBride wrote: On Thu, 25 Oct 2012 00:05:44 +0100, Mike Abdullah said: Is it possible http://www.mikeabdullah.net/nsurl-bookmark-error- handling.html is biting you? Interesting bug. I wonder if everyone inside Apple is using ARC these days and therefore expecting ptr-to-object variables to be nil-initialised could explain how such a bug escaped. Cheers, I think another person on has run across a case as well. http://www.reddit.com/r/iOSProgramming/comments/120e2m/breaking_arc_retain_cycle_in_objectivec_blocks/ http://teohm.github.com/blog/2012/09/03/breaking-arc-retain-cycle-in-objective-c-blocks/ In any case, considering the huge benefit that ARC offers, for what I've done, it's been a pleasantly painless experience. I'm confused. Neither of your links seem to have anything to do with pointers and error 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
Re: Object not being drawn in Cmd + N window. Why?
Presumably your NSView subclass implements -drawRect: Is this being called at all for you non-drawing view? If it is being called, is there anything weird about the view or environment at the time? What triggers do you have to cause the view to be redrawn? On 25 Oct 2012, at 21:16, Peter Teeson ptee...@me.com wrote: Xcode 4.5.1 Lion 10.7.4 I have desktop Document project with a sub-class of NSView. Debug only version as of now. The Window has 2 instances of this sub-class (basically squares that have gradients); The only difference between the two instances are the start and stop mid points for the gradients. When I Run it to debug, a Document window opens and behaves as I expect. In particular both instances of the sub-class are drawn in the window. The Problem: But when I Cmd + N to get a new document then only one of the sub-class objects is drawn. The one that is not drawn is the second instance I added yesterday. As I said the only difference between the two instances is the value of an ivar (which I set appropriately in Document.m awakeFromNib.) My efforts to track this down have failed and I lack understanding how this could happen. After all they are using the same nib (xib). And indeed the value of each pointer to the instances are not zero. And the various ivars are correctly initialized. The Questions: How could this happen? How can I try to track it down? TIA respect… Peter P.S. I first posted this to the Xcode list but was advised to post here instead. ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Security-scoped bookmarks linked to code signing?
On 24 Oct 2012, at 02:28, Graham Cox wrote: I'm using security-scoped bookmarks to save the location of certain folders between launches so that my sandboxed app works properly. We've had reports that resolving these bookmarks sometimes crashes deep inside the security-scoping resolution but I have been unable to reproduce this. But one clue is that the apps that exhibit this problem were incorrectly codesigned (using the wrong developer certificate), and I was wondering if there was a connection between resolving SS bookmarks and codesigning. If there is that's probably the answer, but if not I'll know to keep looking for another reason. Handling security-scoped bookmarks most certainly relies upon code-signing, as without you can’t create or resolve them. Are you dealing with app or document scoped bookmarks 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: App Sandbox Container or Data Directory
On 23 Oct 2012, at 23:06, Richard Somers wrote: On Oct 23, 2012, at 2:43 PM, Kyle Sluder k...@ksluder.com wrote: If by unapproved you mean my app's sandbox hasn't been extended to include this path then you are incorrect. The user can choose the destination, and the NSURL you get back from the open panel will carry the rights to access that location. If by unapproved you mean the user my app is running as doesn't have write permission to this location, then yes that is expected behavior. I sandboxed my app in Xcode. In the app target entitlement area there are access control options for Music, Movies, Pictures, and Downloads folders. Access to these folders remained the default No Access. I launched the app and and saved a new document. In the save panel the Music folder was showing as a Recent Place. I selected this as the save location and saving was a success. As a developer, based on the entitlement settings, I was expecting failure. If the user can get to it in a save panel, that should override anything else your app has setup. Any other way would be madness. Saving a new document to the users home directory (choose the home directory in the save panel) resulted in failure. The document could not be saved. You don't have permission. As a developer this is what I expected. From a users point of view I was surprised that the save panel let the user choose a location where a save was not allowed and subsequently would result in failure. This is the surprising bit. You do have the com.apple.security.files.user-selected.read-write entitlement set, yes? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Plan for persisting preferences on iOS applications
On 24 Oct 2012, at 16:24, Alex Zavatone wrote: We're currently looking at expanding one of our applications from 1 office to up to 40. It's an app that needs an internal preference to be set and remembered through updates or reinstalls. I’m confused, what stops a regular preference from persisting across updates and reinstalls? ___ 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: Need help passing a Secure Bookmark to an XPC Service
On 24 Oct 2012, at 22:56, douglas welton wrote:
Hi All,
I am sending a NSURL, encoded as a Secure Bookmark, from the main part of my
sandboxed application to an XPC Service that handles a specific subtask. The
data is making it across the interface, but when I try to resolve the
bookmark back into an NSURL, I get the following error:
10/24/12 5:15:18.908 PM com.einsteinslegacy.silica.silicaHelper: ---
bookmark error: Error Domain=NSCocoaErrorDomain Code=259 The file couldn’t
be opened because it isn’t in the correct format. UserInfo=0x7faf418069a0 {}
Googling the text of the error message has not lead to any useful insights.
Here's what I'm doing:
• When a user selects a file, I create an object containing the URL and the
associated secure bookmark.
• I use NSKeyedArchive to create a data object, which I then pass to the XPC
service as a key-value pair in an xpc_dictionary.
• The XPC service receives the message, unpacks it and calls
NSKeyedUnarchiver to reconstitute the URL from the secure bookmark.
At this point, I check the length of the bookmark data. The value matches
the length of the originally encoded bookmark. However, when I try to
resolve the URL using the following line of code, I get nil.
self.url = [NSURL URLByResolvingBookmarkData: self.bookmark options:
NSURLBookmarkResolutionWithSecurityScope relativeToURL: nil
bookmarkDataIsStale: isStale error: bookmarkError];
The entitlements file used for the XPC Service is a duplicate of the main
application file. The XPCService dictionary in the service's info.plist has
JoinExistingSession set to YES, so I assume that both parts should have the
same set of entitlements.
Are there other factors I need to consider when passing secure bookmarks?
You don’t need a security-scoped bookmark for this. Regular bookmarks carry
access to the file until the computer next reboots.
___
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: Security-scoped bookmarks linked to code signing?
On 24 Oct 2012, at 23:31, Graham Cox wrote: On 24/10/2012, at 8:47 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: Handling security-scoped bookmarks most certainly relies upon code-signing, as without you can’t create or resolve them. Are you dealing with app or document scoped bookmarks here? App-scoped. In dev and testing no problem was encountered but in the wild we have this crash deep within -[NSURL URLByResolvingBookmarkData:options:.]. The app was incorrectly signed due to a stuff-up with the developer ID certs which was resolved, but that won't help until we get an update published. What's annoying is that the bookmark resolving just crashes rather than handle the problem gracefully, and we're still not certain whether the incorrect signing is the real cause or not (the apps were signed, just not using the correct cert). This deep connection between parts of the OS that behave very differently according to the situation they find themselves in is a recipe for very hard-to-find bugs that easily escape QA. Is it possible http://www.mikeabdullah.net/nsurl-bookmark-error-handling.html is biting 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: Memory issues when loading a document
On 23 Oct 2012, at 11:21, Ulf Dunkel dun...@calamus.net wrote: I wonder if this issue is created by our app or if it is inherent in Mac OS X: Our app creates documents which can contain various content per document page, e.g. PDF files. Assume you have created a document with 64 pages, each of them contains a full-page PDF content. The document file's weight is about 1 GB when it is saved. When users try to reload the document on a Mac with 4 GB RAM, it cannot be opened, because of a lack of memory. Important bit you haven't told us: is your app 32bit, 64bit, or both? Tracking the allocations with Instruments, I can see strange things happen: - The app itself consumes about 300 MB RAM. - The document is loaded in several steps, where the first step allocates the document size with -[NSData(NSData) initWithContentsOfFile:]. - Then the RAM for page content files (the PDFs) is allocated and the relevant PDF is being loaded - but: - The first PDF load process allocates additional RAM for the first PDF. - The 2nd PDF allocates additional RAM for the 1st and 2nd PDF. - The 3rd PDF allocates additional RAM for the 1.-3. PDF. - Etc. So this procedure sums up to about 3.5 GB RAM which of course is followed by an exception. On bigger machines, the additional RAM for the PDFs is deallocated after the document has been loaded successfully. Is this a wanted behavior of Mac OS X, or are we able to control how much RAM is being allocated in the document load process? You have very fine-grained control available to you. Read up on the document architecture and the different NSDocument methods you can override. ___ 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: App Sandbox Container or Data Directory
On 23 Oct 2012, at 19:13, Richard Somers wrote: I do not understand what is going on with an application's sandboxed container or Data directory. NSHomeDirectory for an OS X sandboxed app points here. ~/Library/Containers/bundle_id/Data The sandbox Data directory is pre-populated with items. Data/Desktop (Alias) Data/Documents Data/Downloads (Alias) Data/Library Data/Movies (Alias) Data/Music (Alias) Data/Pictures(Alias) So here are some of the unusual things. 1. If you specify No Access to the Music, Movies, Pictures, or Downloads folders for the App Sandbox you can still save a document to those folders. So much for the sandbox. What exactly do you mean by “save a document” here? 2. When a file is saved to the Documents folder in a save dialog, the file is actually saved to ~/Documents not Data/Documents. So what is Data/Documents for? Yes, the open/save panels automatically translate any locations form within the container to outside. Anything within the container is not intended for regular users to see. Your app could generate “documents” which get stored on disk in the Documents folder, but provide its own UI for managing that data perhaps, rather than the standard open/save panel approach. 3. Data/Documents is pre-populated with an iChat file alias. What is that for? Does it matter? 4. Local log files go in Data/Library/Logs but this location is not visible from Console app. So all local log files are visible from Console except for apps that are sandboxed. How can a user see local sandboxed log files? How are you generating these logs? 5. Data/Library/Preferences is pre-populated with a bunch of preference plist file aliases. One of the items is an alias to com.apple.iWork.Pages.plist. Why would my app need default access to the Pages preference plist file? This seems like a violation of sandboxing. Some other apps have relied upon this, I would guess. Can your app actually access that plist while running though? Just because it’s there as a symlink doesn’t necessarily mean the app has access to 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: Associate icon with file ext. / quick look
On 22 Oct 2012, at 16:54, Sean McBride wrote: On Wed, 17 Oct 2012 13:38:45 +0200, Jean Suisse said: My scientific cocoa app (10.6-10.8) records acquired data from devices and store them in human-readable UTF8 text files that have specific extensions (different from .txt). I have two questions related to file extensions, default application, icons and preview in quick look to submit to your expertise. The app that collects and stores the data is not the same as the one that is used to view the data (third-party text editor). I have found how to tell launch services to open the files with the third-party text editor, but I can't find how to associate the icon of my app with all the files extensions I use. How can I do that using cocoa or a shell script ? – this is my first question. Secondly, how can I tell quick look to preview the-said files just like it would any other text file ? Jean, From the sounds of it, it might be best if you just use .txt for your human readable text files. QuickLook will then generate previews, and the user's preferred text editor will open the file when double clicked. I believe declaring your file format as conforming to public.plain-text will automatically gain that ability too. ___ 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: Importance of 'keys' and other options when creating bookmarks with NSURL?
On 22 Oct 2012, at 21:23, Sean McBride s...@rogue-research.com wrote: Hi all, I have recently been replacing all my Alias Manager use with NSURL bookmarks. One thing that has surprised and confused me is the 'keys' parameter to bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error:. The docs say only An array of names of URL resource properties. It seems that if you provide nil and are later unable to resolve the bookmark, you can't find out *anything* about it, not even its original name or path. With an AliasRecord, you are always able to get basic info like that back. I found one related item in the archives: http://lists.apple.com/archives/cocoa-dev/2012/Feb/msg00165.html Is it others' experience as well that it is vital to always at least provide a few basic keys like NSURLNameKey and NSURLParentDirectoryURLKey? I've seen another thread somewhere where an Apple engineer said there was no API at present, and that a workaround was to store the path yourself under a custom key. It seems to me that storing the name + parent directory would do the trick just as well. Or on 10.8+, there's NSURLPathKey too. ___ 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: How to send fetchrequest to main context from a local context on a separate thread?
On 18 Oct 2012, at 16:01, Koen van der Drift koenvanderdr...@gmail.com wrote:
After some more searching I came to the following plan.
1. get the main context from another thread as follows:
AppDelegate *appDelegate = [[NSApplication sharedApplication] delegate];
NSManagedObjectContext *mainContext = [appDelegate managedObjectContext];
2. use performSelectorOnMainThread to execute the fetch request:
[mainContext performSelectorOnMainThread:@selector(executeFetchRequest:)
withObject:fetchRequest
waitUntilDone:YES];
However, performSelectorOnMainThread does not give a return value
back, and the selector should really be executeFetchRequest:error:
One way to solve this would be to use an NSInvocation, I think? Or
maybe wrap the executeFetchRequest in another method, call
performSelectorOnMainThread on it, and then use a notification to send
the result back.
Will try this later, does any of these approaches sound reasonable?
Here's what you want:
__block BOOL exists;
dispatch_sync(dispatch_get_main_queue, ^{
NSManagedObjectContext *context = … // grab the context
exists = … // query the context to see if the data already exists
});
Works on OS X 10.6+ and iOS4+
___
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: NSTextField not updated during large process
On 12 Oct 2012, at 23:55, Koen van der Drift koenvanderdr...@gmail.com wrote:
Man, I thought I had this all working, and after a few days of doing other
stuff, it is back to my original issue. I am now updating my textfield as
follows, so no matter from where it is called, it will always be updated on
the main thread:
- (void)updateStatus: (NSString *)status
{
NSLog(@%@, status);
[self performSelectorOnMainThread:@selector( updateStatusWrapper:)
withObject: status waitUntilDone: YES];
}
-(void)updateStatusWrapper: (NSString *) status
{
self.progressStatus = status;
}
Again, all the logs get displayed, so I know updateStatus: is called, but
again, in the parseData part, the string is not updated. For whatever reason,
updateStatusWrapper: doesn't get called. I also tried YES and NO for
waitUntilDone.
How did you determine that -updateStatusWrapper: doesn't get called?
(You could do away with that method entirely BTW, and just use
setProgressStatus: as the selector)
You're updating a property of self. How does that then update the text field?
___
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: NSTextField not updated during large process
On 14 Oct 2012, at 20:29, Koen van der Drift koenvanderdr...@gmail.com wrote:
On Oct 14, 2012, at 3:04 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote:
How did you determine that -updateStatusWrapper: doesn't get called?
(You could do away with that method entirely BTW, and just use
setProgressStatus: as the selector)
You're updating a property of self. How does that then update the text field?
Even if I use:
- (void)updateStatus: (NSString *)status
{
[statusTextField performSelectorOnMainThread:@selector( setStringValue:)
withObject: status waitUntilDone: NO]; // or YES
}
the field does not get updated.
Presumably statisTextField is an outlet? Sure you've got it hooked up right?
___
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: File browser widget
NSOpenPanel. On 27 Sep 2012, at 12:39, Qiang Y pugetso...@outlook.com wrote: Good morning everyone, I need a file browser control/widget for my project under osx. Does anyone know if cocoa provides one for developers to user in their own applications? ___ 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: dropping alias file on NSPathControl with App Sandbox
On 10 Oct 2012, at 00:16, Sean McBride s...@rogue-research.com wrote: On Sat, 6 Oct 2012 10:59:46 +0100, Mike Abdullah said: Sandboxed apps can resolve aliases and follow symlinks, but unless the destination is within their sandbox already they do not gain access to it, sadly. I recommend filing a radar requesting this. I will. Do you agree with me that pathControl:acceptDrop: should pass the resolved alias instead of the original? Or perhaps provide a setResolvesAliases: like NSOpenPanel does? I don't know really. To resolve aliases properly would require it to be some sort of privileged UI component like NSOpenPanel. Or Apple would have to add a new entitlement for this, or adjust how the sandbox works. They all *work*, but the first option sucks for developers making other similar things. ___ 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: dropping alias file on NSPathControl with App Sandbox
On 10 Oct 2012, at 15:04, Sean McBride s...@rogue-research.com wrote: On Wed, 10 Oct 2012 09:46:15 +0100, Mike Abdullah said: Sandboxed apps can resolve aliases and follow symlinks, but unless the destination is within their sandbox already they do not gain access to it, sadly. I recommend filing a radar requesting this. I will. Do you agree with me that pathControl:acceptDrop: should pass the resolved alias instead of the original? Or perhaps provide a setResolvesAliases: like NSOpenPanel does? I don't know really. To resolve aliases properly would require it to be some sort of privileged UI component like NSOpenPanel. Or Apple would have to add a new entitlement for this, or adjust how the sandbox works. They all *work*, but the first option sucks for developers making other similar things. I'm pretty sure it already is a 'privileged UI component like NSOpenPanel'. In the early seeds of 10.7, there were all sorts of sandbox violations related to NSPathControl trying to draw the icons of the file hierarchy, and failing to have access to those icons. Really? Three possible conclusions come to mind: * The sandbox has been relaxed to allow fetching of icons of ancestor folders * NSPathControl is more aware of the sandbox, and doesn't try to fetch icons it doesn't have access to * NSPathControl has some special privilege which allows it to fetch icons other components can't The last one seems least likely to me since it would be a sandbox hole application-level or malicious code could exploit. Number two also seems slightly improbably to me simply because NSPathControl still has a sandbox-related bug where it no longer recognises a path stems from the user's home directory. ___ 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: dropping alias file on NSPathControl with App Sandbox
On 10 Oct 2012, at 17:57, Uli Kusterer witness.of.teacht...@gmx.net wrote: On Oct 10, 2012, at 6:39 PM, Mike Abdullah cocoa...@mikeabdullah.net wrote: * NSPathControl is more aware of the sandbox, and doesn't try to fetch icons it doesn't have access to Not if NSPathControl runs out-of-process. The NSPathControl you create could just be an IOSurface drawn into your process's window by another process that has permissions, or even a separate window that just moves with your process's window like the accessory view in an NSOpenPanel, just the other way round. Good point. Mine certainly wasn't an exhaustive list :) All evidence suggests it draws as a regular NSControl so far though. ___ 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: dropping alias file on NSPathControl with App Sandbox
Hi Sean, Sandboxed apps can resolve aliases and follow symlinks, but unless the destination is within their sandbox already they do not gain access to it, sadly. I recommend filing a radar requesting this. On 5 Oct 2012, at 20:40, Sean McBride s...@rogue-research.com wrote: Hi all, NSOpenPanal takes care of resolving aliases/symlinks for you, which is important with App Sandbox since you want access to the target not the alias file itself. But NSPathControl, in its pathControl:acceptDrop: method, does not resolve the alias for you, and try as I may, I can't find a way to resolve it under App Sandbox. I get either: Error Domain=NSCocoaErrorDomain Code=4 The file doesn’t exist. Error Domain=NSCocoaErrorDomain Code=259 The file couldn’t be opened because it isn’t in the correct format. depending on the exact contortions. If the user granted my app access to an alias file, do I inherit access to its target? It seems not. As a programmer, I get that, but as a user, it seems counter to my intentions. Am I missing a way to resolve the alias, or is this an NSPathControl bug? Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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: Suggestions for handling old document files with file paths in a sandbox environment
On 3 Oct 2012, at 16:15, Marshall Houskeeper mhouskee...@media100.com wrote: Our document file format currently stores file paths and file alias to external files. We can potentially have several thousand references to external files stored in a document. When we move to a sandbox environment, we will store Security-Scoped Bookmarks. What is the suggested method to handling old documents with with external file references in a sandbox environment? Arguably, here's what should (have) happen(ed): 1. March 2012, OS X 10.7.3 introduces security-scoped bookmarks. You update your app to start generating them 2. June 2012, sandboxing deadline for App Store. You update your app to be sandboxed at some point around then or later. Most documents already use security-scoped bookmarks. For those that don't, prompt using open panel By leaving it until now to worry about security-scoped bookmarks, you've placed yourself at a bit of a disadvantage. How are you currently storing references to external files? Bookmarks, aliases or raw paths? Ideally you'd already be storing bookmark data, so it's no change to the document format to add in security-scoped info too. Similarly, bookmark resolution can always fail because the file has been deleted or moved somewhere the system doesn't recognise. If this happens you ought to provide some sort of alert to the user, including an open panel to locate the file or its replacement. Upgrading to a security-scoped bookmark can follow the same pattern. Of course, with a large quantity of files that could become a big pain. In which case your best bet is to use the open panel to locate the *folder* containing a number of the files. That grants you access to all the other files within the folder. ___ 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: Suggestions for handling old document files with file paths in a sandbox environment
On 3 Oct 2012, at 18:18, Sean McBride s...@rogue-research.com wrote: On Wed, 3 Oct 2012 11:15:48 -0400, Marshall Houskeeper said: Our document file format currently stores file paths and file alias to external files. We can potentially have several thousand references to external files stored in a document. When we move to a sandbox environment, we will store Security-Scoped Bookmarks. What is the suggested method to handling old documents with with external file references in a sandbox environment? I'm afraid the only choice seems to be: display an NSOpenPanel for each file. I wonder how Final Cut Pro will deal with this (and when it will get sandboxed.) Do file a bug, and pray. Mine's rdar://problem/10898972 if you want to dupe it. I've no idea how Apple could possibly offer a secure system for migrating documents to the sandbox though :( ___ 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: Suggestions for handling old document files with file paths in a sandbox environment
On 3 Oct 2012, at 19:48, Sean McBride s...@rogue-research.com wrote: On Wed, 3 Oct 2012 11:38:10 -0700, Quincey Morris said: If an item is in your sandbox, you don't need the bookmark at all (for security reasons, anyway). If the item is *not* in your sandbox, then you're going to have to ask the user for access -- possibly thousands of times. Which is of course ridiculous. Can you imagine Final Cut Pro or Xcode doing such a thing when opening their old documents? Notice Apple hasn't sandboxed those applications? My solution for now is: !-- Allows full access to filesystem, due to numerous difficulties with App Sandbox. rdar://11616142 -- keycom.apple.security.temporary-exception.files.absolute-path.read-write/key array string//string string/Volumes//string /array You still get some benefit from the sandbox (protection against network, USB, camera being compromised), but have full file system access. If you care about App Store (I don't), they may not allow this. They almost certainly won't allow it. A combo of pleading, explaining, and being well-established might help you out though. Ideally your entitlement would be read-only for most apps. Sadly though due to a bug you need write access to a file in order to generate a read-only security-scoped bookmark to it at present. ___ 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: Suggestions for handling old document files with file paths in a sandbox environment
On 3 Oct 2012, at 21:34, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Oct 3, 2012, at 12:44 , Marshall Houskeeper mhouskee...@media100.com wrote: Our plan is to use Security-Scoped Bookmarks for all new documents to store external file references when we go to the sandbox environment. In our use case, I would guess that none of the external referenced files would be stored in our sandbox. What I'm saying is, for all *new* documents, you can't create security-scoped bookmarks unless the user has authorized each (via the open panel). Thus, even for future documents, if they contain thousands of references via bookmarks, then you would have had to get them through the open panel thousands of times. Of course, this is the worst case. If the user is actually adding (say) hundreds of files from a single folder, then presumably you'd might have the user choose the folder and create a bookmark to the folder rather than the files. But the point is that AFAIK: 1 security-scoped bookmark == 1 visit to the open panel Not strictly true. All you need to generate a security-scoped bookmark is write access to the file. This may be obtained by open/save panel, or pasteboard for the specific file. But it may also be obtained by open panel, security-scoped bookmark, or temporary entitlement for a parent directory. ___ 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: Suggestions for handling old document files with file paths in a sandbox environment
On 3 Oct 2012, at 22:02, Marshall Houskeeper mhouskee...@media100.com wrote: Hi Quincey, I have no problem with the use of the open panel ( security-scoped bookmark )for creating new documents. The problem is for pre sandboxed documents or documents that come from Windows. Having the user re-authorize each external file would be very problematic and time consuming. So what's your document format here? A document that references external files that it expects to be portable between systems is a little unusual. Why not use a package-based document format? ___ 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: Suggestions for handling old document files with file paths in a sandbox environment
On 4 Oct 2012, at 20:18, Marshall Houskeeper mhouskee...@media100.com wrote: Hi Mike, Our products are a video/audio editor application and video effect plugins. In both cases, our file formats (data block for plugin data) can store many file references. Our files keep references to file types such as quicktime movies, audio files and text files as well as links to our program and bin files.We have been shipping products well before the introduction of security-scoped bookmarks. Our customers have very large libraries of edited shows that they often go back to edit or review. The data for these programs is often spread across multiple disk volumes. Right, so how are you storing that reference? A raw path? I wasn't terribly clear I'm afraid: Bookmark data was introduced in OS X 10.6. It's only with 10.7.3 that you could generate security-scoped bookmarks. The two are completely compatible though; 10.6 can happily handle security-scoped bookmarks. And 10.7+ can decode the old bookmarks, just without the ability to actually access them. Another approach you could take, or perhaps do alongside the document-scoped bookmarks, is to ask the user what disks/folders they're using for the project. You can then save an application-scoped bookmark to that, granting you access forever more. Another wrinkle to the problem: Users commonly wil move/delete and then restore to the same or another disk the audio/video/image data while changing projects. One feature that we provide that will also break under sandboxing is the ability to scan the local and network drives to relink media the has been moved or restored to a new location. Well you can pop up an open panel asking to select a folder/disk to scan. That grants you access to perform the task at least. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOperationQueue and for-loop
On 3 Oct 2012, at 13:37, Koen van der Drift koenvanderdr...@gmail.com wrote:
On Tue, Oct 2, 2012 at 10:30 PM, Koen van der Drift
koenvanderdr...@gmail.com wrote:
Thanks, I'll Google for some examples. For now, I still get an
EXC_BAD_ACCESS (code=13, address = 0x0) error in one of the threads after
several iterations. Some more digging reveals:*** -[MyObject setPosition:]:
message sent to deallocated instance 0x1075a6480. This address is the
current MyObject, and only one is created during each iteration.
It's all very confusing still. I'll keep looking.
I'm not at my Mac right now (I have a non-programming daytime job),
but I think I know what could be going on. This is some code (typed in
email program) very similar to what I did so far and which was causing
the crashes:
NSUInteger __block i, j,;
MyObject __block *newObj;
NSMutabbleArray*temp = [[NSMutableArray alloc] init];
NSOperationQueue *q = [[NSOperationQueue alloc] init];
for (i = 0; i 10; i++) {
[q addOperationWithBlock: ^{
for (j=1; j 5; j++) {
newObj = [MyObject alloc] init];
[newObj doSomething: i];
[newObj doSomethingElse: j];
[temp addObject: newObj];
}
}];
}
[q waitUntilAllOperationsAreFinished];
[self updateUIWithArray: temp];
The crash would always occur at one of the doSomething calls, and is
related to newObj already being dellocated (message sent to
deallocated instance). So maybe with all those thread going on,
newObj somehow gets re-used before it was added to temp.
So I see two solutions: 1) add a copy of newObj to temp, or 2) put
the declaration of newObj inside the inner for loop.
I won't be able to test it until later, but am I on the right track here?
Also, is waitUntilAllOperationsAreFinished needed to make sure all
iterations are completed before moving on to update the UI?
Regardless, your posted code is going to blow up sooner or later.
NSMutableArray is not safe to modify from more than a single thread at a time.
If two of your worker blocks happen to finish at the same time and call
-addObject: together, nasty things will happen.
___
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: NSOperationQueue and for-loop
On 3 Oct 2012, at 14:17, Koen van der Drift koenvanderdr...@gmail.com wrote:
On Wed, Oct 3, 2012 at 9:03 AM, Koen van der Drift
koenvanderdr...@gmail.com wrote:
Good point, thanks. So are there any workarounds for that? I'm sure
this pattern (doing lots of calculations concurrently, and store the
results in a common object for later), is used in other situations as
well.
From a quick search, would this work in my situation (will try later):
@synchronized(temp) {
[temp addObject: newObj];
}
Yes, your options boil down to:
- some kind of lock, as in your example
- shunting the -addObject: call off onto a serial queue/thread
___
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: App won't launch after a crash
What's the exception? Should appear in the console log somewhere. On 1 Oct 2012, at 12:17, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Dear all, I've received a report from a user saying that, after a crash, the app won't launch any more. The crash log looks like below. It looks to me like the app bundle has somehow got corrupted, but I've no idea what's going on really. The user has tried deleting preferences and app support directory, but it didn't help. In the end, I suggested downloading the app again. The user did that, and it launches now. Does anyone have a clue what's happening here? Cheers, Martin 0 CoreFoundation 0x7fff83ff9784 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x7fff88ff2f03 objc_exception_throw + 45 2 CoreFoundation 0x7fff83ff95a7 +[NSException raise:format:arguments:] + 103 3 CoreFoundation 0x7fff83ff9534 +[NSException raise:format:] + 148 4 Foundation 0x7fff853d0075 _decodeInt64 + 307 5 AppKit 0x7fff869cf21c -[NSMenuItem initWithCoder:] + 1765 6 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 7 Foundation 0x7fff853c9a89 -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1229 8 Foundation 0x7fff853c9fc9 -[NSArray(NSArray) initWithCoder:] + 462 9 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 10 Foundation 0x7fff853c81fd _decodeObject + 208 11 AppKit 0x7fff869d3499 -[NSMenu initWithCoder:] + 442 12 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 13 Foundation 0x7fff853c81fd _decodeObject + 208 14 AppKit 0x7fff869cf2b3 -[NSMenuItem initWithCoder:] + 1916 15 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 16 Foundation 0x7fff853c9a89 -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1229 17 Foundation 0x7fff853c9fc9 -[NSArray(NSArray) initWithCoder:] + 462 18 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 19 Foundation 0x7fff853c81fd _decodeObject + 208 20 AppKit 0x7fff869d3499 -[NSMenu initWithCoder:] + 442 21 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 22 Foundation 0x7fff853c81fd _decodeObject + 208 23 AppKit 0x7fff869cf238 -[NSMenuItem initWithCoder:] + 1793 24 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 25 Foundation 0x7fff853c81fd _decodeObject + 208 26 AppKit 0x7fff869cb1e4 -[NSNibConnector initWithCoder:] + 406 27 AppKit 0x7fff869cea46 -[NSNibControlConnector initWithCoder:] + 788 28 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 29 Foundation 0x7fff853c9a89 -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] + 1229 30 Foundation 0x7fff853c9fc9 -[NSArray(NSArray) initWithCoder:] + 462 31 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 32 Foundation 0x7fff853c81fd _decodeObject + 208 33 AppKit 0x7fff869ca351 -[NSIBObjectData initWithCoder:] + 2046 34 Foundation 0x7fff853c8d83 _decodeObjectBinary + 2548 35 Foundation 0x7fff853c81fd _decodeObject + 208 36 AppKit 0x7fff869c9a41 loadNib + 146 37 AppKit 0x7fff869c8fa1 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 248 38 AppKit 0x7fff869c8dd9 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 326 39 AppKit 0x7fff869c635b NSApplicationMain + 279 ___ 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:
Re: App won't launch after a crash
On 1 Oct 2012, at 13:13, Martin Hewitson martin.hewit...@aei.mpg.de wrote: Oops, sorry, I chopped off the top of the report. Here it is: Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: '*** -[NSKeyedUnarchiver decodeInt64ForKey:]: value for key (NSTag) is not an integer number' Well this seems like your nib is corrupted in some fashion. I wouldn't expect the preferences or app support to make a scrap of difference here. Try asking your customer to re-install to see if they're got a corrupted copy of the app. If not, go through your main menu xib carefully and look for any objects that somehow have a non-integer tag perhaps. ___ 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: NSTextField not updated during large process
On 1 Oct 2012, at 22:39, Koen van der Drift koenvanderdr...@gmail.com wrote:
On Oct 1, 2012, at 8:59 AM, Koen van der Drift koenvanderdr...@gmail.com
wrote:
Ok, I decided to use NSOperation(Queue) as it is generally recommended
over performSelectorXXX to be a more modern API, and have been reading
a bit about it. In Hillegass' Cocoa book, he uses processQueue
addOperationWithBlock, in other examples on the webs, people make
subclasses of NSOperation to put their tasks in. What's the difference
between these two appraches (if any)?
Playing around with NSOperationQueue, and I implemented it as follows. I use
this method to do some calculations, and store the results in a table.
- (void)doMyTask
{
[self cleanUp]; // clear the NSTableView
NSOperationQueue*myQueue = [[NSOperationQueue alloc] init];
[myQueue addOperationWithBlock:^(void)
{
[self parseData]; // calculate the new data and update the model
}];
// now tell everyone we're done
[self finishedTask]; // update the NSTableView and the UI
}
This works, and is faster than before, but if I run this several times in a
row, at one point I get a crash, somewhere in the parseData routine. It
could happen after ten times, or even after one time. But always at the same
point:
[self willChangeValueForKey:@myArray];
[self.myArray addObject: newObject];
[self didChangeValueForKey:@myArray];
This is called during the parse, when I update the myArray property as a
result of the parsing.
Any idea what could be going on?
Yes, you don't understand the consequences of your code yet. AppKit is not
threadsafe. You absolutely MUST only update UI on the main thread for something
like this.
Make sure your -parseData routine is threadsafe, and then bounce back over to
the main thread for -finishedTask.
___
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: NSWindowController and nib in framework
On 26 Sep 2012, at 17:37, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Sep 25, 2012, at 22:37 , Graham Cox graham@bigpond.com wrote: Is the app sandboxed? I ask because I've had reports of this same error from the odd user but have been unable to reproduce it so far. It's ONLY happening since we sandboxed though. No, the app has been around for a while and isn't sandboxed or code signed. It's possible, though, that the error only started happening after sandboxing was introduced, perhaps reflecting an implementation change in Cocoa frameworks. There's another similar error that occurred some months ago where a view controller init in the same private framework failed: self = [super initWithNibName: @MyNib bundle: [NSBundle bundleForClass: [self class]]]; It's worth noting that [self class] is a little bit dangerous here. If the instance happens to be a subclass of your class, you'll get back a different class and so search in the wrong bundle. Despite it feeling less clean, better to do: self = [super initWithNibName:@MyNib bundle:[NSBundle bundleForClass: [MyClass class]]]; ___ 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: autosavesInPlace and sandbox
On 23 Sep 2012, at 19:59, Georg Seifert georg.seif...@gmx.de wrote: Another alternative would be to ask the system to autosave to an alternative location which you do have write access to. Your users lose the ability to easily spot the autosaved copy of the doc, but otherwise it should perform fine. Can someone give me a hint on how to do that? Reimplement -autosaveDocumentWithDelegate:didAutosaveSelector:contextInfo: yourself to call through to -saveToURL:ofType:forSaveOperation:delegate:didSaveSelector:contextInfo: with a custom URL of your choosing. That said, I would strongly encourage you to adopt autosave-in-place. You describe the problem in two parts: you do not like that any mouse click might change your document Surely this applies to either saving system? No, with the new style autosaving, the file changes on disk without asking the user. That's kinda the point though; that the user no longer has to differentiate between what's in memory and what's on disk. There's just the document and that's 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
