Re: NSOutlineView: what does this even mean?

2014-05-22 Thread Graham Cox

On 23 May 2014, at 1:09 pm, Kyle Sluder  wrote:

> Did you remember to set your table view to View Based mode first? I just
> successfully dropped a Custom View _below_ the existing text cell view
> in a table view in Xcode 5.1.1.


Yep, it's set to view-based. Strange, I just can't drop a custom view there.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOutlineView: what does this even mean?

2014-05-22 Thread Kyle Sluder
On Thu, May 22, 2014, at 07:00 PM, Graham Cox wrote:
> I still have a problem doing this though. In the video, a custom table
> row view is shown as a subview of the table, and sure enough, the
> identifier and class can be set there. But when I try it, there is no
> such view available, neither already part of the table, nor as a 'table
> row view' type I can drag in from the palette (there are table cells, but
> not rows).

You're right, it appears there is no NSTableRowView in the palette.
There aren't many useful properties to be set on an instance, so I can
see why it would be omitted in lieu of just using a Custom View and
changing its class, but I think that perhaps it would be worth including
anyway for purposes of clarity.

> If I attempt to just drag a plain custom view, it's not
> possible to drop it onto the table view - it refuses the drop, or else it
> incorrectly ends up as a subview of the custom cell view there.

Did you remember to set your table view to View Based mode first? I just
successfully dropped a Custom View _below_ the existing text cell view
in a table view in Xcode 5.1.1.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOutlineView dragging weirdness [SOLVED]

2014-05-22 Thread Graham Cox
Thanks Ken, though it turned out to be a stupid error on my part (not 
unexpectedly!).

My custom cell view declared a property I called 'layer' which returns the 
associated model object. Of course this conflicts with NSView's 'layer' 
property which returns any underlying Core Animation layer, so the view drawing 
stuff got thoroughly confused. Renaming my property to something less generic 
solved the issue.


--Graham




On 22 May 2014, at 11:59 pm, Ken Thomases  wrote:

> On May 21, 2014, at 10:10 PM, Graham Cox wrote:
> 
>> I'm using NSOutlineView with view-based rows. I've set it up to allow drag 
>> and drop of a row. When the drag is initiated, it throws an exception with 
>> the following stack trace:
>> 
>> #0   0x7fff8b6d4e4a in objc_exception_throw ()
>> #1   0x7fff8d00412d in -[NSObject(NSObject) doesNotRecognizeSelector:] ()
>> #2   0x7fff8cf5f322 in ___forwarding___ ()
>> #3   0x7fff8cf5eea8 in __forwarding_prep_0___ ()
>> #4   0x7fff88c69a1d in -[NSView 
>> _layerBackedDisplayRectIgnoringOpacity:inContext:isRootView:] ()
>> #5   0x7fff88bf0104 in -[NSView displayRectIgnoringOpacity:inContext:] ()
>> #6   0x7fff8900fb6f in -[NSTableView 
>> _drawView:withCellFrameUnion:inContext:] ()
>> #7   0x7fff8901127f in __70-[NSTableView 
>> _dragImageForRowsWithIndexes:tableColumns:event:offset:]_block_invoke_2 ()
>> #8   0x7fff86dc62ae in __NSIndexSetEnumerate ()
>> #9   0x7fff890111fe in __70-[NSTableView 
>> _dragImageForRowsWithIndexes:tableColumns:event:offset:]_block_invoke ()
>> #10  0x7fff86dc62ae in __NSIndexSetEnumerate ()
>> #11  0x7fff89010c90 in -[NSTableView 
>> _dragImageForRowsWithIndexes:tableColumns:event:offset:] ()
>> #12  0x7fff89011c8f in -[NSTableView 
>> _doImageDragUsingRowsWithIndexes:event:pasteboard:source:slideBack:startRow:]
>>  ()
>> #13  0x7fff89012c11 in -[NSTableView 
>> _performClassicDragOfIndexes:hitRow:event:] ()
>> #14  0x7fff88b79a99 in -[NSTableView _performDragFromMouseDown:] ()
>> #15  0x7fff88b780c7 in -[NSTableView mouseDown:] ()
>> #16  0x7fff88c7d0d1 in -[NSOutlineView mouseDown:] ()
>> #17  0x7fff88b62a58 in -[NSWindow sendEvent:] ()
>> #18  0x7fff88b015d4 in -[NSApplication sendEvent:] ()
>> #19  0x7fff88951a19 in -[NSApplication run] ()
>> #20  0x7fff8893c7a3 in NSApplicationMain ()
>> 
>> 2014-05-22 13:01:47.040 [12101:303] -[ 
>> contentsAreFlipped]: unrecognized selector sent to instance 0x102105a00
> 
>> The exception is an unrecognised selector of -contentsAreFlipped (which is a 
>> method of CALayer) and the target of the message is my class that is the 
>>  represented by this row of the table, part of my data model.
> 
> The most common reason for this sort of thing is a memory management bug.  
> Something has a dangling reference to an object that has been incorrectly 
> deallocated, a new object has taken its place, and it messages the new object 
> as though it were the old object.
> 
> Try running with the Zombies template of Instruments.
> 
> Another possible culprit would be manipulation of the GUI from a background 
> thread.  That might also corrupt the view hierarchy's data structures 
> resulting in the dangling pointer.
> 
> Regards,
> Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSOutlineView: what does this even mean?

2014-05-22 Thread Graham Cox

