Re: Lion doesn't like tricky.key.paths in bindings?

[Charles Srstka]

On Jul 28, 2011, at 9:42 PM, Kyle Sluder wrote:

> If you're not returning precisely the same NSString instance every
> time KVO thinks you should, then you are violating the rules and KVO
> has every right to complain.
> 
> KVO doesn't do an -isEqual: on the result of your method. It does
> pointer equality. Something changed on Lion that causes it to now care
> that the return value of your method stays constant when it should.

But doesn’t that undermine the whole idea of encapsulation? Suppose I have an 
object that represents a file in the file system, and it’s got a property that 
represents a path:

- (NSString *)path {
return [[someStringIvar retain] autorelease];
}

- (void)setPath:(NSString *)newPath {
if(newPath != someStringIvar) {
[someStringIvar release];
someStringIvar = [newPath copy];
}
}

But later on, I refactor the object so that it uses URLs instead of paths, but 
I want to leave the -path method there for callers that might still be using 
the old interface, so I rewrite it like this:

- (NSURL *)URL {
return [[someURLIvar retain] autorelease];
}

- (void)setURL:(NSURL *)newURL {
if(newURL != someURLIvar) {
[someURLIvar release];
someURLIvar = [newURL copy];
}
}

- (NSString *)path {
return [[self URL] path];
}

- (void)setPath:(NSString *)newPath {
[self setURL:[NSURL fileURLWithPath:newPath]];
}

So what you are telling me is that even though the new -path method will return 
a string containing the same value every time, since it’s not going to be the 
same *pointer*, this is going to foul up bindings? That in order for bindings 
to work properly, all the accessors can’t do anything but naïvely return some 
instance variable directly, so that you might as well just be using a struct?

Why the heck would you design something like this?

Charles___

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

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

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

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

Re: Lion doesn't like tricky.key.paths in bindings?

[Charles Srstka]

On Jul 28, 2011, at 9:42 PM, Kyle Sluder wrote:

> If you're not returning precisely the same NSString instance every
> time KVO thinks you should, then you are violating the rules and KVO
> has every right to complain.
> 
> KVO doesn't do an -isEqual: on the result of your method. It does
> pointer equality. Something changed on Lion that causes it to now care
> that the return value of your method stays constant when it should.

Actually, on further thought, this can’t be true, can it? Plenty of methods 
built right into the frameworks create objects on the fly — call valueForKey: 
to retrieve a property that’s declared as an NSInteger, and you’ll get an 
NSNumber object that was created to wrap it. Send valueForKey: to an array, and 
you get a newly-created array containing the results of getting that property 
from each object in the array. Both of these times, you’re not going to have 
the same pointer on subsequent calls, and these work fine, so pointer 
discrepancies can’t be the cause of his problem.

Charles___

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

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

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

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

UIModalTransitionStylePartialCurl with UITabBarController

[Dan Hopwood]

This question has been asked a lot e.g.
herebut
as far as I can see is yet to be answered in full.

I have a `UITabBarController` with a `UINavigationController` as the root vc
for one of the tabs, which itself has a `MKMapView` as its root vc. The
behaviour I want is for the map to partially curl upwards, *while leaving
the tab bar in place* (similar to the Maps app).

So far all I have managed to get working is for the whole view to curl,
which isn't as nice.

Solutions I have seen are to set the `hidesBottomBarWhenPushed` property to
NO, which would make sense however this doesn't seem to work, (unless I am
doing something wrong).

For clarity, my code is as follows:

MyVC *aView = [MyVC init]; // init here is just a static convenience
method that does the alloc etc.
aView.modalTransitionStyle = UIModalTransitionStylePartialCurl;
aView.hidesBottomBarWhenPushed = NO;

For the presenting part, I have tried the two alternatives below, neither of
which seem to work:

[self presentModalViewController:updateStatus animated:YES];
[[self navigationController] presentModalViewController:updateStatus
animated:YES];

Any help much appreciated.
___

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

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

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

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

Re: Filter an array

[Chris Paveglio]

Looks like the method -[NSArray pathsMatchingExtensions:] is case sensitive. I 
don't have a problem declaring all the variations I need in lower or upper; but 
I'll see if speed is an issue on a large number of files.

>The docs don't state whether it's case sensitive or not.


Thanks for the suggestions for all the options here. I might also check into 
the UTI's in case users don't have a file extension.
Chris
___

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

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

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

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

Receiving Unicode Input in NSView

[Bill Appleton]

Hi all,

I have seen this issue come up a lot, but there isn't much information on
how to receive unicode input in a NSView.

(I know we are supposed to just type in a NSTextField but that is impossible
in our situation where the app must run stand-alone and as a browser
plugin).

we used to call interpretKeyEvents in the keyDown handler and the InsertText
handler would get the unicode string, I guess this stopped working with a
system update a while back.

Now i think there are 2 ways to do this:

1) subclass nsview and make it conform to the NSTextInputClient protocol

i have been picking away at this, i added the NSTextInputClient handlers but
they aren't being called. a working example or a pointer would help if
anyone has done this.

2) use a fake NSTextField and try to use that for gathering the unicode as
it arrives.

I have seen someone recommend NSWindow fieldEditor:forObject: to do this.
This sounds pretty bad and i have a lot of uncertainty as to how to make
this work right.

So do you guys have a recommendation here?

thanks in advance
___

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

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

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

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

Re: Drawing performance in CALayer

[Kyle Sluder]

On Thu, Jul 28, 2011 at 11:23 PM, Graham Cox  wrote:
> Am I right in thinking that using calls such as NSRectFill within a CALayer 
> like this is really making OpenGL calls behind the scenes? If so it's 
> probably going as fast as it can. On my middling iMac it's acceptably fast, 
> but laptops start to show a bit of a slow-down.

No, it's doing the drawing on the CPU on a bitmap context in RAM, then
uploading this as a texture to the GPU.

> I can think of ways to optimise this, but first I want to know whether this 
> is truly the fastest way to draw a simple solid rectangle in this situation. 
> If not, what's better?

