Date   

Re: Abstracting a group of commonly named Selectors

Alex Zavatone
 

Would it be possible to put them in an array or dictionary as NSStrings and use performSelector on one of them if it is present within the array or dict?

On Jul 20, 2020, at 12:11 PM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

I have a certain group of selectors that all follow a strict naming convention,

-(Status)parseXYZ
-(Status)parseRST

All have one line that does the same thing and return a scalar (enum) as a result.
Each method would do something XYZ or RST and return their status

There are about 200 of these… it’s quite annoying to maintain and look at this boiler plate interface. It should not be necessary, I hope.

I would like to abstract them using something like:
-doesNotRecognizeSelector:
or
-forwardInvocation:
or
By some other means, which I cannot conceive of…

The issue I don’t understand is, how would I return the scalar to the original caller once one of the methods has received the program flow. Neither of these methods return anything.

Is what I want to do possible?
If so, what should I be looking at?

Sandor


Abstracting a group of commonly named Selectors

Sandor Szatmari
 

I have a certain group of selectors that all follow a strict naming convention,

-(Status)parseXYZ
-(Status)parseRST

All have one line that does the same thing and return a scalar (enum) as a result.
Each method would do something XYZ or RST and return their status

There are about 200 of these… it’s quite annoying to maintain and look at this boiler plate interface. It should not be necessary, I hope.

I would like to abstract them using something like:
-doesNotRecognizeSelector:
or
-forwardInvocation:
or
By some other means, which I cannot conceive of…

The issue I don’t understand is, how would I return the scalar to the original caller once one of the methods has received the program flow. Neither of these methods return anything.

Is what I want to do possible?
If so, what should I be looking at?

Sandor


Re: UndoManager setActionNames

Graham Cox
 

The action name is part of the “view” layer in model-controller-view architecture. But most of the actual undoable ’stuff’ is in the model.

So I usually set the action name at the top level action method that responds to the original command, even if that burrows down and changes a bunch of stuff in the model. That works fine, because the Undo Manager itself keeps the same action name across undo/redo actions even if it doesn’t directly invoke the original action method for redo. This works fine as long as your model doesn’t also try messing with the action name - just keep that in the view layer.

—Graham

On 5 Jul 2020, at 5:07 pm, Arved von Brasch via Cocoa-dev <cocoa-dev@lists.apple.com> wrote:

Hi list,

Where’s the best place to intercept undo/redo actions to edit the action name (’setActionName()’) for the UndoManager in a CoreData application? In particular, when a particular entity’s attribute's change. Obviously, I want to do this so that when the user edits something, the menu name is more descriptive than just “Undo”/“Redo”.

Easiest, in terms of implementation, seems to be in the NSManagedObject subclass by means of an observer on the attribute. However, conceptually, it would make more sense to handle it in the NSArrayController or, maybe the NSTableView or other NSView object where the attribute is edited directly.

Just wondering where others have settled for best practice.

Kind regards,
Arved
_______________________________________________

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/graham.cox%40bigpond.com

This email sent to graham.cox@bigpond.com


Re: Redrawing a view during a dragging session [SOLVED]

Graham Cox
 

As usual, the answer was staring me in the face.

The old code was synchronous, the new is asynchronous.

I was restoring the view after the call to -dragImage… because that used to keep control until the drag finished. But the replacement returns immediately, so restoring the view just undoes the hiding step, and with it not hidden, the stack animation has no “gap” to work with.

A small re-arrangement of where the clean-up of the drag is done restores full working visuals (and my sanity!).

Sory for the noise - but if anyone else has a similar issue, this might be of some help.

—Graham

On 3 Jul 2020, at 4:11 pm, Graham Cox <graham@mapdiva.com> wrote:

Hi all,

I’m updating some legacy code that currently uses the ‘classic’ way to drag stuff, namely

[NSView dragImage:at:offset:event:pasteboard:source:slideBack:];

This code has been deprecated forever (10.7+ anyway), so it’s about time it was updated to the modern dragging session API. However, the old code still works perfectly and has served faithfully for years.

The dragging session is created OK, and the dragging image drags as a semi-transparent image, so the drag is taking place alright. I can also see that the dragging destination methods are called as they should be.

