swift - making array of subclass of class also conforming to protocol

[Roland King]

I have a protocol I want some of my UIView subclasses to conform to so they can 
be controlled by a specific master object. So they are UIVIews (class) and they 
are also MasterControllable (protocol)

easy to make those UIView subclasses

public class MyVIew1 : UIView, MasterControllable {}
public class MyView2 : UIView, MasterControllable {}

etc

what I wanted in the master was an array of them, an array of UIViews which are 
also MasterControllable, but I can’t think of a way to specify that

private var myViews : Array  // nope
private var myViews : Array// nope

I can specify an array of something conforming to a protocol, or more than one 
protocol, or of a subclass of a given class, but not it seems of a subclass of 
a given class which also conforms to a given protocol. 

Yes I could write a generic UIView subclass which conforms to the 
MasterControllable protocol and stub out all the protocol methods and then 
write my UIView subclasses as subclasses of that, then use an array of that 
generic class, but that seems a very old scruffy way of doing it. 

I tried thinking about protocol extensions but didn’t get very far with that 
either. 

Did I miss something or has my quest for type perfection led me down another 
blind alley? 





___

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: FSIsAliasFile deprecated - typeOfFile is slow

[Leonardo]

Thanks, I will check that.


Regards
-- Leonardo


> Da: Sean McBride 
> Organizzazione: Rogue Research Inc.
> Data: Fri, 27 Nov 2015 17:07:33 -0500
> A: Leonardo , 
> Oggetto: Re: FSIsAliasFile deprecated - typeOfFile is slow
> 
> On Fri, 27 Nov 2015 23:00:16 +0100, Leonardo said:
> 
>> The problem is that the IsAliasNew method is 3.7 times slower than the
>> IsAliasOld method. Do you know a way to accomplish that with a faster
>> method?
> 
> Maybe try NSURL's getResourceValue:forKey:error: with NSURLIsAliasFileKey.
> 
> 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: FSIsAliasFile deprecated - typeOfFile is slow

[Leonardo]

Hi Gary,
Thank you for your low level fine solution. Anyway, I'm afraid that Apple
changes the alias-rule and this method will not work longer. Do you have a
solution at a upper level? Or may I be 100% sure that Apple will never
change this rule? 

Regards
-- Leonardo


> Da: "Gary L. Wade" 
> Data: Fri, 27 Nov 2015 16:48:43 -0800
> A: Leonardo 
> Cc: 
> Oggetto: Re: FSIsAliasFile deprecated - typeOfFile is slow
> 
> Although I have experience with your performance hit, one solution I would
> probably try when it becomes important again for me would be to do this:
> 
> 1. Using the BSD layer of APIs, see if the file (alias files are regular files
> from a statfs call, even folder aliases) has an extended attribute named
> "com.apple.FinderInfo". If it does not, it is not an alias file.
> 2. If the extended attribute does exist and is of length 32 bytes (or more
> although doubtful this would ever change), you might have an alias file. If
> less, just say no assuming corruption.
> 3. Get the bytes of the extended attribute and examine the byte at index 8
> (bytes[8]) to see if its high bit is set (bytes[8] | 0x80). If so, you have an
> alias; if not, you don't.
> 4. Add this logic in an appropriate category method (to keep this Cocoa).
> 
> For reference, look up ATTR_CMN_FNDRINFO, xattr, Finder.h. Note this extended
> attribute has its integers in big-endian format. You might also look at the
> fileType parameter of the CoreServices FileInfo that maps the first 16 bytes,
> but that requires more checking.
> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
>> On Nov 27, 2015, at 2:00 PM, Leonardo  wrote:
>> 
>> Hi,
>> I actually detect whether a file is an alias this way:
>> I use a NSString category where self is the filePath.
>> 
>> - (BOOL)IsAliasOld
>> {
>>FSRefsourceRef;
>> 
>>OSErrerr = [self GetFSRef:];
>>if(err) return NO;
>> 
>>BooleanisFSDirectory, aliasFileFlag;
>> 
>>err = FSIsAliasFile(, , );
>>if(err) return NO;
>>else return aliasFileFlag;
>> }
>> 
>> - (OSErr)GetFSRef:(FSRef*)sourceRef
>> {
>>const char *cSrcPath = [[NSFileManager defaultManager]
>> fileSystemRepresentationWithPath:self];
>>if(cSrcPath == 0 || *cSrcPath == _NUL) return -1;
>> 
>>OSErr err = FSPathMakeRefWithOptions((UInt8*)cSrcPath,
>> kFSPathMakeRefDoNotFollowLeafSymlink, sourceRef, NULL);
>>return err;
>> }
>> 
>> 
>> Since FSIsAliasFile is deprecated (I compile for 10.9) I would now use
>> 
>> - (BOOL)IsAliasNew
>> {
>>NSString*type = [[NSWorkspace sharedWorkspace] typeOfFile:self
>> error:nil];
>>return [type isEqualToString:@"com.apple.alias-file"];
>> }
>> 
>> The problem is that the IsAliasNew method is 3.7 times slower than the
>> IsAliasOld method. Do you know a way to accomplish that with a faster
>> method?
>> 