On 22 May 2014, at 2:20 pm, Kyle Sluder  wrote:

> On May 22, 2014, at 12:15 AM, Graham Cox  wrote:
>> 
>> So I want to use a custom subclass of NSTableRowView so I can use an 
>> in-house UI highlighting style. It's far from obvious how to do this, even 
>> though other documentation states that this is the 'correct' approach to 
>> customising the row highlight of a view-based table. The docs only have the 
>> text above, providing a glimmer of hope.
> 
> Drag an NSTableRowView instance onto the table view, and assign it the 
> "NSTableViewRowViewKey" identifier on the identity tab.
> 
> You should watch the WWDC video where they introduce view-based NSTableViews.
> 
> --Kyle Sluder


Thanks Kyle, the video does clear up a lot of confusion.

I still have a problem doing this though. In the video, a custom table row view 
is shown as a subview of the table, and sure enough, the identifier and class 
can be set there. But when I try it, there is no such view available, neither 
already part of the table, nor as a 'table row view' type I can drag in from 
the palette (there are table cells, but not rows). If I attempt to just drag a 
plain custom view, it's not possible to drop it onto the table view - it 
refuses the drop, or else it incorrectly ends up as a subview of the custom 
cell view there. The video clearly shows this should be seen as a separate 
second row in the table. This is with IB in XCode 5.1.1. Am I missing 
something, or has IB forgotten to include this feature?

From the video, I can also see that there is a way to do this in code, so I may 
attempt that instead.

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Can MCPeerID be used as a key in a dictionary?

2014-05-22 Thread Rick Mann
Is MCPeerID usable as a key? It can be used as a key, I've verified that, but 
will I only ever get the same instance for a specific peer, even after 
disconnecting and re-connecting? If the instances are different, are the -hash 
and -equals: methods properly overridden?

If not, how can I map peers to data structures in my code? Should each peer 
generate a UUID that remains constant for the life of the app on that device, 
and send that over during connection?

Thanks!

-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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

Window gets moved to the wrong location when changing screen resolution

2014-05-22 Thread Mills, Steve
Our app has a bunch of palettes (NSPanels). One of them is usually flush 
against the menubar and against the left edge of the monitor. These palettes 
have setMovable:NO set on them, because we needed to handle moving them 
ourselves so they will snap into place. When the screen res changes, we also 
need to handle that, since having movable set to NO means Cocoa tries to keep 
them locked to the bottom edge instead of the top (hence, they don't "move" in 
Cocoa's weird bottom-up coordinate space, but to the user's normal top-down 
coordinate space, they DO move).

In my case, I'm running on an external monitor on the right (main screen), and 
my MacBook Pro's monitor on the left. That puts this palette up against the 
menubar and snapped to the left edge of the right monitor (x is 0). If I then 
change the right monitor's resolution to a smaller size, the palette gets a 
setFrame:display message, giving the same rect that it was at before. This in 
turn calls constrainFrameRect:toScreen: to make sure the window will still be 
onscreen now that the screen is smaller, but the rect that gets returned from 
the default implementation has it moved -40 in the x direction. It shouldn't be 
moving it in that direction at all! Here's the stack. Note that [SnappyPalette 
constrainFrameRect:toScreen:] does nothing in this case but call the super, 
which is NSPanel.

Note that if I swap the arrangement of the screens (MBP on right, external on 
left) and set the MBP screen to be the main screen, it doesn't do this. I'm 
also running with that goofy Displays Have Separate Spaces turned OFF. I'm 
running 10.9.3. Bug? Is there a workaround?

#0  0x01204e2b in -[SnappyPalette constrainFrameRect:toScreen:] at 
/depot/Finale_Main/FinaleDev/Finale/SRC/FIN/MAC/Cocoa/Palettes/SnappyPalette.mm:96
#1  0x968c6190 in -[NSWindow 
_overrideDefeatingConstrainFrameRect:toScreen:] ()
#2  0x961cdb77 in -[NSWindow _oldPlaceWindow:] ()
#3  0x961cd4ac in -[NSWindow _setFrameCommon:display:stashSize:] ()
#4  0x961cce4a in -[NSWindow 
_setFrame:display:allowImplicitAnimation:stashSize:] ()
#5  0x961ccd12 in -[NSWindow setFrame:display:] ()
#6  0x01204fdd in -[SnappyPalette setFrame:display:] at 
/depot/Finale_Main/FinaleDev/Finale/SRC/FIN/MAC/Cocoa/Palettes/SnappyPalette.mm:106
#7  0x968be2b8 in -[NSWindow _adjustWindowToScreen] ()
#8  0x968be6c3 in -[NSWindow _displayChanged] ()
#9  0x90a74262 in -[NSObject performSelector:] ()
#10 0x963516d5 in __44-[NSApplication 
makeWindowsPerform:inOrder:]_block_invoke ()
#11 0x9609fe66 in -[NSApplication _findWindowInOrder:passingTest:] ()
#12 0x9609fc95 in -[NSApplication makeWindowsPerform:inOrder:] ()
#13 0x96461c81 in -[NSApplication _reactToDisplayChanged:resetScreens:] ()
#14 0x962525a2 in -[NSApplication sendEvent:] ()
#15 0x00574449 in -[FCApplication sendEvent:] at 
/depot/Finale_Main/FinaleDev/Finale/SRC/FIN/MAC/Cocoa/FCApplication.mm:145
#16 0x960971dc in -[NSApplication run] ()
#17 0x96080018 in NSApplicationMain ()
#18 0x2dca in main at 
/depot/Finale_Main/FinaleDev/Finale/SRC/FIN/MAC/CocoaShell/main.mm:32