The problem is that the source view needs to update while the drag is going on. The view is actually a stack of subviews, and the thing being dragged is one of them, to re-arrange the order of the views. So the first thing is that the view being dragged is hidden. This opens up a gap in the stack. As the drag proceeds, the remaining views animate their position to open up a gap where the view can be dropped.

In the old code, works great.

In the new code, nothing I do allows the view’s visual appearance to be updated during the drag. The view being dragged doesn’t hide (its ‘hidden’ state becomes YES, but it still shows), and the animation doesn’t happen, though once again the code that handles that is being called as expected. That calls -setAnimatedFrame: to reposition the other views to make space, but though its being called with sensible values, nothing actually gets drawn or redrawn.

It’s as if the run loop is suspended during the dragging session, so window updates are not processed. I’m not sure what to check to verify that guess.

SUrely normal updates should be allowed during a drag? How can the old code (that freely handles updates) be replaced if the new one doesn’t work the same way?

Anyone run into this problem, or knows what I should do here?

—Graham







Redrawing a view during a dragging session

Graham Cox
 

Hi all,

I’m updating some legacy code that currently uses the ‘classic’ way to drag stuff, namely

[NSView dragImage:at:offset:event:pasteboard:source:slideBack:];

This code has been deprecated forever (10.7+ anyway), so it’s about time it was updated to the modern dragging session API. However, the old code still works perfectly and has served faithfully for years.

The dragging session is created OK, and the dragging image drags as a semi-transparent image, so the drag is taking place alright. I can also see that the dragging destination methods are called as they should be.

The problem is that the source view needs to update while the drag is going on. The view is actually a stack of subviews, and the thing being dragged is one of them, to re-arrange the order of the views. So the first thing is that the view being dragged is hidden. This opens up a gap in the stack. As the drag proceeds, the remaining views animate their position to open up a gap where the view can be dropped.

In the old code, works great.

In the new code, nothing I do allows the view’s visual appearance to be updated during the drag. The view being dragged doesn’t hide (its ‘hidden’ state becomes YES, but it still shows), and the animation doesn’t happen, though once again the code that handles that is being called as expected. That calls -setAnimatedFrame: to reposition the other views to make space, but though its being called with sensible values, nothing actually gets drawn or redrawn.

It’s as if the run loop is suspended during the dragging session, so window updates are not processed. I’m not sure what to check to verify that guess.

SUrely normal updates should be allowed during a drag? How can the old code (that freely handles updates) be replaced if the new one doesn’t work the same way?

Anyone run into this problem, or knows what I should do here?

—Graham


Re: Determining CGContext type at runtime

Graham Cox
 

Thanks — it is a bit kludgey, but might do in a pinch, as you say.

In some cases I can set a flag on my drawing to tell it that the context should be a PDF at that time, since I am responsible for setting up that context in the first place — but at other times (such as printing), I may not get the chance. But I will explore the issue further and see if anything else comes to mind.

cheers, Graham






On 21 Jun 2020, at 5:28 am, Steve Christensen via groups.io <punster@...> wrote:

I played around with it and found that bitmap (easy to create) and PDF contexts have the same CFTypeID so no help there, and that there doesn’t appear to be a public context [sub-]type property. One thing I noticed in  run logging was that the context type is available in the description string, so if you’d like a fragile solution then you might do something like this. I’m not advocating for it, but if in a weak moment desperation overwhelms you...

NSString* pdfDescription = [[NSString alloc] initWithFormat:@"%@", pdfContext];
NSString* bitmapDescription = [[NSString alloc] initWithFormat:@"%@", bitmapContext];

NSLog(@"pdf = %@, isPDF = %@", pdfDescription, [pdfDescription containsString:@"PDF"] ? @"YES" : @"NO");
NSLog(@"bitmap = %@, isPDF = %@", bitmapDescription, [bitmapDescription containsString:@"PDF"] ? @"YES" : @"NO");


pdf = <CGContext 0x600001ae0840> (kCGContextTypePDF), isPDF = YES

bitmap = <CGContext 0x600001ae0b40> (kCGContextTypeBitmap)
<<CGColorSpace 0x600000be0c60> (kCGColorSpaceDeviceRGB)>
width = 100, height = 100, bpc = 8, bpp = 32, row bytes = 416 
kCGImageAlphaPremultipliedFirst | 0 (default byte order) | kCGImagePixelFormatPacked (default) , isPDF = NO