___

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: swift - making array of subclass of class also conforming to protocol

[Quincey Morris]

On Nov 28, 2015, at 03:51 , Roland King  wrote:
> 
> private var myViews : Array
> // nope
> private var myViews : Array  // nope

The problem is that you’re defining a variable. It can’t be generic — that 
would imply a different variable for each specialization. It can’t be 
UIView+MasterControllable (in some syntax), because no such *single* type 
exists. You could do something like this (which compiles in a playground):

> protocol MasterControllable
> {
>   func implementMe ()
>   var view: UIView { get }
> }
> 
> extension MasterControllable
> {
>   var view: UIView { return self as! UIView }
> }
> 
> public class MyView1 : UIView, MasterControllable
> {
>   func implementMe () {}
> }
> 
> public class MyView2 : UIView, MasterControllable
> {
>   func implementMe () {}
> }
> 
> private var myViews : [MasterControllable] = [MyView1 (frame: .zero), MyView2 
> (frame: .zero)]

That means you’d use 'myViews [i]’ to get to the MasterControllable methods and 
‘myViews [i].view’ to get to the view methods.

What you’re trying to do sounds reasonable, though. If there was syntax like 
‘class ’ to go along with ‘protocol ’, then you could declare an 'Array>’. However, I don’t know exactly what kind of type this 
would be — not exactly a class *or* a protocol.

Declaring a parent class that’s a UIView subclass and implements the protocol 
as placeholder methods isn’t a stupid idea. (Or, better still, implements them 
as defaults in a protocol extension.) It’s just grunt work like we’ve been 
doing for years.

You should ask this question in the Swift developer forum area. There are 
smarter people there who love solving this kind of thing.

___

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: FSIsAliasFile deprecated - typeOfFile is slow

[Charles Srstka]

> On Nov 28, 2015, at 9:59 AM, Leonardo  wrote:
> 
> Hi Gary,
> Thank you for your low level fine solution. Anyway, I'm afraid that Apple
> changes the alias-rule and this method will not work longer. Do you have a
> solution at a upper level? Or may I be 100% sure that Apple will never
> change this rule? 
> 
> Regards
> — Leonardo

The safe, upper-level method is to use -[NSURL getResourceValue:forKey:error:] 
with NSURLIsAliasFileKey.

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

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

Re: FSIsAliasFile deprecated - typeOfFile is slow

[Charles Srstka]

