Re: Optionality in a NSManagedObject sub-class

2017-02-10 Thread Daryle Walker 

> On Feb 10, 2017, at 3:02 AM, Daryle Walker  wrote:
> 
> It’s simple:
> 
> - I’m writing this framework for an app, both macOS, with Swift 3 and Xcode 8.
> - My protocol has two non-optional strings.
> - I unchecked “Optional” for those attributes when editing the model file.
> - I used “Manual/None” for generation, then used the menu command to create 
> the declaration and properties-extension files anyway.
> - The class uses “String?”, i.e. optionals, for my attributes.
> - This keeps the managed-object sub-class from matching the protocol when I 
> add it from another extension (in a new file).
> 
> The properties are mandatory. So is it OK to change the generated versions to 
> non-optionals? What’s the risk/trade-offs if I do so?

I gave up and used an adaptor:

> extension RawHeaderField {
> /// Adapter for core properties to conform to InternetMessageHeaderField, 
> since CoreData prefers to properties to be optionals.
> public class FieldAdapter: NSObject, InternetMessageHeaderMutableField {
> private var source: RawHeaderField
> public dynamic var name: String {
> get { return source.name ?? “" }
> set { source.name = newValue }
> }
> public dynamic var body: String {
> get { return source.body ?? “" }
> set { source.body = newValue }
> }
> 
> init(source: RawHeaderField) {
> self.source = source
> }
> }
> 
> /// A level of redirection since `RawHeaderField` can't directly conform 
> to `InternetMessageHeaderField`.
> public dynamic var field: FieldAdapter {
> return FieldAdapter(source: self)
> }
> }

Hmm, I had to add that since just taking out the “?” suffixes caused a weird 
link error. I removed them again to show all of you the error, but the 
framework compiled/linked successfully.

…

I commented out the “field” declaration to make sure that wasn’t “fixing” my 
original problem, but it still didn’t come back. There was some sort of link 
error over the (direct) “name” and “body” properties, and suggested using the 
“-v” on the linker. But I can’t reproduce it now. Maybe it was a first-time 
making the objects error.

…

Nope, running “Clean” and re-compiling/linking/testing didn’t bring the error 
back. I’ll respond if it happens later.

…

Oh, I forgot to copy the protocol declaration back to the extension on the 
first line. That brought the error back:

> Ld 
> /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Products/Debug/InternetMessages.framework/Versions/A/InternetMessages
>  normal x86_64
> cd /Users/daryle/Documents/Repositories/XNW/XNW
> export MACOSX_DEPLOYMENT_TARGET=10.12
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>  -arch x86_64 -dynamiclib -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>  
> -L/Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Products/Debug
>  
> -F/Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Products/Debug
>  -filelist 
> /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages.LinkFileList
>  -install_name @rpath/InternetMessages.framework/Versions/A/InternetMessages 
> -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath 
> -Xlinker @loader_path/Frameworks -mmacosx-version-min=10.12 -Xlinker 
> -object_path_lto -Xlinker 
> /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages_lto.o
>  -Xlinker -export_dynamic -Xlinker -no_deduplicate -fobjc-link-runtime 
> -fprofile-instr-generate 
> -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx
>  -Xlinker -add_ast_path -Xlinker 
> /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages.swiftmodule
>  -single_module -compatibility_version 1 -current_version 1 -Xlinker 
> -dependency_info -Xlinker 
> /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages_dependency_info.dat
>  -o 
>

Re: Intercept Save when closing NSDocument

2017-02-10 Thread Kevin Perry 
NSSavePanelDelegate is probably the approach you want to take, with 
-[NSDocument prepareSavePanel:] being the most convenient means of inserting 
your delegate.

> On Feb 10, 2017, at 9:41 AM, Quincey Morris 
>  wrote:
> 
> On Feb 10, 2017, at 08:12 , Trygve Inda  wrote:
>> 
>> I would like to disable the Save button
>> for a demo version of our app.
> 
> Have you looked at the NSSavePanelDelegate methods? One approach would be to 
> use panel:validateURL:error: to prevent the save proceeding. Another would be 
> to use (say) panelSelectionDidChange: to explicitly disable the Save button 
> (which has a documented view tag) if that works the the XPC environment of 
> the Save dialog.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
> 
> This email sent to kpe...@apple.com


___

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

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

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

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

Re: Intercept Save when closing NSDocument

2017-02-10 Thread Quincey Morris 
On Feb 10, 2017, at 08:12 , Trygve Inda  wrote:
> 
> I would like to disable the Save button
> for a demo version of our app.

Have you looked at the NSSavePanelDelegate methods? One approach would be to 
use panel:validateURL:error: to prevent the save proceeding. Another would be 
to use (say) panelSelectionDidChange: to explicitly disable the Save button 
(which has a documented view tag) if that works the the XPC environment of the 
Save dialog.

___

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: UI bindings

2017-02-10 Thread Keary Suska 

> On Feb 9, 2017, at 5:52 PM, Ariel Feinerman  wrote:
> 
> I have finished the core of my programme and now I am designing the UI. The
> issue is that it has several tabs and about a hundred fields. I wish to
> make a mechanism which can gather values and save them in the hierarchical
> structure of NSArrays and NSDictionaries which I can send to core library,
> save as plist or map into XML. And, of course, I should be able to restore
> UI from it .
> 
> I guess Cocoa Bindings can do all of that. However, I have never used it
> and do not know where to begin. Any examples and suggestions will be highly
> appreciated.

If you haven’t already, read the Key-Value Coding and Key-Value Observing 
guides. Make sure all of your model classes are compliant with both. Then read 
the Cocoa Bindings Programming Topics guide, which has links to all the other 
docs so you can start there if you prefer. Read through all the linked 
supported docs as well. That will be enough for most implementations. If or 
when you get into issues not addressed in those documents you will find most 
answers in the archives. Cocoa bindings have been around for a really long time 
and have changed very little since their inception so any (good) advice on the 
subject will still be relevant regardless of how old. And what is not addressed 
in the archives can be addressed here but please be specific and reference all 
of the involved objects, binding names and key paths.

Oh, and avoid storyboards at this stage as (IMHO) they are unintuitive and 
flout all other MVC documentation.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: Intercept Save when closing NSDocument

2017-02-10 Thread Trygve Inda 
On 2/10/17, 9:19 AM, "Keary Suska"
 wrote:

>
>> On Feb 10, 2017, at 9:12 AM, Trygve Inda 
>>wrote:
>> 
>> When I close an NSDocument, it puts up a sheet offering (Don¹t Save,
>> Cancel, Save).
>> 
>> Is there a way to intercept this? I would like to disable the Save
>>button
>> for a demo version of our app. I could mark the document as having no
>> changes, but then it would just close directly and not allow a cancel
>> operation.
>> 
>> I can easily disable the menu Save/Save As but clicking the Save button
>>in
>> the close-sheet window jumps right into the file writing methods in my
>> NSDocument subclass.
>> 
>> Thanks for any ideas.
>
>I would start by overriding -saveDocument: and -saveDocumentAs: in your
>NSDocument subclass with a breakpoint so I can see what is being done. I
>might also start by subclassing
>-runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:
>to see if that is the method used in these cases. Then there are also
>autosave issues if you intend to support autosave in your app...

Yup - I have overridden -saveDocument: and -saveDocumentAs:

They are called from the File-Save and File-Save As points, but not from
clicking Save in the “document is about to close” dialog. I am not
supporting Autosave as I am dealing with very large files.

Trygve





___

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

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

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

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

Re: Intercept Save when closing NSDocument

2017-02-10 Thread Jens Alfke 

> On Feb 10, 2017, at 9:19 AM, Keary Suska  wrote:
> 
> I would start by overriding -saveDocument: and -saveDocumentAs: in your 
> NSDocument subclass with a breakpoint so I can see what is being done.

Even easier: wait for the save dialog to appear, then hit the Pause button in 
the debugger and look at the backtrace to see the entire call chain. Look for 
any NSDocument method that you can override.

—Jens

___

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

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

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

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

Re: Intercept Save when closing NSDocument

2017-02-10 Thread Keary Suska 

> On Feb 10, 2017, at 9:12 AM, Trygve Inda  wrote:
> 
> When I close an NSDocument, it puts up a sheet offering (Don¹t Save,
> Cancel, Save).
> 
> Is there a way to intercept this? I would like to disable the Save button
> for a demo version of our app. I could mark the document as having no
> changes, but then it would just close directly and not allow a cancel
> operation.
> 
> I can easily disable the menu Save/Save As but clicking the Save button in
> the close-sheet window jumps right into the file writing methods in my
> NSDocument subclass.
> 
> Thanks for any ideas.

I would start by overriding -saveDocument: and -saveDocumentAs: in your 
NSDocument subclass with a breakpoint so I can see what is being done. I might 
also start by subclassing 
-runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo: to see 
if that is the method used in these cases. Then there are also autosave issues 
if you intend to support autosave in your app...

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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

Intercept Save when closing NSDocument

2017-02-10 Thread Trygve Inda 
When I close an NSDocument, it puts up a sheet offering (Don¹t Save,
Cancel, Save).

Is there a way to intercept this? I would like to disable the Save button
for a demo version of our app. I could mark the document as having no
changes, but then it would just close directly and not allow a cancel
operation.

I can easily disable the menu Save/Save As but clicking the Save button in
the close-sheet window jumps right into the file writing methods in my
NSDocument subclass.

Thanks for any ideas.

Trygve




___

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

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

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

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

Optionality in a NSManagedObject sub-class

2017-02-10 Thread Daryle Walker 
It’s simple:

- I’m writing this framework for an app, both macOS, with Swift 3 and Xcode 8.
- My protocol has two non-optional strings.
- I unchecked “Optional” for those attributes when editing the model file.
- I used “Manual/None” for generation, then used the menu command to create the 
declaration and properties-extension files anyway.
- The class uses “String?”, i.e. optionals, for my attributes.
- This keeps the managed-object sub-class from matching the protocol when I add 
it from another extension (in a new file).

The properties are mandatory. So is it OK to change the generated versions to 
non-optionals? What’s the risk/trade-offs if I do so?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

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

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

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

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