On Jun 19, 2020, at 10:23 PM, Graham Cox <graham@...> wrote:

I need to determine whether I am drawing into a CGPDFContext or a different context at runtime.

In AppKit, I can use [NSGraphicsContext currentContextDrawingToScreen], but this is code that is passed a CGContextRef only, so that higher-level API isn’t appropriate. CGPDFContext doesn’t appear to have an associated CGPDFContextGetTypeID() function to compare with the result of CFGetTypeID(), so it’s unclear how I can do this.

The reason I need to so this is that objects I am drawing can have different states according to whether they are selected in the UI or not, but when capturing the drawing into a PDF, the selection state needs to be ignored, so the drawing code needs to be able to detect what context type is so that it can do this.

—Graham



Re: Determining CGContext type at runtime

Steve Christensen
 

I played around with it and found that bitmap (easy to create) and PDF contexts have the same CFTypeID so no help there, and that there doesn’t appear to be a public context [sub-]type property. One thing I noticed in  run logging was that the context type is available in the description string, so if you’d like a fragile solution then you might do something like this. I’m not advocating for it, but if in a weak moment desperation overwhelms you...

NSString* pdfDescription = [[NSString alloc] initWithFormat:@"%@", pdfContext];
NSString* bitmapDescription = [[NSString alloc] initWithFormat:@"%@", bitmapContext];

NSLog(@"pdf = %@, isPDF = %@", pdfDescription, [pdfDescription containsString:@"PDF"] ? @"YES" : @"NO");
NSLog(@"bitmap = %@, isPDF = %@", bitmapDescription, [bitmapDescription containsString:@"PDF"] ? @"YES" : @"NO");


pdf = <CGContext 0x600001ae0840> (kCGContextTypePDF), isPDF = YES

bitmap = <CGContext 0x600001ae0b40> (kCGContextTypeBitmap)
<<CGColorSpace 0x600000be0c60> (kCGColorSpaceDeviceRGB)>
width = 100, height = 100, bpc = 8, bpp = 32, row bytes = 416 
kCGImageAlphaPremultipliedFirst | 0 (default byte order) | kCGImagePixelFormatPacked (default) , isPDF = NO



On Jun 19, 2020, at 10:23 PM, Graham Cox <graham@...> wrote:

I need to determine whether I am drawing into a CGPDFContext or a different context at runtime.

In AppKit, I can use [NSGraphicsContext currentContextDrawingToScreen], but this is code that is passed a CGContextRef only, so that higher-level API isn’t appropriate. CGPDFContext doesn’t appear to have an associated CGPDFContextGetTypeID() function to compare with the result of CFGetTypeID(), so it’s unclear how I can do this.

The reason I need to so this is that objects I am drawing can have different states according to whether they are selected in the UI or not, but when capturing the drawing into a PDF, the selection state needs to be ignored, so the drawing code needs to be able to detect what context type is so that it can do this.

—Graham


Determining CGContext type at runtime

Graham Cox
 

I need to determine whether I am drawing into a CGPDFContext or a different context at runtime.

In AppKit, I can use [NSGraphicsContext currentContextDrawingToScreen], but this is code that is passed a CGContextRef only, so that higher-level API isn’t appropriate. CGPDFContext doesn’t appear to have an associated CGPDFContextGetTypeID() function to compare with the result of CFGetTypeID(), so it’s unclear how I can do this.

The reason I need to so this is that objects I am drawing can have different states according to whether they are selected in the UI or not, but when capturing the drawing into a PDF, the selection state needs to be ignored, so the drawing code needs to be able to detect what context type is so that it can do this.

—Graham


iCloudKit - CoreData Integration: What am I doing wrong?

Rick Aurbach
 

I have a CoreData-based app where I am experimenting with inter-device synchronization using iCloudKit. At the moment, I am running in Development mode and am using an iPad and a MacCatalyst app as the two test devices. Bottom line - things aren't working. Looking at the generated logs, it appears that after getting everything set up, data requests are being cancelled because of pending requests. (I.e., it looks like a request is being LOST or maybe being UNANSWERED).

Both the Mac and the iPad use the same AppleID (but not the AppleID associated with the application).