> On Nov 28, 2015, at 11:26 AM, Gary L. Wade  
> wrote:
> 
> Extended attributes aren't going away, and current alias files aren't going 
> away; those exist on the latest OS. Try this and getResourceValue: to see if 
> there's any significant difference, and if you eventually do need the alias 
> data you might also try the bookmark API on the file (check to be sure nil is 
> returned for a non-alias), especially when you scale up to a large file set, 
> and if my suggested wrapper around the BSD layer is fastest, write a 
> http://bugreport.apple.com asking Apple to add it as a blessed API based on 
> performance reasons and your need (besides the method result of BOOL, it 
> should also return an NSError in case the file doesn't exist). After all, 
> what is Cocoa but wrappers around lower levels? Someone eventually "gets 
> their hands dirty."

While extended attributes aren’t going away, it’s conceivable that the *format* 
could change. For example, if Apple ever moves off HFS+ to a file system that 
supports aliases natively, the kludge in the com.apple.FinderInfo xattr would 
probably not be needed anymore (unless of course they left it there for 
backward compatibility purposes).

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

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

Re: FSIsAliasFile deprecated - typeOfFile is slow

[Gary L. Wade]

Extended attributes aren't going away, and current alias files aren't going 
away; those exist on the latest OS. Try this and getResourceValue: to see if 
there's any significant difference, and if you eventually do need the alias 
data you might also try the bookmark API on the file (check to be sure nil is 
returned for a non-alias), especially when you scale up to a large file set, 
and if my suggested wrapper around the BSD layer is fastest, write a 
http://bugreport.apple.com asking Apple to add it as a blessed API based on 
performance reasons and your need (besides the method result of BOOL, it should 
also return an NSError in case the file doesn't exist). After all, what is 
Cocoa but wrappers around lower levels? Someone eventually "gets their hands 
dirty."

If I need to revisit the app that needs such a solution, I'll also report it, 
and maybe it'll make it into OS X 10.12. Some things do get added this way.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Nov 28, 2015, at 7:59 AM, Leonardo  wrote:
> 
> Hi Gary,
> Thank you for your low level fine solution. Anyway, I'm afraid that Apple
> changes the alias-rule and this method will not work longer. Do you have a
> solution at a upper level? Or may I be 100% sure that Apple will never
> change this rule? 
> 
> Regards
> -- Leonardo
> 
> 
>> Da: "Gary L. Wade" 
>> Data: Fri, 27 Nov 2015 16:48:43 -0800
>> A: Leonardo 
>> Cc: 
>> Oggetto: Re: FSIsAliasFile deprecated - typeOfFile is slow
>> 
>> Although I have experience with your performance hit, one solution I would
>> probably try when it becomes important again for me would be to do this:
>> 
>> 1. Using the BSD layer of APIs, see if the file (alias files are regular 
>> files
>> from a statfs call, even folder aliases) has an extended attribute named
>> "com.apple.FinderInfo". If it does not, it is not an alias file.
>> 2. If the extended attribute does exist and is of length 32 bytes (or more
>> although doubtful this would ever change), you might have an alias file. If
>> less, just say no assuming corruption.
>> 3. Get the bytes of the extended attribute and examine the byte at index 8
>> (bytes[8]) to see if its high bit is set (bytes[8] | 0x80). If so, you have 
>> an
>> alias; if not, you don't.
>> 4. Add this logic in an appropriate category method (to keep this Cocoa).
>> 
>> For reference, look up ATTR_CMN_FNDRINFO, xattr, Finder.h. Note this extended
>> attribute has its integers in big-endian format. You might also look at the
>> fileType parameter of the CoreServices FileInfo that maps the first 16 bytes,
>> but that requires more checking.
>> --
>> Gary L. Wade (Sent from my iPhone)
>> http://www.garywade.com/
>> 
>>> On Nov 27, 2015, at 2:00 PM, Leonardo  wrote:
>>> 
>>> Hi,
>>> I actually detect whether a file is an alias this way:
>>> I use a NSString category where self is the filePath.
>>> 
>>> - (BOOL)IsAliasOld
>>> {
>>> FSRefsourceRef;
>>> 
>>> OSErrerr = [self GetFSRef:];
>>> if(err) return NO;
>>> 
>>> BooleanisFSDirectory, aliasFileFlag;
>>> 
>>> err = FSIsAliasFile(, , );
>>> if(err) return NO;
>>> else return aliasFileFlag;
>>> }
>>> 
>>> - (OSErr)GetFSRef:(FSRef*)sourceRef
>>> {
>>> const char *cSrcPath = [[NSFileManager defaultManager]
>>> fileSystemRepresentationWithPath:self];
>>> if(cSrcPath == 0 || *cSrcPath == _NUL) return -1;
>>> 
>>> OSErr err = FSPathMakeRefWithOptions((UInt8*)cSrcPath,
>>> kFSPathMakeRefDoNotFollowLeafSymlink, sourceRef, NULL);
>>> return err;
>>> }
>>> 
>>> 
>>> Since FSIsAliasFile is deprecated (I compile for 10.9) I would now use
>>> 
>>> - (BOOL)IsAliasNew
>>> {
>>> NSString*type = [[NSWorkspace sharedWorkspace] typeOfFile:self
>>> error:nil];
>>> return [type isEqualToString:@"com.apple.alias-file"];
>>> }
>>> 
>>> The problem is that the IsAliasNew method is 3.7 times slower than the
>>> IsAliasOld method. Do you know a way to accomplish that with a faster
>>> method?
> 
> 

___

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: FSIsAliasFile deprecated - typeOfFile is slow

[Gary L. Wade]

Hopefully by that time those software developers in Apple who misquote Donald 
Knuth will gain enough experience to realize there are good reasons even small 
APIs should be efficient.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

On Nov 28, 2015, at 10:38 AM, Charles Srstka  wrote:

>> On Nov 28, 2015, at 11:26 AM, Gary L. Wade  
>> wrote:
>> 
>> Extended attributes aren't going away, and current alias files aren't going 
>> away; those exist on the latest OS. Try this and getResourceValue: to see if 
>> there's any significant difference, and if you eventually do need the alias 
>> data you might also try the bookmark API on the file (check to be sure nil 
>> is returned for a non-alias), especially when you scale up to a large file 
>> set, and if my suggested wrapper around the BSD layer is fastest, write a 
>> http://bugreport.apple.com asking Apple to add it as a blessed API based on 
>> performance reasons and your need (besides the method result of BOOL, it 
>> should also return an NSError in case the file doesn't exist). After all, 
>> what is Cocoa but wrappers around lower levels? Someone eventually "gets 
>> their hands dirty."
> 
> While extended attributes aren’t going away, it’s conceivable that the 
> *format* could change. For example, if Apple ever moves off HFS+ to a file 
> system that supports aliases natively, the kludge in the com.apple.FinderInfo 
> xattr would probably not be needed anymore (unless of course they left it 
> there for backward compatibility purposes).
> 
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Bunch of CoreData based NSDocument questions.

[Gary L. Wade]

I don't remember the details, but I seem to recall you having to override some 
methods in NSDocument (saving, closing, etc.) and possibly NSApplication 
terminate to get the behavior it sounds like you require. The app I worked on 
wanted to make sure the user had an option to submit an action to an outside 
service even though the data was saved.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/

> On Nov 26, 2015, at 10:41 PM, Motti Shneor  wrote:
> 
> He hits "Quit" by mistake, and the whole thing pops and disappears. He'll 
> have to open the application and re-do half an hour's work to bring his setup 
> to the previous state. Nothing was yet saved - because most of this work is 
> outside the computer. Only the user can align these two simultaneous flows of 
> action.

___

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: swift - making array of subclass of class also conforming to protocol

[Quincey Morris]

On Nov 28, 2015, at 10:32 , Quincey Morris 
 wrote:
> 
> It can’t be UIView+MasterControllable (in some syntax), because no such 
> *single* type exists. 

One other dopey alternative occurred to me. You could add all the methods from 
UIView, or just those your app actually uses, directly to the 
MasterControllable protocol. Your conforming subclasses will of course inherit 
conformity to these requirements from the real UIView, so there’s no extra work 
or runtime overhead. If the UIView API ever changes, then you’ll conformance 
errors in your subclasses the next time you compile.

There are probably hundreds of methods in UIView, but chances are you’ll only 
need a couple of dozen to be exposed in the enlarged MasterController.

FWIW

___

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: swift - making array of subclass of class also conforming to protocol

[Roland King]

> On 29 Nov 2015, at 09:26, Quincey Morris 
>  wrote:
> 
> On Nov 28, 2015, at 10:32 , Quincey Morris 
>  > wrote:
>> 
>> It can’t be UIView+MasterControllable (in some syntax), because no such 
>> *single* type exists. 
> 
> One other dopey alternative occurred to me. You could add all the methods 
> from UIView, or just those your app actually uses, directly to the 
> MasterControllable protocol. Your conforming subclasses will of course 
> inherit conformity to these requirements from the real UIView, so there’s no 
> extra work or runtime overhead. If the UIView API ever changes, then you’ll 
> conformance errors in your subclasses the next time you compile.
> 
> There are probably hundreds of methods in UIView, but chances are you’ll only 
> need a couple of dozen to be exposed in the enlarged MasterController.
> 
> FWIW
> 

Thanks - I was just writing a reply to your last message which said I’d tried 
containment but it made the rest of the code clunky and so, realising I only 
need about 4-5 methods from UIView I made a UIViewProtocol protocol with those 
methods in and ‘extended’ UIView to conform to it. At the same time I did add 
another read-only property into that protocol which returns a UIView, a real 
one, which the extension trivially implements with

var view : UIView { return self }

And then I can make an array> and I 
have pretty close to what I want. 

When I’m calling methods *on* the view, they’re in the protocol so I can call 
them directly, if I need to use the object *as* a UIView, to send it to 
something else, like addSubview(), then I have to stick the ‘.view’ on the end, 
which isn’t a terrible hardship. So it looks a bit like containment in some 
cases, and like extension in most of them, not a horrid hybrid. 

Were UIView written as a protocol and a single implementing class, this would 
be pretty easy, I wonder as Swift develops whether more of the library will be 
adjusted to be that way. Perhaps UIView would be the last thing to get there 
but you an see how having many classes as just implementing various Cocoa/UIKit 
protocols would be a useful recasting. 

That also possibly suggests an answer to your question in the previous mail, 
‘what would class mean’? How about, and I’m sure there 
are some big gaping holes in this, if a class counted as an object implementing 
a protocol of the same-named-type, so protocol would mean 
a protocol which has all the methods of UIView and all the methods of 
SomeProtocol and could be used wherever a UIView class/subclass was used. That 
would be an interesting trick for moving to protocol-based programming. 

Anyway this is rigorous enough for what I’m doing, I just wanted to avoid too 
many ‘as?’ constructs which to my mind give the code a bit of an odour. 
___

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: Bunch of CoreData based NSDocument questions.

[Quincey Morris]

On Nov 28, 2015, at 14:41 , Motti Shneor  wrote:
> 
> This I don’t get. If that’s not a close what is a ‘close'… the document 
> disappears, windows close and disappear

I’ll think about the other things you wrote, but I’ll answer this right now, 
since it’s an important conceptual part of the “modern” NSDocument behavior.

There are 3 different operations that are significant to the user:

1. Quit. This is intended to preserve all of the current state so that it can 
be restored on relaunch. The idea is that the user can quit without changing 
anything that’s going on, then re-launch and be exactly where he was. As a 
consequence, there’s no saving of documents, since that does change what’s 
going on. (For example, after you save, you can’t revert any more. Saving may 
have other side effects, too.) Also, the windows go away, because the app goes 
away.

2. Save. This is a user-initiated action that causes the on-disk document state 
to be updated, and you can no longer go back to the pre-save state (except via 
Versions, but that’s a different matter). Note that when autosavesInPlace==YES, 
an autosave is most definitely NOT a save from the UI point of view. It’s more 
like a forced write of memory to a swap file.

3. Close. This is a user-initiated action that says that the *user* doesn’t 
want the document window to be open any more. Since there is no state 
restoration after a user-initiated Close, there has to be a dialog to ask what 
to do with unsaved changes, and the options are to save or not save. What I 
previously called the “close machinery” are the pieces of behavior that 
implement this, and they provide intervention points for the developer, such as 
shouldClose…/willClose…/didClose… methods. None of this happens at Quit.

The virtue of this system is that a user can quit the app without having to 
decide whether to save. Because of autosaving, app crashing is nearly as safe, 
because it’s like a quit and relaunch, except if a final autosave wasn’t done 
before the crash the restored state will be about 20 seconds old.

That’s what I meant by saying that a Close implies a Save (or not, if the user 
chooses to not save), but a Quit does not imply a Close or a Save. A Quit is 
*intended* to leave all documents unsaved, though without losing the current 
unsaved state, if you implement restorability properly. This is simply the 
architecture of the modern document system. You may not agree with the design 
choices, but it’s not wrong that it’s designed according to these choices.

I do think that the current Quit behavior, where the documents/windows are 
discarded before you get a chance to refuse to terminate, is an out and out bug 
in ‘terminate:’. Documents should probably have their autosaves started before 
you’re notified, but there’s no real reason AFAICT why the document and windows 
can’t stay in place until after. Unfortunately, even if Apple accepts this is a 
bug, it’s unlikely to be repaired on any timeline that helps you get your app 
finished.

As a workaround, you could have your applicationShouldTerminate: method be 
aware that documents (might) have closed already. If you keep track of what 
document is currently using the microscope, then you could simply re-open the 
document on behalf of the user. Of course, as before, this means you have to 
move any non-saveable state out of the document into the application itself.

I also note that you haven’t talked about what happens when there’s more than 
one document open? Which one corresponds to the microscope state? If your 
answer is, say, that users only ever use one document at a time, I’d repeat the 
essence of what I said before — that this is a “design smell” that suggests the 
NSDocument metaphor is not serving you 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