Set the backgroundColor of the layer and don't draw anything into it.
This will just draw a GL quad.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Lion doesn't like tricky.key.paths in bindings?

[Kyle Sluder]

On Fri, Jul 29, 2011 at 12:39 AM, Charles Srstka
 wrote:
> Actually, on further thought, this can’t be true, can it? Plenty of methods
> built right into the frameworks create objects on the fly — call
> valueForKey: to retrieve a property that’s declared as an NSInteger, and
> you’ll get an NSNumber object that was created to wrap it. Send valueForKey:
> to an array, and you get a newly-created array containing the results of
> getting that property from each object in the array. Both of these times,
> you’re not going to have the same pointer on subsequent calls, and these
> work fine, so pointer discrepancies can’t be the cause of his problem.

Yes, this works, but I believe the problem is that KVO is getting two
different pointer values for the same key at a time where it thinks
the value should be constant. Of course, I don't have access to the
KVO internals, but I've seen this happen if you call -myProperty from
within a KVO prior notification for that property, and it returns a
different value than when KVO started notifying you of the property
change.

KVO maintains a stack of properties currently being notified. It also
reads the current value of the property in -willChangeValueForKey: for
the purposes of sending prior notifications and for filling in the
NSKeyValueChangeOldKey. My gut is telling me that someone's calling
-valueForKey: in response to a KVO notification, and KVO is noticing
that the pointer value it's returning does not match the pointer value
it has in its internal "I'm notifying people about this change" table.

Of course, my gut could be very wrong.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Filter an array

[Wade Tregaskis]

> Further to earlier answers, bear in mind you've got no guarantee that file 
> extensions are correct, or even exist. Plus of course, you might have both 
> .jpg and .jpeg. You might well be better iterating through, finding the UTI 
> of each file, and working from that.

Oooh, that's kind of embarrassing. :)  Yes, that's a very good point, that we 
all should have realised before worrying about the details of file extension 
comparison.  So I'll retract my prior recommendations and instead suggest using 
something like:

// Provided parameters:
//
//paths:  Collection of NSStrings, the absolute paths of the items in 
question.
//supportedTypes:  Collection of UTIs (NSStrings) that you're looking for.

for (NSString *path in paths) {
NSURL *url = [[NSURL alloc] initFileURLWithPath:path];
NSString *uti = nil;
NSError *error = nil;

if ([url getResourceValue:&uti forKey:NSURLTypeIdentifierKey 
error:&error]) {
for (NSString *supportedType in supportedTypes) {
if (UTTypeConformsTo(uti, supportedType)) {
// You have a match.
}
}
} else {
// Handle error
}
}

There's a lot of nasty enumeration there, rather than hashtables which make me 
much happier, but I don't know of a better way off hand.

However, -[NSURL getResourceValue:forKey:error:] is only available in iOS 4.0 
and later.  So you'll have to find another route if you're targeting earlier 
than that.

Also, if your paths are actually the contents of a folder (or folders), you 
could use -[NSFileManager 
enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:], which will 
handle the enumeration for you as well as possibly being faster - one of the 
promised potentials of that method is that, since you tell it up front what 
file properties you're interested in, it can pre-fetch and/or batch-fetch them. 
 Again, though, that's only available on iOS starting at version 4.0.

Addendum:  See also the Uniform Type Identifiers Overview for more information 
on UTIs.  You'll note, for example, that I didn't just do isEqualToString: when 
comparing them, and for good reason - all explained in the docs.
___

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

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

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

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

Re: What could cause a fast enumeration mutation error in updating tracking areas?

[Raleigh Ledet]

Do you have another thread that is doing something with tracking areas?

-raleigh

On Jul 28, 2011, at 11:33 PM, Gideon King wrote:

> Hi, I have a problem where a few users of my program are getting the 
> following exception:
> 
> 0 CoreFoundation 0x7fff862df7b4 __exceptionPreprocess + 180
> 1 libobjc.A.dylib 0x7fff84b0ff03 objc_exception_throw + 45
> 2 CoreFoundation 0x7fff863375bf __NSFastEnumerationMutationHandler + 303
> 3 AppKit 0x7fff83ec8660 -[NSView trackingAreas] + 271
> 4 AppKit 0x7fff83f1d025 -[NSView(NSInternal) _updateTrackingAreas] + 249
> 5 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 6 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 7 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 8 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 9 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 10 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 11 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 12 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 13 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 14 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 15 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 16 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 17 CoreFoundation 0x7fff86259d6e CFArrayApplyFunction + 222
> 18 AppKit 0x7fff83f1d413 -[NSView(NSInternal) _updateTrackingAreas] + 1255
> 19 AppKit 0x7fff83f1ce28 _handleInvalidCursorRectsNote + 451
> 20 CoreFoundation 0x7fff8629eb37 __CFRunLoopDoObservers + 519
> 21 CoreFoundation 0x7fff8627a464 __CFRunLoopRun + 468
> 22 CoreFoundation 0x7fff86279dbf CFRunLoopRunSpecific + 575
> 23 HIToolbox 0x7fff854f774e RunCurrentEventLoopInMode + 333
> 24 HIToolbox 0x7fff854f7553 ReceiveNextEventCommon + 310
> 25 HIToolbox 0x7fff854f740c BlockUntilNextEventMatchingListInMode + 59
> 26 AppKit 0x7fff83ef1eb2 _DPSNextEvent + 708
> 27 AppKit 0x7fff83ef1801 -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
> 28 AppKit 0x7fff83eb768f -[NSApplication run] + 395
> 29 OmniAppKit 0x00010055c774 -[OAApplication run] + 132
> 30 AppKit 0x7fff83eb03b0 NSApplicationMain + 364
> 31 NovaMind5 0x00012018 start + 52
> 32 ??? 0x0002 0x0 + 2
> 
> 
> But all the tracking areas I am adding are done in the initialization of the 
> views or awakeFromNib, and not updated after that. I do use tracking rects 
> and tooltip rects, and wonder whether they use tracking areas behind the 
> scenes, and whether there are specific places in the code I need to avoid 
> changing them. 
> 
> I haven't been able to reproduce the problem here, so can't catch it in the 
> act so far.
> 
> Any suggestions as to what to look for?
> 
> Thanks
> 
> Gideon
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/ledet%40apple.com
> 
> This email sent to le...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: MPMoviePlayerController Fast forward