I have put together a folder that may help explain the problem. It contains the code of my CoreDataStack class, the SceneDelegate that makes the call to open the database, the Xcode logs (from both the iPad and the iMac runs) showing the progression of messages, and printed images of information from my iCloudKit Dashboard.
(in case the folder attachment doesn't work, try this Dropbox download: https://www.dropbox.com/sh/vdeg9pcmy2fdo17/AABNuCdojZjr5tP6BEpu3T0ma?dl=0 ).


Re: Manually-shown palettes not showing during app restoration

Steve Mills
 

On May 18, 2020, at 10:29:13, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

I needed to add many attributes to my CoreData model. Filling in these attributes will happen during migration of old docs, which means loading all the files that each asset points to. Since it can take a while to do all this, I'm putting up a progress palette so the user knows something is happening. This works fine.

What does NOT work fine is when migration happens during app restoration. The palette says its window is loaded and the frame is correct, but it's just not appearing onscreen. Does app restoration do some kind of window manager voodoo that prevents windows NOT being restored from appearing? Maybe so it doesn't confuse the list of windows being restored?
Screw it. I've switched the migration progress window to a regular window and now present it modally. This kind of window WILL appear during state restoration, unlike a palette which has been sent orderFront.

--
Steve Mills
Drummer, Mac geek


Manually-shown palettes not showing during app restoration

Steve Mills
 

I needed to add many attributes to my CoreData model. Filling in these attributes will happen during migration of old docs, which means loading all the files that each asset points to. Since it can take a while to do all this, I'm putting up a progress palette so the user knows something is happening. This works fine.

What does NOT work fine is when migration happens during app restoration. The palette says its window is loaded and the frame is correct, but it's just not appearing onscreen. Does app restoration do some kind of window manager voodoo that prevents windows NOT being restored from appearing? Maybe so it doesn't confuse the list of windows being restored?

--
Steve Mills
Drummer, Mac geek


WkWebView with URLSchemeHandler

Gerriet M. Denkmann
 

macOS 15.4; Xcode Version 11.4 (11E146)

I have a window with a WkWebView.

This WkWebView should handle a special scheme.
The only way to do this that I know of, is:

@IBOutlet var wkWebView: WKWebView!
guard let webSuperView = wkWebView.superview else ...
let copiedConfiguration = wkWebView.configuration
copiedConfiguration.setURLSchemeHandler(self, forURLScheme: mySpecialScheme )
let newWebView = WKWebView(frame: wkWebView.frame, configuration: copiedConfiguration)
webSuperView.addSubview(newWebView)
wkWebView.removeFromSuperview()
wkWebView = newWebView

The problem: the old wkWebView had (done in IB) several layout constraints.

I tried to copy these constraints to the newWebView; but this crashes with:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION
(code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x00007fff2fcb5f13 AppKit`-[NSApplication _crashOnException:] + 106
frame #1: 0x00007fff2fa73c1c AppKit`__62+[CATransaction(NSCATransaction)
NS_setFlushesWithDisplayLink]_block_invoke + 805



• Is there a way to configure a URLSchemeHandler in IB?
• Is there a way to add a URLSchemeHandler to an existing WkWebView?

Gerriet.


Re: Correcting scrollbar after app state restoration

Steve Mills
 

On May 14, 2020, at 01:56:27, Allan Odgaard <groups-io@simplit.com> wrote:

You can send reflectScrolledClipView: to the NSScrollView instance after state restoration.

But it should basically never be necessary to call this method manually, so even if it fixes it, something may still be wrong / broken.

https://developer.apple.com/documentation/appkit/nsscrollview/1403534-reflectscrolledclipview
Thanks for pointing out that method. I tried it, but it didn't work. Not sure when the scrollbar is being restored to a stupid value. But, I've added predicate restoration, and that solves it. I also added a small icon that indicates when the collection view is showing some or all items, which lets the user see at a glance after re-open that they might not be seeing everything.

--
Steve Mills
Drummer, Mac geek


Re: Correcting scrollbar after app state restoration

Allan Odgaard
 

On 14 May 2020, at 11:00, Steve Mills via groups.io wrote:

I can *not* figure out a good way to tell the collection view, scroll view, or what that it needs to recalc the size of the thumb. It's driving me bonkers. Any ideas?
You can send reflectScrolledClipView: to the NSScrollView instance after state restoration.

But it should basically never be necessary to call this method manually, so even if it fixes it, something may still be wrong / broken.

https://developer.apple.com/documentation/appkit/nsscrollview/1403534-reflectscrolledclipview


Re: Correcting scrollbar after app state restoration

Allan Odgaard
 

You can send reflectScrolledClipView: to the NSScrollView instance after state restoration.
 
But it should basically never be necessary to call this method manually, so even if it fixes it, something may still be wrong / broken.
 
https://developer.apple.com/documentation/appkit/nsscrollview/1403534-reflectscrolledclipview


Re: Correcting scrollbar after app state restoration

Steve Mills
 

On May 14, 2020, at 10:13:15, Glenn L. Austin <glenn@austinsoft.com> wrote:

You need to save and restore the state of the data being shown as well. If you use an IndexSet for your sub-collection, you could use, save and restore that.
Hmm. I'd have to restore the search predicate. That should be doable, but it rubs me the wrong way that a document, when restored, only shows the last subset of items instead of showing everything. Photos doesn't restore the find term and show the find results, it shows everything. Neither does Mail. I'd much rather find a way to kick the scrollbar in the ass and tell it to be correct. It's extremely strange that document restoration remembers and restores a scrollbar's thumb size and scroll position. It should be set based on the scrollview's contents.

--
Steve Mills
Drummer, Mac geek


Re: Correcting scrollbar after app state restoration

Glenn L. Austin
 

You need to save and restore the state of the data being shown as well.  If you use an IndexSet for your sub-collection, you could use, save and restore that.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver         <><
<http://www.austinsoft.com>

On May 13, 2020, at 9:00 PM, Steve Mills via groups.io <sjmills@...> wrote:

I've noticed that the vertical scrollbar in the scroll view for my collection view is wrong after app restoration. This happens if the full collection (via CoreData) has, say 1000 items in it, then I do a filtered fetch to limit the collection to, say, 100 items. When showing all 1k items, the scrollbar thumb is small. When showing 100 items, the thumb is much larger.

I save and quit. The next time I launch, it restores the previously opened doc and restores the window state, including the collection view, scroll view, and scrollbar, including restoring the scrollbar state, which means the thumb is large like it was during save and quit, yet the collection view contains all 1k items, not just 100 items.

I can *not* figure out a good way to tell the collection view, scroll view, or what that it needs to recalc the size of the thumb. It's driving me bonkers. Any ideas?

All the restoration crap is just being handled by the OS - I'm not overriding any method to do the state restoration.

--
Steve Mills
Drummer, Mac geek






Correcting scrollbar after app state restoration

Steve Mills
 

I've noticed that the vertical scrollbar in the scroll view for my collection view is wrong after app restoration. This happens if the full collection (via CoreData) has, say 1000 items in it, then I do a filtered fetch to limit the collection to, say, 100 items. When showing all 1k items, the scrollbar thumb is small. When showing 100 items, the thumb is much larger.

I save and quit. The next time I launch, it restores the previously opened doc and restores the window state, including the collection view, scroll view, and scrollbar, including restoring the scrollbar state, which means the thumb is large like it was during save and quit, yet the collection view contains all 1k items, not just 100 items.

I can *not* figure out a good way to tell the collection view, scroll view, or what that it needs to recalc the size of the thumb. It's driving me bonkers. Any ideas?

All the restoration crap is just being handled by the OS - I'm not overriding any method to do the state restoration.

--
Steve Mills
Drummer, Mac geek


Re: CoreData in Objective-C in Xcode 11

Chris Hanson
 

On May 12, 2020, at 5:56 PM, Alex Zavatone via groups.io <zav@...> wrote:

I’m going through Chris Eidhof’s Core Data tutorial here https://www.objc.io/issues/4-core-data/full-core-data-application/ and noticed something that ends up creating a build error directly after creating creating a simple ManagedObjectModel from the Editor > Create NSManagedObject Subclass.

Two Swift files are created, not Objective-C files.

Item+CoreDataProperties.swift
Item+CoreDataClass.swift

The creation of these classes create a build errors right away.  Is it expected that an Objective C project will create Swift MOC subclasses?  Is anyone using CoreData in Xcode 11?
I’m curious what’a happening here.

The language used for creating NSManagedObject (not MOC) subclasses is set in the data model’s file inspector. It defaults to Swift.

Core Data data models also support automatic code generation, which is enabled by default, so if you don’t want classes generated automatically for certain entities you need to specify that in their inspector. You can also specify that just a class extension be generated for a particular entity, so you still own the overall class definition and just the attribute & relationship accessors will be handled for you.

  -- Chris


Re: CoreData in Objective-C in Xcode 11

Alex Zavatone
 

It works as expected in Xcode 10.  : /

On May 12, 2020, at 11:54 PM, Steve Christensen via groups.io <punster@...> wrote:

Check the entity inspector in the model file. As I recall, there are options for auto-creating Obj-C it Swift class files, or manual if you want to create and edit the class files yourself. Perhaps it’s now defaulting to Swift. (I’m not around my computer now, so it’s a guess.)

On May 12, 2020, at 5:56 PM, Alex Zavatone via groups.io <zav@...> wrote:

I’m going through Chris Eidhof’s Core Data tutorial here https://www.objc.io/issues/4-core-data/full-core-data-application/ and noticed something that ends up creating a build error directly after creating creating a simple ManagedObjectModel from the Editor > Create NSManagedObject Subclass.

Two Swift files are created, not Objective-C files.

Item+CoreDataProperties.swift
Item+CoreDataClass.swift

The creation of these classes create a build errors right away.  Is it expected that an Objective C project will create Swift MOC subclasses?  Is anyone using CoreData in Xcode 11?
I’m curious what’a happening here.

Thanks.


<unknown>:0: error: filename "Item+CoreDataClass.swift" used twice: '/Users/zav/Developer/BasicCoreData/BasicCoreData/Item+CoreDataClass.swift' and '/Users/zav/Library/Developer/Xcode/DerivedData/BasicCoreData-ddewwduzsmelbzawnlblirktothl/Build/Intermediates.noindex/BasicCoreData.build/Debug-iphonesimulator/BasicCoreData.build/DerivedSources/CoreDataGenerated/ItemModel/Item+CoreDataClass.swift'
<unknown>:0: note: filenames are used to distinguish private declarations with the same name
<unknown>:0: error: filename "Item+CoreDataProperties.swift" used twice: '/Users/zav/Developer/BasicCoreData/BasicCoreData/Item+CoreDataProperties.swift' and '/Users/zav/Library/Developer/Xcode/DerivedData/BasicCoreData-ddewwduzsmelbzawnlblirktothl/Build/Intermediates.noindex/BasicCoreData.build/Debug-iphonesimulator/BasicCoreData.build/DerivedSources/CoreDataGenerated/ItemModel/Item+CoreDataProperties.swift'
<unknown>:0: note: filenames are used to distinguish private declarations with the same name


error: Multiple commands produce '/Users/zav/Library/Developer/Xcode/DerivedData/BasicCoreData-ddewwduzsmelbzawnlblirktothl/Build/Intermediates.noindex/BasicCoreData.build/Debug-iphonesimulator/BasicCoreData.build/Objects-normal/x86_64/Item+CoreDataClass.o':
1) Target 'BasicCoreData' (project 'BasicCoreData') has compile command for Swift source files
2) Target 'BasicCoreData' (project 'BasicCoreData') has compile command for Swift source files

error: Multiple commands produce '/Users/zav/Library/Developer/Xcode/DerivedData/BasicCoreData-ddewwduzsmelbzawnlblirktothl/Build/Intermediates.noindex/BasicCoreData.build/Debug-iphonesimulator/BasicCoreData.build/Objects-normal/x86_64/Item+CoreDataProperties.o':
1) Target 'BasicCoreData' (project 'BasicCoreData') has compile command for Swift source files
2) Target 'BasicCoreData' (project 'BasicCoreData') has compile command for Swift source files


–––––––––––––––––––––

Item+CoreDataClass.swift


import Foundation
import CoreData

@objc(Item)
public class Item: NSManagedObject {

}


–––––––––––––––––––––

Item+CoreDataProperties.swift


import Foundation
import CoreData


extension Item {

    @nonobjc public class func fetchRequest() -> NSFetchRequest<Item> {
        return NSFetchRequest<Item>(entityName: "Item")
    }

    @NSManaged public var order: Int64
    @NSManaged public var title: String?
    @NSManaged public var parent: Item?
    @NSManaged public var child: Item?

}





121 - 140 of 1378