--
Steve Mills
office: 952-818-3871
home: 952-401-6255


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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

Core Data Trouble - Exception in configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:

2014-05-22 Thread Motti Shneor
Hi.

In my NSPersistentDocument based application (SDK 10.9, Deployment 10.8 XCode 
5.1.1) The main document window is loaded from a .xib file. Recently I started 
to experience the following ill behavior.

If I open an old existing document, all is well. I can manipulate, add 
entities, remove, and otherwise manipulate my document. I can save (and 
autosave) without problem.

But... If I try to create a new empty document, I experience a bad exception 
immediately after trying to save the first time, or if AutoSave's are allowed 
-- the exception is raised without me touching the keyboard, a second or two 
after launching the application and seeing the document window.

Setting up a symbolic breakpoint to catch exceptions, I discovered the 
exception happens in the following  NSPersistentDocument method:

- (BOOL)configurePersistentStoreCoordinatorForURL:(NSURL *)url ofType:(NSString 
*)fileType modelConfiguration:(NSString *)configuration 
storeOptions:(NSDictionary *)storeOptions error:(NSError **)error 
NS_AVAILABLE_MAC(10_5);


The exception: 

2014-05-22 23:06:16.729 PlanktoMetrix-II[88475:303] Cannot perform operation 
since entity with name '(null)' cannot be found
2014-05-22 23:06:16.735 PlanktoMetrix-II[88475:303] (
0   CoreFoundation  0x7fff8923db06 
__exceptionPreprocess + 198
1   libobjc.A.dylib 0x7fff8eee73f0 
objc_exception_throw + 43
2   CoreFoundation  0x7fff8923d8dc 
+[NSException raise:format:] + 204
3   AppKit  0x7fff8dff3587 
-[_NSManagedProxy _entity] + 144
4   AppKit  0x7fff8dff343a 
-[_NSManagedProxy fetchRequestWithSortDescriptors:limit:] + 95
5   AppKit  0x7fff8e4c8d2c 
-[_NSManagedProxy _storesDidChange:] + 125
6   CoreFoundation  0x7fff891efeda 
_CFXNotificationPost + 2554
7   Foundation  0x7fff8ebbf796 
-[NSNotificationCenter postNotificationName:object:userInfo:] + 64
8   CoreData0x7fff8dbaaced 
-[NSPersistentStoreCoordinator(_NSInternalMethods) 
_postStoresChangedNotificationsForStores:changeKey:options:] + 253
9   CoreData0x7fff8db9c516 
-[NSPersistentStoreCoordinator 
addPersistentStoreWithType:configuration:URL:options:error:] + 4006
10  AppKit  0x7fff8e4e9cf8 
-[NSPersistentDocument 
configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:]
 + 1567
11  PlanktoMetrix-II0x00010003bf74 
-[PMXDocument 
configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:]
 + 324
12  AppKit  0x7fff8e76bf6f 
-[NSPersistentDocument(NSDeprecatedInternal) 
_configurePersistentStoreCoordinatorForURL:ofType:error:] + 159
13  AppKit  0x7fff8e4ea35c 
-[NSPersistentDocument 
writeToURL:ofType:forSaveOperation:originalContentsURL:error:] + 362
14  AppKit  0x7fff8df602ca -[NSDocument 
_writeSafelyToURL:ofType:forSaveOperation:forceTemporaryDirectory:error:] + 618
15  AppKit  0x7fff8df60054 -[NSDocument 
_writeSafelyToURL:ofType:forSaveOperation:error:] + 28
16  AppKit  0x7fff8df5fbd9 -[NSDocument 
writeSafelyToURL:ofType:forSaveOperation:error:] + 348
17  AppKit  0x7fff8e4ebcb1 
-[NSPersistentDocument writeSafelyToURL:ofType:forSaveOperation:error:] + 957
18  AppKit  0x7fff8df5f377 
__block_global_90 + 76
19  AppKit  0x7fff8df6caef 
__block_global_97 + 242
20  AppKit  0x7fff8df6c9ee 
__block_global_96 + 339
21  AppKit  0x7fff8e3a8da0 
__block_global_89 + 1533
22  Foundation  0x7fff8eba4bce 
-[NSFileCoordinator(NSPrivate) 
_invokeAccessor:orDont:thenRelinquishAccessClaimForID:] + 229
23  Foundation  0x7fff8eb8791a 
-[NSFileCoordinator(NSPrivate) 
_coordinateWritingItemAtURL:options:error:byAccessor:] + 705
24  AppKit  0x7fff8df5ef83 -[NSDocument 
_fileCoordinator:coordinateReadingContentsAndWritingItemAtURL:byAccessor:] + 362
25  AppKit  0x7fff8df5ed07 
__66-[NSDocument 
saveToURL:ofType:forSaveOperation:completionHandler:]_block_invoke_0 + 920
26  AppKit  0x7fff8df598a9 -[NSDocument 
continueFileAccessUsingBlock:] + 222
27  AppKit  0x7fff8df59472 -[NSDocument 
_performFileAccessOnMainThread:u

Re: Document architecture: locking document files while open

2014-05-22 Thread Jens Alfke

On May 22, 2014, at 9:44 AM, Gary L. Wade  wrote:

> I've only just run across this as a potential solution to a prospective need, 
> but might Kernel Authorizations be what you need?
> https://developer.apple.com/library/mac/technotes/tn2127/_index.html

Only if you’re implementing your own filesystem as a kernel extension. That’s 
some scary low-level stuff there.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: Document architecture: locking document files while open

2014-05-22 Thread Gary L. Wade
I've only just run across this as a potential solution to a prospective need, 
but might Kernel Authorizations be what you need?

https://developer.apple.com/library/mac/technotes/tn2127/_index.html
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On May 22, 2014, at 9:21 AM, Jens Alfke  wrote:
> 
> 
>> On May 22, 2014, at 8:51 AM, Matthew LeRoy  wrote:
>> 
>> Does anyone have any idea if there is a way to get the document architecture 
>> to lock a document file when it is opened?
> 
> If you implement the lower-level read/write methods in NSDocument, you have 
> full control over opening and closing the file. You can then make whatever 
> filesystem calls you want to lock/unlock it.
> 
>> When I say “lock”, I’m talking about an exclusive file lock at the 
>> filesystem level, as in no other user or process can open, move, or delete 
>> the file.
> 
> There’s no such thing in standard Unix. The closest thing is “advisory” locks 
> (i.e. flock(2)), which are opt-in and can be ignored, and only prevent 
> modifying the file, not opening/moving/deleting it.
> 
> HFS+ does have extended attributes that, I _think_ include some sort of 
> “immutable” option, but from what you say below I don’t think that’s relevant 
> here.
> 
>> This causes all kinds of kooky and undesired behavior if a document on a 
>> remote filesystem is first opened in the Mac version (which does not lock 
>> the file), then opened concurrently by the Windows version (which locks the 
>> file).
> 
> OK, here it gets even messier, because you’re talking about locking files on 
> a file server. This involves the semantics of the file sharing protocol (you 
> didn’t specify what it is), of OS X’s client implementation of that protocol, 
> and of the underlying filesystem of the disk volume being shared. There are 
> significant differences between the behavior of NFS, AFP and SMB, and between 
> different versions of those, and different versions of OS X connecting to 
> them … it’s quite a rat-hole. I’ve seen people give vehement advice to 
> _never_ use SQLite databases on shared volumes, for example, because problems 
> with file locking can easily cause database corruption.
> 
> At a minimum you’re going to need to describe exactly what software is 
> involved on both sides, and what file server protocol is in use.
> 
> —Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSAlert & NSOpenPanel on a background thread

2014-05-22 Thread edward taffel

On May 22, 2014, at 12:24 PM, Jens Alfke  wrote:

> 
> On May 22, 2014, at 8:54 AM, edward taffel  wrote:
> 
>> i find no mention of thread safety in the NSOpenPanel doc, but the doc 
>> mentions ‘Open panels are drawn in a separate process by the powerbox’: 
>> perhaps this is the reason.
> 
> That’s done because the Open panel itself can’t be bound by the limitations 
> of a sandboxed process. It doesn’t necessarily mean that the NSOpenPanel code 
> in your process is thread-safe, though, so unless you’re told that it can be 
> used on a background thread I wouldn’t do it. Even if it works today, you 
> might find it crashes in two weeks when you try it on the (hypothetical) beta 
> of 10.10.
> 
> —Jens

based on your first advice, i had already resolved to show the NSOpenPanel on 
the main thread, as well.

thanks again!
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSAlert & NSOpenPanel on a background thread

2014-05-22 Thread Jens Alfke

On May 22, 2014, at 8:54 AM, edward taffel  wrote:

> i find no mention of thread safety in the NSOpenPanel doc, but the doc 
> mentions ‘Open panels are drawn in a separate process by the powerbox’: 
> perhaps this is the reason.

That’s done because the Open panel itself can’t be bound by the limitations of 
a sandboxed process. It doesn’t necessarily mean that the NSOpenPanel code in 
your process is thread-safe, though, so unless you’re told that it can be used 
on a background thread I wouldn’t do it. Even if it works today, you might find 
it crashes in two weeks when you try it on the (hypothetical) beta of 10.10.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSAlert & NSOpenPanel on a background thread

2014-05-22 Thread Fritz Anderson
On 22 May 2014, at 10:54 AM, edward taffel  wrote:

> i find no mention of thread safety in the NSOpenPanel doc, but the doc 
> mentions ‘Open panels are drawn in a separate process by the powerbox’: 
> perhaps this is the reason.

This is one of those rules so universal in Apple APIs that it is never 
repeated, so it can be easy to miss:

No Apple API is thread-safe unless expressly documented as being so.

Breaking the rule may work for some combinations of hardware, application, OS, 
and luck, but breaking it is as far outside the API contract as you can get. 
What you found in the documentation makes your inference reasonable, but 
“reasonable” and “true” are not the same thing.

— F


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: CGDisplaySetDisplayMode only working properly after calling twice in a row

2014-05-22 Thread Matthias Dörfelt
Thanks for the detailed reply, that makes a lot of sense. I tried putting the 
display capturing in multiple places, without any success.
My temporary work around really is to just call CGDisplaySetDisplayMode twice 
(as that is the only „easy" solution I found), as I don’t really wan’t to write 
a lot of detection code for GPU switch for something that will hopefully be 
fixed sooner than later. I might have to go down that route though.

Thanks!
Matthias

Am 22.05.2014 um 07:17 schrieb Ken Thomases :

> On May 21, 2014, at 6:25 PM, Matthias Dörfelt wrote:
> 
>> Capturing the display does not make a difference.
> 
> Did you capture it before or after creating the pixel format object?
> 
>> Anyways, your guess about the GPU switching was spot on! If I disable it, 
>> the issue disappears. Is there any way to fix this in my code? I.e. an 
>> NSOpenGLPixelFormat flag that would take that into account?
> 
> Technical Q&A QA1734: Allowing OpenGL applications to utilize the integrated 
> GPU
> https://developer.apple.com/library/mac/qa/qa1734/_index.html
> 
> That will avoid switching the GPU, but then you have to make your app cope 
> with something else changing the GPU on the fly:
> 
> Technical Note TN2229: Supporting Multiple GPUs on Mac OS X
> https://developer.apple.com/library/mac/technotes/tn2229/_index.html
> 
> 
> On May 21, 2014, at 8:45 PM, Matthias Dörfelt wrote:
> 
>> The more I think about this, the more I think this deserves a bug report.
> 
> Sure.  The behavior is clearly not something that a developer could or should 
> anticipate.
> 
>> If the automatic GPU switching gets triggered by switching the display mode 
>> in the first place, and the newly active GPU supports the same display 
>> format, shouldn’t it make sure it keeps the same format? I don’t see how 
>> that should be the job of client code. Any thoughts?
> 
> It's not changing the display mode which switches the GPU.  It's the use of 
> OpenGL.
> 
> The two GPUs use different display modes.  Since you're calling 
> CGDisplayCopyAllDisplayModes() after triggering the switch, you should be OK, 
> because you should get the modes appropriate for the discrete GPU.  
> Obviously, that's not happening.
> 
> I suspect that Quartz needs an opportunity to detect the change of GPU before 
> it starts returning the new set of display modes.  I suspect that returning 
> to the run loop between creating the pixel format and changing the display 
> mode would let it notice.  Apparently, the attempt to change the display mode 
> also gives it an opportunity to update itself.  At that point, it's too late 
> for that particular attempt but fixes the next one.  I guess.
> 
> I also suspect that capturing the display between creating the pixel format 
> object and querying the display modes would give Quartz the opportunity to 
> notice the GPU change.
> 
> Regards,
> Ken
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: Document architecture: locking document files while open

2014-05-22 Thread Jens Alfke

On May 22, 2014, at 8:51 AM, Matthew LeRoy  wrote:

> Does anyone have any idea if there is a way to get the document architecture 
> to lock a document file when it is opened?

If you implement the lower-level read/write methods in NSDocument, you have 
full control over opening and closing the file. You can then make whatever 
filesystem calls you want to lock/unlock it.

> When I say “lock”, I’m talking about an exclusive file lock at the filesystem 
> level, as in no other user or process can open, move, or delete the file.

There’s no such thing in standard Unix. The closest thing is “advisory” locks 
(i.e. flock(2)), which are opt-in and can be ignored, and only prevent 
modifying the file, not opening/moving/deleting it.

HFS+ does have extended attributes that, I _think_ include some sort of 
“immutable” option, but from what you say below I don’t think that’s relevant 
here.

> This causes all kinds of kooky and undesired behavior if a document on a 
> remote filesystem is first opened in the Mac version (which does not lock the 
> file), then opened concurrently by the Windows version (which locks the file).

OK, here it gets even messier, because you’re talking about locking files on a 
file server. This involves the semantics of the file sharing protocol (you 
didn’t specify what it is), of OS X’s client implementation of that protocol, 
and of the underlying filesystem of the disk volume being shared. There are 
significant differences between the behavior of NFS, AFP and SMB, and between 
different versions of those, and different versions of OS X connecting to them 
… it’s quite a rat-hole. I’ve seen people give vehement advice to _never_ use 
SQLite databases on shared volumes, for example, because problems with file 
locking can easily cause database corruption.

At a minimum you’re going to need to describe exactly what software is involved 
on both sides, and what file server protocol is in use.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSAlert & NSOpenPanel on a background thread

2014-05-22 Thread edward taffel

On May 22, 2014, at 11:41 AM, Jens Alfke  wrote:

> 
> On May 22, 2014, at 8:29 AM, edward taffel  wrote:
> 
>> this i have remedied. however, given the scenario where a url has vanished, 
>> i first show an NSAlert & then an NSOpenPanel to offer relink. NSOpenPanel 
>> causes no such background thread issue: do the two have variant thread 
>> safety? or is this likely to change in the future for NSOpenPanel, as well?
> 
> I suspect NSOpenPanel just doesn’t have special code to detect misuse. It 
> probably happens so often with NSAlert that they added a warning for it. 
> 
> In general, you shouldn’t call _any_ AppKit code from a background thread. 
> Ditto for any other UI-level framework that uses AppKit. (There are some 
> exceptions, like working with offscreen NSImages, but in general the Apple 
> API docs will tell you when an API is thread-safe.)

i find no mention of thread safety in the NSOpenPanel doc, but the doc mentions 
‘Open panels are drawn in a separate process by the powerbox’: perhaps this is 
the reason.

> 
> —Jens

thanks for your advice, jens.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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

Document architecture: locking document files while open

2014-05-22 Thread Matthew LeRoy
Good morning,

Does anyone have any idea if there is a way to get the document architecture to 
lock a document file when it is opened? When I say “lock”, I’m talking about an 
exclusive file lock at the filesystem level, as in no other user or process can 
open, move, or delete the file. I’m not talking about the “Locked” attribute 
that is settable through Finder’s Info panel or the document’s title bar menu.

The reason I ask is that my application has a corresponding Windows version, 
and the Windows version locks the document files when it opens them. This 
causes all kinds of kooky and undesired behavior if a document on a remote 
filesystem is first opened in the Mac version (which does not lock the file), 
then opened concurrently by the Windows version (which locks the file). At this 
point, I get all kinds of warning and error messages in the Mac application 
anytime autosave attempts to save the document, or if I attempt to save it 
manually. Unfortunately none of the messages explicitly state that the reason 
for the warnings and errors is that the file is locked by another user/process. 
Even attempting to close the document is unsuccessful if the “Ask to keep 
changes when closing documents” system setting is unchecked, because the 
application attempts to save the document, fails (because it is locked), and 
then aborts the close operation. The only way I have found to get out of the 
endless loop of warnings/errors is to choose File > Save As… and then un-check 
the “Keep changes in original document” checkbox.

Ideally I would like to prevent multiple users from opening a document file at 
the same time. The document architecture seems to automatically fail to open a 
file that is locked at the filesystem level, and we’ve coded that same behavior 
in the Windows application as well, so the only piece of the puzzle missing is 
getting the Mac application to lock the file once it has been successfully 
opened. I’m guessing I could implement the locking code manually in one of my 
NSDocument overrides, but I’m worried about properly handling all of the 
various move/rename/duplicate cases and making sure I correctly release the 
locks when those things happen; would be much better if the document 
architecture can handle all of that for me, but I don’t know if it can.

Thanks!

Matt
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSAlert & NSOpenPanel on a background thread

2014-05-22 Thread Jens Alfke

On May 22, 2014, at 8:29 AM, edward taffel  wrote:

> this i have remedied. however, given the scenario where a url has vanished, i 
> first show an NSAlert & then an NSOpenPanel to offer relink. NSOpenPanel 
> causes no such background thread issue: do the two have variant thread 
> safety? or is this likely to change in the future for NSOpenPanel, as well?

I suspect NSOpenPanel just doesn’t have special code to detect misuse. It 
probably happens so often with NSAlert that they added a warning for it. 

In general, you shouldn’t call _any_ AppKit code from a background thread. 
Ditto for any other UI-level framework that uses AppKit. (There are some 
exceptions, like working with offscreen NSImages, but in general the Apple API 
docs will tell you when an API is thread-safe.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: ANN: Couchbase Lite 1.0 database/sync library

2014-05-22 Thread Rui Pacheco
This is very interesting.

On 22 May 2014, at 17:37, Jens Alfke  wrote:

> Hey everyone, my day-job project that I’ve been toiling on for three years(!) 
> has finally gone 1.0.
>   http://www.couchbase.com/mobile
>   http://developer.couchbase.com/mobile/
>   https://github.com/couchbase/couchbase-lite-ios
> 
> In my own non-marketing speak: Couchbase Lite is an open-source framework for 
> iOS and OS X (and Android and soon .NET) that provides a JSON-based local 
> database engine with really advanced data sync / replication capabilities. It 
> lets you store all the relevant data locally, so your app can work while 
> offline, then sync changes to/from a server when the network’s available. The 
> server-side component supports databases shared between any number of users 
> so you can build multi-user and social apps. The sync protocols are 
> REST-based and open, and interoperate with CouchDB and Cloudant.
> 
> - It’s kind of like Core Data with iCloud sync, except multi-user and 
> multi-platform and the server isn’t a black box.
> - It’s kind of like Parse, except with more robust offline support, and you 
> can use your own server instead of Facebook’s (or go P2P!)
> - It’s kind of like the great offline/sync capabilities of apps like Things 
> or The Hit List, except you don’t have to spend person-years of your own 
> development time figuring out how to make it work reliably. (We already did 
> that for you :-p)
> 
> Sorry about the blurbing! I hope I’ve accumulated enough karma here to make 
> this lapse forgivable :)
> 
> —Jens
> 
> PS: Oh, also, I have to give a shout out to the great libraries like FMDB and 
> CocoaHTTPServer that I’ve leaned on. W00t!
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post 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/rui.pacheco%40gmail.com
> 
> This email sent to rui.pach...@gmail.com


--
Rui Pacheco




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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

ANN: Couchbase Lite 1.0 database/sync library

2014-05-22 Thread Jens Alfke
Hey everyone, my day-job project that I’ve been toiling on for three years(!) 
has finally gone 1.0.
http://www.couchbase.com/mobile
http://developer.couchbase.com/mobile/
https://github.com/couchbase/couchbase-lite-ios

In my own non-marketing speak: Couchbase Lite is an open-source framework for 
iOS and OS X (and Android and soon .NET) that provides a JSON-based local 
database engine with really advanced data sync / replication capabilities. It 
lets you store all the relevant data locally, so your app can work while 
offline, then sync changes to/from a server when the network’s available. The 
server-side component supports databases shared between any number of users so 
you can build multi-user and social apps. The sync protocols are REST-based and 
open, and interoperate with CouchDB and Cloudant.

- It’s kind of like Core Data with iCloud sync, except multi-user and 
multi-platform and the server isn’t a black box.
- It’s kind of like Parse, except with more robust offline support, and you can 
use your own server instead of Facebook’s (or go P2P!)
- It’s kind of like the great offline/sync capabilities of apps like Things or 
The Hit List, except you don’t have to spend person-years of your own 
development time figuring out how to make it work reliably. (We already did 
that for you :-p)

Sorry about the blurbing! I hope I’ve accumulated enough karma here to make 
this lapse forgivable :)

—Jens

PS: Oh, also, I have to give a shout out to the great libraries like FMDB and 
CocoaHTTPServer that I’ve leaned on. W00t!
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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

NSAlert & NSOpenPanel on a background thread

2014-05-22 Thread edward taffel
opening an NSAlert while scanning an autosaved document now engenders the 
following log item:

NSAlert is being used from a background thread, which is not safe.  This is 
probably going to crash sometimes. Break on void 
_NSAlertWarnUnsafeBackgroundThreadUsage() to debug.  This will be logged only 
once.  This may break in the future.

this i have remedied. however, given the scenario where a url has vanished, i 
first show an NSAlert & then an NSOpenPanel to offer relink. NSOpenPanel causes 
no such background thread issue: do the two have variant thread safety? or is 
this likely to change in the future for NSOpenPanel, as well?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: Where are the errors in NSOSStatusErrorDomain defined?

2014-05-22 Thread Sean McBride
On Thu, 22 May 2014 12:17:50 +0700, Gerriet M. Denkmann said:

>Got an NSError with:
>
>"Error Domain=NSOSStatusErrorDomain Code=560030580 "The operation
>couldn’t be completed. (OSStatus error 560030580.)""

In addition to what others have said.  Check MacErrors.h.  You can also use the 
'macerror' command line tool, though it gives nothing for 560030580, ex:

$ macerror -43
Mac OS error -43 (fnfErr): File not found

Cheers,

-- 

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: CGDisplaySetDisplayMode only working properly after calling twice in a row

2014-05-22 Thread Ken Thomases
On May 21, 2014, at 6:25 PM, Matthias Dörfelt wrote:

> Capturing the display does not make a difference.

Did you capture it before or after creating the pixel format object?

> Anyways, your guess about the GPU switching was spot on! If I disable it, the 
> issue disappears. Is there any way to fix this in my code? I.e. an 
> NSOpenGLPixelFormat flag that would take that into account?

Technical Q&A QA1734: Allowing OpenGL applications to utilize the integrated GPU
https://developer.apple.com/library/mac/qa/qa1734/_index.html

That will avoid switching the GPU, but then you have to make your app cope with 
something else changing the GPU on the fly:

Technical Note TN2229: Supporting Multiple GPUs on Mac OS X
https://developer.apple.com/library/mac/technotes/tn2229/_index.html


On May 21, 2014, at 8:45 PM, Matthias Dörfelt wrote:

> The more I think about this, the more I think this deserves a bug report.

Sure.  The behavior is clearly not something that a developer could or should 
anticipate.

> If the automatic GPU switching gets triggered by switching the display mode 
> in the first place, and the newly active GPU supports the same display 
> format, shouldn’t it make sure it keeps the same format? I don’t see how that 
> should be the job of client code. Any thoughts?

It's not changing the display mode which switches the GPU.  It's the use of 
OpenGL.

The two GPUs use different display modes.  Since you're calling 
CGDisplayCopyAllDisplayModes() after triggering the switch, you should be OK, 
because you should get the modes appropriate for the discrete GPU.  Obviously, 
that's not happening.

I suspect that Quartz needs an opportunity to detect the change of GPU before 
it starts returning the new set of display modes.  I suspect that returning to 
the run loop between creating the pixel format and changing the display mode 
would let it notice.  Apparently, the attempt to change the display mode also 
gives it an opportunity to update itself.  At that point, it's too late for 
that particular attempt but fixes the next one.  I guess.

I also suspect that capturing the display between creating the pixel format 
object and querying the display modes would give Quartz the opportunity to 
notice the GPU change.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: NSOutlineView dragging weirdness

2014-05-22 Thread Ken Thomases
On May 21, 2014, at 10:10 PM, Graham Cox wrote:

> I'm using NSOutlineView with view-based rows. I've set it up to allow drag 
> and drop of a row. When the drag is initiated, it throws an exception with 
> the following stack trace:
> 
> #00x7fff8b6d4e4a in objc_exception_throw ()
> #10x7fff8d00412d in -[NSObject(NSObject) doesNotRecognizeSelector:] ()
> #20x7fff8cf5f322 in ___forwarding___ ()
> #30x7fff8cf5eea8 in __forwarding_prep_0___ ()
> #40x7fff88c69a1d in -[NSView 
> _layerBackedDisplayRectIgnoringOpacity:inContext:isRootView:] ()
> #50x7fff88bf0104 in -[NSView displayRectIgnoringOpacity:inContext:] ()
> #60x7fff8900fb6f in -[NSTableView 
> _drawView:withCellFrameUnion:inContext:] ()
> #70x7fff8901127f in __70-[NSTableView 
> _dragImageForRowsWithIndexes:tableColumns:event:offset:]_block_invoke_2 ()
> #80x7fff86dc62ae in __NSIndexSetEnumerate ()
> #90x7fff890111fe in __70-[NSTableView 
> _dragImageForRowsWithIndexes:tableColumns:event:offset:]_block_invoke ()
> #10   0x7fff86dc62ae in __NSIndexSetEnumerate ()
> #11   0x7fff89010c90 in -[NSTableView 
> _dragImageForRowsWithIndexes:tableColumns:event:offset:] ()
> #12   0x7fff89011c8f in -[NSTableView 
> _doImageDragUsingRowsWithIndexes:event:pasteboard:source:slideBack:startRow:] 
> ()
> #13   0x7fff89012c11 in -[NSTableView 
> _performClassicDragOfIndexes:hitRow:event:] ()
> #14   0x7fff88b79a99 in -[NSTableView _performDragFromMouseDown:] ()
> #15   0x7fff88b780c7 in -[NSTableView mouseDown:] ()
> #16   0x7fff88c7d0d1 in -[NSOutlineView mouseDown:] ()
> #17   0x7fff88b62a58 in -[NSWindow sendEvent:] ()
> #18   0x7fff88b015d4 in -[NSApplication sendEvent:] ()
> #19   0x7fff88951a19 in -[NSApplication run] ()
> #20   0x7fff8893c7a3 in NSApplicationMain ()
> 
> 2014-05-22 13:01:47.040 [12101:303] -[ 
> contentsAreFlipped]: unrecognized selector sent to instance 0x102105a00