[Matt Neuburg]

On Thu, 28 Jul 2011 15:06:29 -0400, Steve Kostrey  said:
>I've implemented MPMoviePlayerController (iPhone/iPad) and I'm playing videos 
>without trouble but I'm not sure how to receive an event from the Fast forward 
>overlay button.
>I've tried everything the documentation suggests about remote control but I'm 
>not sure that's the way.

I guess it all depends on what you mean by "the fast forward overlay button". 
The remote control events are for events sent by the remote interface - that 
is, the buttons in a physical device (such as the earphones that come with an 
iPhone), or the buttons that you see when you double-click the Home button and 
swipe left.

But if you are referring to the buttons that are *part* of the 
MPMoviePlayerController's view interface, then those have nothing to do with 
remote control.

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

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

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

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

Re: UIImageView subclasses

[Matt Neuburg]

On Fri, 29 Jul 2011 00:24:56 -0500, William Squires  said:
>Hi all!
>  Here's what I've got: (Xcode 3.2.5 - iOS SDK 4)
>
>A view controller that dynamically creates UIImageView subclass instances as 
>subviews in it's awakeFromNib
>
>According to the documentation, UIImageView subclasses do not enable user 
>interaction by default, so
>
>...
>// Create a UIImageView that'll animate Number1.png through Number8.png, and 
>load Number.png as the
>// default (non-aminating) image
>MyImageView *iv = [[MyImageView alloc] initWithBaseName:@"Number"];
>[iv setUserInteractionEnabled:YES];
>// ...
>// Don't know what to do here!
>// ...
>[self.view addSubview:iv];
>...
>
>Okay, now what?

It depends on what you want to do. Is it that you'd like to know when a 
UIImageView is tapped? In that case, my book tells you how (using a gesture 
recognizer), and you can download code that demonstrates one approach:

https://github.com/mattneub/Programming-iOS-4-Book-Examples/tree/master/p424hitTesting

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

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

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

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

Re: A trap with full screen in Lion

[vincent habchi]

Le 29 juil. 2011 à 04:50, Gideon King a écrit :

> Sorry - missed an important bit of info - this applies for a view that is in 
> the toolbar. So far as I am aware, it 

The toolbar is supposed to disappear in full screen mode, no?
V.

___

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

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

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

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

NSView-based NSTableView: How to animate when using bindings?

[Daniel Vollmer]

Helloes,

I'm experimenting with migrating from my formerly NSCollectionView-based 
drawing to using an NSView-based table-view (as the tableView is conceptually 
closer to what I'm displaying 
(http://www.maven.de/code/wowplot/example_chains.png).

The NSCollectionView had really nice animation behaviour for inserting and 
removing items and well as changing the minimum item size (which I used to 
force the collectionView to expand into its scrollView and thus "zoom" into my 
content).
I'm not sure how to replicated these animations in an NSTableView when 
populating it with bindings, as I cannot call both [arrayController 
insertObject:] as well as [tableView insertRowsAtIndexes:withAnimation:].

Is combining the animation properties of an NSView-based NSTableView possible 
when using it via Cocoa bindings?

Thanks,
Daniel.

___

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

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

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

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

Re: A trap with full screen in Lion

[Kyle Sluder]

On Fri, Jul 29, 2011 at 9:56 AM, vincent habchi  wrote:
> The toolbar is supposed to disappear in full screen mode, no?

No.

It hangs out at the top of the screen and slides down out of the way
of the menu bar when you move your mouse up to the top edge.

This is why it needs to move into its own window.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Jerry Krinock]

I received a reply off-list suggesting that I file a bug.  And I'll certainly 
do that, but before I do that I'd like to confirm that I'm not overlooking 
something obvious.

The fact that these methods throw exceptions if their input data cannot be 
processed is very uncharacteristic of the Cocoa frameworks.  When invoking 
-archivedDataWithRootObject: on, say, dictionary, finding an un-encodeable 
object buried somewhere in the dictionary would seem to be quite common.  
Similarly, when invoking -unarchiveObjectWithFile:, no programmer can guarantee 
what may be found on the filesystem.

Has anyone else ever noticed that these methods are exceptionally lame in their 
lack of error-handling capability?  Is there something about the (un)archiving 
process which makes it particularly inefficient to detect and handle errors?

Jerry

On 2011 Jul 28, at 23:24, Jerry Krinock wrote:

> With each major update of Mac OS X, Apple updates more classes to return 
> proper NSErrors, deprecating methods which either don't give errors or give 
> outmoded error representations.
> 
> But what about NSKeyedArchiver and NSKeyedUnarchiver, in particular these 
> methods…
> 
> +[NSKeyedArchiver archivedDataWithRootObject:]
> +[NSKeyedUnarchiver unarchiveObjectWithFile:]
> 
> -unarchiveObjectWithFile: takes a file, for heaven's sake.  If someone has 
> messed with the file, eek, it raises an exception.  I generally enclose these 
> methods in @try{} to avoid that.  Very primitive!
> 
> Does anyone know why these methods not marked for deprecation?  Is there a 
> reason why we don't we have 21st-century archive/unarchive methods that 
> return errors instead of raise exceptions?

___

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

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

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

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

Re: Receiving Unicode Input in NSView

[Aki Inoue]

Bill,

> we used to call interpretKeyEvents in the keyDown handler and the InsertText
> handler would get the unicode string, I guess this stopped working with a
> system update a while back.
We have always required the first responder to adopt either NSTextInput or 
NSTextInputClient for handling text input with complex user interaction 
required such as the deadkey sequence.

> 1) subclass nsview and make it conform to the NSTextInputClient protocol
> 
> i have been picking away at this, i added the NSTextInputClient handlers but
> they aren't being called. a working example or a pointer would help if
> anyone has done this.
Yes, we do have a sample.  Check out 
file://localhost/Developer/Examples/AppKit/TextInputView/

Aki

On 2011/07/29, at 7:31, Bill Appleton wrote:

> Hi all,
> 
> I have seen this issue come up a lot, but there isn't much information on
> how to receive unicode input in a NSView.
> 
> (I know we are supposed to just type in a NSTextField but that is impossible
> in our situation where the app must run stand-alone and as a browser
> plugin).
> 
> we used to call interpretKeyEvents in the keyDown handler and the InsertText
> handler would get the unicode string, I guess this stopped working with a
> system update a while back.
> 
> Now i think there are 2 ways to do this:
> 
> 1) subclass nsview and make it conform to the NSTextInputClient protocol
> 
> i have been picking away at this, i added the NSTextInputClient handlers but
> they aren't being called. a working example or a pointer would help if
> anyone has done this.
> 
> 2) use a fake NSTextField and try to use that for gathering the unicode as
> it arrives.
> 
> I have seen someone recommend NSWindow fieldEditor:forObject: to do this.
> This sounds pretty bad and i have a lot of uncertainty as to how to make
> this work right.
> 
> So do you guys have a recommendation here?
> 
> thanks in advance
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com
> 
> This email sent to a...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: MPMoviePlayerController Fast forward

[Heath Borders]

You could do key-value observing on currentPlaybackRate.

http://developer.apple.com/library/ios/#documentation/mediaplayer/reference/MPMediaPlayback_protocol/Reference/Reference.html#//apple_ref/occ/intfp/MPMediaPlayback/currentPlaybackRate

-Heath Borders
heath.bord...@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com



On Thu, Jul 28, 2011 at 2:06 PM, Steve Kostrey  wrote:
> I've implemented MPMoviePlayerController (iPhone/iPad) and I'm playing videos 
> without trouble but I'm not sure how to receive an event from the Fast 
> forward overlay button.
> I've tried everything the documentation suggests about remote control but I'm 
> not sure that's the way.
>
> I've tried the following code:
>
> [[UIApplication sharedApplication] beginReceivingRemoteControlEvents];
> [self becomeFirstResponder];
>
> - (BOOL)canBecomeFirstResponder {
>  return YES;
> }
>
> - (void)remoteControlReceivedWithEvent:(UIEvent *)event {
>
>  if( event.type == UIEventTypeRemoteControl ) {
>      NSLog(@"sub type: %d", event.subtype);
>  }
> }
>
> Not sure where to place this (and when I place it in the header I get 
> redefinition errors):
>
> typedef enum {
>  // available in iPhone OS 3.0
>  UIEventSubtypeNone                              = 0,
>
>  // for UIEventTypeMotion, available in iPhone OS 3.0
>  UIEventSubtypeMotionShake                       = 1,
>
>  // for UIEventTypeRemoteControl, available in iPhone OS 4.0
>  UIEventSubtypeRemoteControlPlay                 = 100,
>  UIEventSubtypeRemoteControlPause                = 101,
>  UIEventSubtypeRemoteControlStop                 = 102,
>  UIEventSubtypeRemoteControlTogglePlayPause      = 103,
>  UIEventSubtypeRemoteControlNextTrack            = 104,
>  UIEventSubtypeRemoteControlPreviousTrack        = 105,
>  UIEventSubtypeRemoteControlBeginSeekingBackward = 106,
>  UIEventSubtypeRemoteControlEndSeekingBackward   = 107,
>  UIEventSubtypeRemoteControlBeginSeekingForward  = 108,
>  UIEventSubtypeRemoteControlEndSeekingForward    = 109,
> } UIEventSubtype;
>
>
> Bottom line is I would love to receive the FF event. Has anyone successfully 
> done 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:
> http://lists.apple.com/mailman/options/cocoa-dev/heath.borders%40gmail.com
>
> This email sent to heath.bord...@gmail.com
>
___

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

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

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

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Jens Alfke]

On Jul 29, 2011, at 11:12 AM, Jerry Krinock wrote:

> When invoking -archivedDataWithRootObject: on, say, dictionary, finding an 
> un-encodeable object buried somewhere in the dictionary would seem to be 
> quite common.

This is a case of passing invalid data, so throwing an exception is 
appropriate. It’s implicit that when you archive an object graph, all the 
objects in it must be archivable.

>  Similarly, when invoking -unarchiveObjectWithFile:, no programmer can 
> guarantee what may be found on the filesystem.

That on the other hand is a valid issue, since you should Never Trust Input 
Data.

> Has anyone else ever noticed that these methods are exceptionally lame in 
> their lack of error-handling capability?  Is there something about the 
> (un)archiving process which makes it particularly inefficient to detect and 
> handle errors?

There isn’t any way to pass the errors back from the nested calls, is my guess. 
Consider if you’re unarchiving and your -initWithCoder: method calls 
-decodeObjectForKey: but the unarchiving of that object fails for some reason. 
There’s no way for -decodeObjectForKey: to signal an error because it has no 
error: parameter. All it could do is return nil, which is indistinguishable 
from the case where there is no object with that key. Even if you did get an 
NSError, you don’t have a way to return it from -initWithCoder:.

Basically this would require a whole new API to encoding/decoding, where 
everything took an NSError** parameter.

Not to start another flamewar, but this is a great example of why Exceptions 
Are Good, since you don’t have to rip apart your API and add lots of extra 
parameters just to add error handling.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: A trap with full screen in Lion

[Lee Ann Rucker]

On Jul 29, 2011, at 10:14 AM, Kyle Sluder wrote:

> On Fri, Jul 29, 2011 at 9:56 AM, vincent habchi  wrote:
>> The toolbar is supposed to disappear in full screen mode, no?
> 
> No.
> 
> It hangs out at the top of the screen and slides down out of the way
> of the menu bar when you move your mouse up to the top edge.

That depends; you can have it autohide just like the menubar.

___

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

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

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

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

[Q] calling OpenMP functions in a thread function for NSThread?

[JongAm Park]

Hello,
 
I'm using a GraphicsMagick library in my project.
 
However, there I found a very interesting behavior.
If I create an instance of Magick::Image in a normal method, 
it works OK.
However, if it is implemented in a thread function, it crashes 
when it calls omp_get_max_threads().

I tried these :
 
   1. Declare a pointer to Magick::Image in a class definition 
  and created it dynamically using "new" when I needed it in a thread 
method.
  => When it is being created, it reaches 
 where omp_get_max_threads() is called, 
 and it crashes saying "EXC_BAD_ACCESS".

   2. Declare an instance of Magick::Image in a thread function/method
  => Same crash

   3. Declare the instance of Magick::Image as a global variable 
  and try to use it in a thread function.
  => It crashes when reading a file like image.read( file_name ). 
 Where it crashes is the same to the case 1.
 
So, I thought it could be due to stack size. So, I increased the stack size 
for the thread, but it did'nt solve the problem.
 
is there a problem in calling OpenMP functions in a thread function?
 
Thank you.
JongAm Park___

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

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

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

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

Re: [GM-help] [Q] calling OpenMP functions in a thread function for NSThread?

[JongAm Park]

On Jul 29, 2011, at 2:03 PM, Bob Friesenhahn wrote:

> On Fri, 29 Jul 2011, JongAm Park wrote:
>> 
>> is there a problem in calling OpenMP functions in a thread function?
> 
> Possibly there is, however, I recall that your main program uses Objective C. 
>  Perhaps the Objective C runtime does not properly initialize with OpenMP?
> 
> OpenMP does not provide any way to explicitly initialize it.
> 
> Bob


Thanks for your reply.

Right,there is no function like "InitializeOpenMP()", which should be called at 
the beginning.
I set the project to use OpenMP, and if it is just declared statically like :

Magick::Image myImage;

in a normal method, there is no problem.
Only when they are either created or accessed in a thread function, it causes 
the problem.

Apple's GCC has support for OpenMP and it can be turned on/off from a project 
setting, and I turned it on.
The last time I worked with OpenMP was about 3~5 years ago, and at that moment, 
there was no problem.

Let me do some more experiment.
Maybe current version of GCC/LLVM is broken.
( I tested with GCC, LLVM-GCC, LLVM already. )

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: A trap with full screen in Lion

[Corbin Dunn]

Please log this as a bug. Ideally, include steps to reproduce and/or a sample 
application.

thanks!

corbin

On Jul 28, 2011, at 7:38 PM, Gideon King wrote:

> I just came across a bit of an issue with the full screen mode in Lion: if 
> you have a view and use [[self window] windowController] to get at your 
> window controller, it will return nil in full screen mode. The window gets 
> swapped out with an NSToolbarFullScreenWindow, which doesn't have a window 
> controller set. I haven't checked but assume this will also apply to things 
> like delegates etc too. And if you were relying on something in a custom 
> NSWindow subclass, that would be gone...
> 
> I have found that [[NSApp mainWindow] windowController] returns the right 
> thing, which is sufficient for my needs at the moment, seeing as it's UI 
> level and working on the current document.
> 
> I don't know whether there are any other issues with the full window but I 
> thought it would be interesting to bring up this issue for discussion in case 
> there are further implications.
> 
> 
> Regards
> 
> Gideon
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com
> 
> This email sent to corb...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSView-based NSTableView: How to animate when using bindings?

[Corbin Dunn]

On Jul 29, 2011, at 10:07 AM, Daniel Vollmer wrote:

> Helloes,
> 
> I'm experimenting with migrating from my formerly NSCollectionView-based 
> drawing to using an NSView-based table-view (as the tableView is conceptually 
> closer to what I'm displaying 
> (http://www.maven.de/code/wowplot/example_chains.png).
> 
> The NSCollectionView had really nice animation behaviour for inserting and 
> removing items and well as changing the minimum item size (which I used to 
> force the collectionView to expand into its scrollView and thus "zoom" into 
> my content).
> I'm not sure how to replicated these animations in an NSTableView when 
> populating it with bindings, as I cannot call both [arrayController 
> insertObject:] as well as [tableView insertRowsAtIndexes:withAnimation:].
> 
> Is combining the animation properties of an NSView-based NSTableView possible 
> when using it via Cocoa bindings?

Unfortunately there is no automatic support for this yet.

You'd have to provide the content yourself for the table (instead of using the 
content binding, but you can still use bindings for the NSTableCellViews and 
subviews of them), and watch for array controller changes and then transform 
them into inserts/deletes/moves on the tableview.

-corbin

___

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

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

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

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

Re: What could cause a fast enumeration mutation error in updating tracking areas?

[Gideon King]

Thanks for the suggestion Raleigh, but no, there are no other threads involved 
in any of the tracking area code, and looking at the crash report in more 
detail, it shows that the array that is being mutated has 27 items in it - the 
views I create only have one or two tracking areas that I add. I do have quite 
a few tracking rects but can't find a place where I would have 27 of them on a 
view.

I went through all my code looking for where I was using tooltips, and I found 
one suspicious looking bit of code, where in certain circumstances my drawRect: 
could call a method which would lead to removeAllTooltips and 
addToolTipRect:owner:userData: to be called. Seeing as this looks like the most 
likely cause (assuming the implementation uses tracking areas behind the 
scenes), and it's probably not a good thing to be doing during drawRect, I'll 
shift the code to be called outside drawRect: and see if the error goes away.

There are a few other places where tooltip rects could be updated and there 
could be 27 of them, but although in some cases the initiating caller may have 
come from another thread, it always calls back to the main thread for this 
operation, so I'm pretty sure we're OK there.

I also thought that cursor rects may be using tracking areas behind the scenes, 
so checked them too, but they are all done through the resetCursorRects 
mechanism, so presumably that would only be called when it is safe to do so.

So maybe the drawRect: one was it - I guess I'll know in a few days when I roll 
it out to my testers and see if I get the error again.

Regards

Gideon


On 30/07/2011, at 2:14 AM, Raleigh Ledet wrote:

> Do you have another thread that is doing something with tracking areas?
> 
> -raleigh
> 
> On Jul 28, 2011, at 11:33 PM, Gideon King wrote:
> 
>> Hi, I have a problem where a few users of my program are getting the 
>> following exception:
>> 
>> 0 CoreFoundation 0x7fff862df7b4 __exceptionPreprocess + 180
>> 1 libobjc.A.dylib 0x7fff84b0ff03 objc_exception_throw + 45
>> 2 CoreFoundation 0x7fff863375bf __NSFastEnumerationMutationHandler + 303
>> 3 AppKit 0x7fff83ec8660 -[NSView trackingAreas] + 271
>> 4 AppKit 0x7fff83f1d025 -[NSView(NSInternal) _updateTrackingAreas] + 249
>> 
>> 
>> But all the tracking areas I am adding are done in the initialization of the 
>> views or awakeFromNib, and not updated after that. I do use tracking rects 
>> and tooltip rects, and wonder whether they use tracking areas behind the 
>> scenes, and whether there are specific places in the code I need to avoid 
>> changing them. 
>> 
>> I haven't been able to reproduce the problem here, so can't catch it in the 
>> act so far.
>> 
>> Any suggestions as to what to look for?
>> 
>> Thanks
>> 
>> Gideon
>> 

___

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

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

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

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

toolbars & toolbar items in lion

[ronald b. kopelman]

NSToolbarSeparatorItem & NSToolbarCustomizeToolbarItem seem broken in 
xcode 4.1. I used to be able to add these without a problem previously  but now 
I get errors saying: "The toolbar item with object ID 654 was not in the 
allowed items list of the toolbar with object ID 651. It has been re-added to 
the allowed items list. The toolbar item with object ID 658 was not in the 
allowed items list of the toolbar with object ID 651. It has been re-added to 
the allowed items list." If it is re-added, why doesn't it work? Do I have to 
now add these in code? I have tried to search the literature to no avail. What 
am I missing?

ronald b. kopelman___

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

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

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

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[wadeslists]

> The fact that these methods throw exceptions if their input data cannot be 
> processed is very uncharacteristic of the Cocoa frameworks.

Now it is.  Back when NSCoding et al were written, possibly not.  Opinions on 
the use of exceptions vs other methods have waxed and waned over the years.  
Only recently has there been a comparatively strong push towards NSError.

There are many APIs which are transitioning to NSError.  NSCoding and friends 
may also transition in time (or be replaced entirely...).

> When invoking -archivedDataWithRootObject: on, say, dictionary, finding an 
> un-encodeable object buried somewhere in the dictionary would seem to be 
> quite common.  Similarly, when invoking -unarchiveObjectWithFile:, no 
> programmer can guarantee what may be found on the filesystem.

And this is one of several concerns with the NSCoding system.  It may be that 
the reason these classes haven't been updated is because there's consternation 
over the value of such an update.  Some people consider NSCoding intractably 
insecure and ergo unsuitable for use in pretty much anything.  Others take 
issue with it for varied other reasons.  I personally like it, but it's not 
flawless.

I wouldn't stress too much over it, in any case.  Sooner or later a change will 
occur.  'til then, follow the best practices to date.
___

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

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

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

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Kyle Sluder]

On Fri, Jul 29, 2011 at 3:54 PM,   wrote:
> And this is one of several concerns with the NSCoding system.  It may be that 
> the reason these classes haven't been updated is because there's 
> consternation over the value of such an update.  Some people consider 
> NSCoding intractably insecure and ergo unsuitable for use in pretty much 
> anything.  Others take issue with it for varied other reasons.  I personally 
> like it, but it's not flawless.

It's kind of cyclical. I treat anything loaded via NSCoding as code,
not data, because a) it's a frozen object graph, which means it is
tightly coupled to the implementation that was used to write the data,
and b) because of design decisions that make it fragile, like the one
Jerry has pointed out.

That motivates the designers of NSCoding to avoid making it more
general purpose, which perpetuates the cycle.

FWIW, NSCoding needs to be fast. It's used for unarchiving nibs. I
think its current role as a "code-loader" rather than a "data-loader"
is appropriate. There are better ways to persist data, such as
property lists or XML formats, that avoid common maintenance and
interoperability shortfalls.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: toolbars & toolbar items in lion

[Kyle Sluder]

On Fri, Jul 29, 2011 at 3:50 PM, ronald b. kopelman
 wrote:
>        NSToolbarSeparatorItem & NSToolbarCustomizeToolbarItem seem broken in 
> xcode 4.1.

These items are no longer supported in Lion.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: A trap with full screen in Lion

[Martin Wierschin]

> I just came across a bit of an issue with the full screen mode in Lion: if 
> you have a view and use [[self window] windowController] to get at your 
> window controller, it will return nil in full screen mode. The window gets 
> swapped out with an NSToolbarFullScreenWindow, which doesn't have a window 
> controller set.

Thanks for letting us know about this potential issue.

> I have found that [[NSApp mainWindow] windowController] returns the right 
> thing, which is sufficient for my needs

It looks like you can also get to the proper window controller via: 
[[[toolbarItemView window] parentWindow] windowController], which seems like a 
safer solution.

Best,
~Martin

___

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

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

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

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Rainer Brockerhoff]