> The exception is an unrecognised selector of -contentsAreFlipped (which is a 
> method of CALayer) and the target of the message is my class that is the 
>  represented by this row of the table, part of my data model.

The most common reason for this sort of thing is a memory management bug.  
Something has a dangling reference to an object that has been incorrectly 
deallocated, a new object has taken its place, and it messages the new object 
as though it were the old object.

Try running with the Zombies template of Instruments.

Another possible culprit would be manipulation of the GUI from a background 
thread.  That might also corrupt the view hierarchy's data structures resulting 
in the dangling pointer.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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: Creating Url with Fragment

2014-05-22 Thread Gerriet M. Denkmann

On 22 May 2014, at 17:25, Mike Abdullah  wrote:

> 
> On 22 May 2014, at 11:07, Gerriet M. Denkmann  wrote:
> 
>> 
>> This works:
>>  NSString *fragment = 
>>  NSString *absString = [ @"https://translate.google.com/#"; 
>> stringByAppendingString: fragment ];
>>  NSURL *url = [ [ NSURL alloc ] initWithString: absString ];
>> 
>> But I would like to use something like this:
>>  NSURL *url = [ [ NSURL alloc ] initWithScheme: @"https"  host: 
>> @"translate.google.com"  fragment: fragment ];
>> 
>> There is a method to get a fragment from an NSURL, but I cannot find 
>> anything to *set* or append a fragment.
>> 
>> What am I missing?
> 
> NSURLComponents.
> 
Thanks a lot!

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Creating Url with Fragment

2014-05-22 Thread Mike Abdullah

On 22 May 2014, at 11:07, Gerriet M. Denkmann  wrote:

> 
> This works:
>   NSString *fragment = 
>   NSString *absString = [ @"https://translate.google.com/#"; 
> stringByAppendingString: fragment ];
>   NSURL *url = [ [ NSURL alloc ] initWithString: absString ];
> 
> But I would like to use something like this:
>   NSURL *url = [ [ NSURL alloc ] initWithScheme: @"https"  host: 
> @"translate.google.com"  fragment: fragment ];
> 
> There is a method to get a fragment from an NSURL, but I cannot find anything 
> to *set* or append a fragment.
> 
> What am I missing?

NSURLComponents.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post 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

Creating Url with Fragment

2014-05-22 Thread Gerriet M. Denkmann

This works:
NSString *fragment = 
NSString *absString = [ @"https://translate.google.com/#"; 
stringByAppendingString: fragment ];
NSURL *url = [ [ NSURL alloc ] initWithString: absString ];

But I would like to use something like this:
NSURL *url = [ [ NSURL alloc ] initWithScheme: @"https"  host: 
@"translate.google.com"  fragment: fragment ];

There is a method to get a fragment from an NSURL, but I cannot find anything 
to *set* or append a fragment.