On 29/07/2011, at 20:47, cocoa-dev-requ...@lists.apple.com wrote:
> From: Jens Alfke 
> Date: 29 de julho de 2011 17:15:19 BRT
> 
> On Jul 29, 2011, at 11:12 AM, Jerry Krinock wrote:
> 
>> When invoking -archivedDataWithRootObject: on, say, dictionary, finding an 
>> un-encodeable object buried somewhere in the dictionary would seem to be 
>> quite common.
> 
> This is a case of passing invalid data, so throwing an exception is 
> appropriate. It’s implicit that when you archive an object graph, all the 
> objects in it must be archivable.
> ...
> Not to start another flamewar, but this is a great example of why Exceptions 
> Are Good, since you don’t have to rip apart your API and add lots of extra 
> parameters just to add error handling.

Looking back at code I wrote years ago, I see that I usually did things like
@try {
someObject = [NSKeyedUnarchiver 
unarchiveObjectWithData:someData];
} @catch (id exception) {
someObject = nil;   // or some other reasonable default 
state
// mark someData as being corrupted to avoid its reuse
}
and this works well in my (admittedly not overly thorough) testing. I do the 
same when reading in nib files, image resources, etc..

However, I've also seen cautions that after throwing _any_ exception whatsoever 
we should terminate the application as soon as possible.

Granted that NSKeyedUnarchiver might have left some memory leaks or partially 
uninitialized objects somewhere, but unarchiving an invalid object should 
happen rarely if at all... and ordinarily my own code should never get pointers 
to such objects, anyway.

While personally I never had any problems with that try/catch block, I'd be 
interested in other opinions and experiences. 
--
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
Weblog: http://www.brockerhoff.net/blog

___

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

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

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

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

Re: A trap with full screen in Lion

[Gideon King]

Thanks for that suggestion Martin - I hadn't thought of looking at parent 
window. I kind of think that is an implementation detail behind the scenes that 
we shouldn't have to worry about in our code, so will file a bug report about 
it as Corbin suggested, and hopefully it will either be made to return the same 
window controller as if the window hadn't been swapped out from under you, or 
the documentation changed to make it very clear of the existence of this issue 
(to me, the former solution would seem by far the best one).

Regards

Gideon


On 30/07/2011, at 9:44 AM, Martin Wierschin wrote:

>> I just came across a bit of an issue with the full screen mode in Lion: if 
>> you have a view and use [[self window] windowController] to get at your 
>> window controller, it will return nil in full screen mode. The window gets 
>> swapped out with an NSToolbarFullScreenWindow, which doesn't have a window 
>> controller set.
> 
> Thanks for letting us know about this potential issue.
> 
>> I have found that [[NSApp mainWindow] windowController] returns the right 
>> thing, which is sufficient for my needs
> 
> It looks like you can also get to the proper window controller via: 
> [[[toolbarItemView window] parentWindow] windowController], which seems like 
> a safer solution.
> 
> Best,
> ~Martin
> 

___

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

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

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

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[wadeslists]

> Looking back at code I wrote years ago, I see that I usually did things like
>@try {
>someObject = [NSKeyedUnarchiver unarchiveObjectWithData:someData];
>} @catch (id exception) {
>someObject = nil;// or some other reasonable default state
>// mark someData as being corrupted to avoid its reuse
>}
> and this works well in my (admittedly not overly thorough) testing. I do the 
> same when reading in nib files, image resources, etc..

Interestingly there are some exceptions that will not be caught by the above.  
I can't remember the details, though, as it was years ago when I was wrangling 
with them.  I never came up with a better approach, though, I remember that 
much.

> However, I've also seen cautions that after throwing _any_ exception 
> whatsoever we should terminate the application as soon as possible.

These days especially, exceptions in "Cocoa" are generally considered 
crash-worthy, yes.  In the sense that you shouldn't try to catch them 
unequivocally; only in specific cases where it's clearly reasonable and there's 
no alternative - the above being such a case.

> Granted that NSKeyedUnarchiver might have left some memory leaks or partially 
> uninitialized objects somewhere, but unarchiving an invalid object should 
> happen rarely if at all... and ordinarily my own code should never get 
> pointers to such objects, anyway.

Indeed there may be memory leaks, but that's a relatively benign side effect.  
The security issues I alluded to earlier are a much greater concern in any 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Gwynne Raskind]

On Fri, Jul 29, 2011 at 21:48,   wrote:
>> Granted that NSKeyedUnarchiver might have left some memory leaks or 
>> partially uninitialized objects somewhere, but unarchiving an invalid object 
>> should happen rarely if at all... and ordinarily my own code should never 
>> get pointers to such objects, anyway.
> Indeed there may be memory leaks, but that's a relatively benign side effect. 
>  The security issues I alluded to earlier are a much greater concern in any 
> case.

Can you be more specific about those side effects? I'm rather curious,
and somewhat concerned; I've used NSCoding in the past for persisting
data.

-- Gwynne
___

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

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

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

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Kyle Sluder]

On Jul 29, 2011, at 7:07 PM, Gwynne Raskind  wrote:

> On Fri, Jul 29, 2011 at 21:48,   wrote:
>> 
>> Indeed there may be memory leaks, but that's a relatively benign side 
>> effect.  The security issues I alluded to earlier are a much greater concern 
>> in any case.
> 
> Can you be more specific about those side effects? I'm rather curious,
> and somewhat concerned; I've used NSCoding in the past for persisting
> data.

Any code that throws exceptions will probably leak a few objects, since 
according to the ARC design doc the ABI requires not draining autorelease pools 
while unwinding the stack.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Jerry Krinock]

On 2011 Jul 29, at 19:07, Gwynne Raskind wrote:

> On Fri, Jul 29, 2011 at 21:48,   wrote:
>>> Granted that NSKeyedUnarchiver might have left some memory leaks or 
>>> partially uninitialized objects somewhere, but unarchiving an invalid 
>>> object should happen rarely if at all... and ordinarily my own code should 
>>> never get pointers to such objects, anyway.
>> Indeed there may be memory leaks, but that's a relatively benign side 
>> effect.  The security issues I alluded to earlier are a much greater concern 
>> in any case.
> 
> Can you be more specific about those side effects?

Well, for perfectionists, another side effect is that an exception will often 
log a turd to the system console.