What am I missing?

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Where are the errors in NSOSStatusErrorDomain defined?

2014-05-22 Thread Uli Kusterer
On 22 May 2014, at 07:50, Ben Kennedy  wrote:
> If that is indeed the context in which Gerriet is receiving the error, it 
> sounds as though the routine generating it is assigning an inappropriate 
> error domain then, no? Surely it should be a CoreAudio-related domain 
> (specifically for the reason illustrated by this thread). 

Yes and no.

These errors predate NSError and error domains. NSOSStatusErrorDomain wraps all 
the errors that fit into the (pre-MacOS X) OSStatus error code type. So pretty 
much all Carbon-descended API and the few calls in CoreFoundation that return 
more than a BOOL are encapsulated in the single NSOSStatusErrorDomain. This 
includes lower-level API like CoreAudio and CoreGraphics.

Would it be nicer and cleaner if the OS used a separate domain for errors from 
separate frameworks? Possible.

In general, the easiest way to find these error codes is quoting them in Google 
and doing a search of "Project and Frameworks” for that number and look at 
whatever constant name it is. Sadly, some errors are defined sequentially in 
enums, so sometimes the actual number doesn’t appear in the code, in which case 
it gets more difficult. CoreAudio’s odd choice of redefining the integer 
OSStatus as a FourCharCode also doesn’t make finding error codes easier.

If you see an error code is an incredibly low number, you can use a tool like 
my ValueConverter 
(http://zathras.de/angelweb/macapplications.htm#ValueConverter), though, to 
view it as a four char code and then search for that.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com