I wrote some code a couple years ago to archive NSError objects, for later 
display by another process.  Formally, NSError conforms to NSCoding.  But in 
practice, it may contain unencodable objects it its userInfo, and if userInfo 
includes an underlying error created by someone else, all bets are off.

To work around this, I traverse the error's -userInfo, making a copy and 
checking each leaf for encodability with a @try{} around 
-archivedDataWithRootObject:.  If a leaf is not encodable, I replace it in the 
copy with its -description.  Then I create a new error using the encodable copy 
of userInfo and encode that.

If I @catch an error, besides using -description, I also log a message to 
console saying "Please ignore the above exception…".  Pretty bad.

On 2011 Jul 29, at 13:15, Jens Alfke wrote:

> Basically this would require a whole new API to encoding/decoding, where 
> everything took an NSError** parameter.  …  Exceptions Are Good, since you 
> don’t have to rip apart your API and add lots of extra parameters just to add 
> error handling.

Yes, I've been there and done that.  It's certainly within Apple's 
capabilities.  However, understanding the reasons given in this discussion for 
not wanting to mess with NSKeyedArchiver and NSKeyedUnarchiver, or provide new 
classes, I think these methods would make me happy:

+[NSKeyedArchiver isEncodeable:(id)object]
+[NSKeyedUnarchiver isAValidArchive:(NSData*)data]

___

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

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

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

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

Telling Auto Save, "No, I'm busy now"

[Jerry Krinock]

With Auto Save enabled in a document, I find that Lion sometimes wants to break 
into a sequence of operations to do an Auto Save.  I haven't been able to find 
any recommendation of how to tell Auto Save "No, I'm busy now".  I just figured 
out how to do it by overriding saveToURL.

It seems to work.  I'd appreciate any criticisms:

- (void)saveToURL:(NSURL *)url
   ofType:(NSString *)typeName
 forSaveOperation:(NSSaveOperationType)saveOperation
completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
if (saveOperation == NSAutosaveInPlaceOperation) {
if ([[[NSOperationQueue mainQueue] operations] count] != 0) {
// "No, I'm busy now"

// If you don't do this, it hangs forever…
completionHandler(nil) ;

return ;
}
}

// Optional…
[self prepareForSaveOperation:saveOperation] ;

[super saveToURL:url
  ofType:typeName
forSaveOperation:saveOperation
   completionHandler:completionHandler] ;
}

___

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

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

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

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

Change in animation?

[David Rowland]

I have a routine that presents and then fades a label and a button,

- (void)fadeView:(UIView *)theView {
  theView.alpha = 1.0;
  infoButton.hidden = FALSE;
  [UIView animateWithDuration:2.5
   animations:^{theView.alpha = 0.0;}
   completion:^(BOOL finished){infoButton.hidden = TRUE;}
   ];
}

I changed to Lion and Xcode 4.1 and the behavior has changed. The fade occurs 
as it should, but while it's in action my touch controls are unresponsive. 
Formerly, they worked during the fade. Anyone else noticed something like this?

thanks,

David

___

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

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

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

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

ANN: HBCollections Blocks Categories

[Heath Borders]

Objective-C categories for functional data structure traversal with
blocks. The interface was inspired by Javascript Array Iteration
Methods. The implementation was inspired by Mike Ash's Implementating
Fast Enumeration Friday Q&A.

https://github.com/hborders/HBCollections

I encourage any feedback about ways to make this more efficient or any
other convenience APIs or basic functional APIs I could add.

Thanks!

-Heath Borders
heath.bord...@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com
___

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

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

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

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

Re: Change in animation?

[Roland King]

You asked something similar back in March

http://www.cocoabuilder.com/archive/cocoa/300383-iphone-animation-puzzle.html

I think the answer is still UIViewAnimationOptionAllowUserInteraction. Don't 
know why changing to Lion would have made a difference however as I think that 
option has been off by default in all versions of iOS 4.x, so it should never 
have worked. 

On Jul 30, 2011, at 12:44 PM, David Rowland wrote:

> I have a routine that presents and then fades a label and a button,
> 
> - (void)fadeView:(UIView *)theView {
>  theView.alpha = 1.0;
>  infoButton.hidden = FALSE;
>  [UIView animateWithDuration:2.5
>   animations:^{theView.alpha = 0.0;}
>   completion:^(BOOL finished){infoButton.hidden = TRUE;}
>   ];
> }
> 
> I changed to Lion and Xcode 4.1 and the behavior has changed. The fade occurs 
> as it should, but while it's in action my touch controls are unresponsive. 
> Formerly, they worked during the fade. Anyone else noticed something like 
> this?
> 
> thanks,
> 
> David
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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

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

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

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

Re: Fastest high-quality thumbnail display

[Scott Anguish]

If you want to display many thumbnails (or images in general) why not use the 
ImageKit?

It’s what it was designed for. Check out IK* files.

“The IKImageBrowserView class is a view for displaying and browsing a large 
amount of images and movies efficiently.”


On Jul 25, 2011, at 3:04 PM, James Merkel wrote:

> What is the fastest way to generate and display a thumbnail from a digital 
> camera file?
> In the past I used NSImage -- however the quality (with JPEG files) leaves 
> something to be desired. Now I am using CIImage with Lanczos scale transform 
> -- quality is very good but it is slow (particularly with raw files).
> 
> Should I be using the thumbnail capability of Image I/O? Will it have as good 
> a  quality as CIImage, but be faster?
> 
> I am comparing the speed of my app (running in Xcode) with the speed of 
> Preview. Preview is much faster ( 2x or 3X). I wonder what they are doing.
> 
> Of course the fastest way to display a thumbnail is to use the thumbnail in 
> the file (assuming there is one). But that's the problem, there may not be a 
> thumbnail in the file, in which case you need to create one yourself.
> 
> Thanks for any help,
> 
> Jim Merkel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
> 
> This email sent to sc...@cocoadoc.com

___

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

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

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

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