I was working on a project the other day, and my preview stopped working. I got the error "Compiling Failed, cannot find "DataType" in scope" (all code/relationships will be shown below). I have restarted XCode a few times, and even commented out that area of code but it continues to not work, is anyone else having this problem and how can I fix it?
I am previewing a sheet called "Profile Sheet", just a standard swiftUI View, so the preview code looks like:
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ProfileSheet()
}
}
In the profile sheet, it is accessing data from a static function associated with my model file (different struct, different file), the functions it is using, and the ones that define "DataType", the problematic generic are here:
static func saveData<DataType>(data: DataType, for key: String) {
defaults.setValue(data, forKey: key)
}
static func retrieveData<DataType>(defaultValue: DataType, for key: String) -> DataType {
guard let value = defaults.value(forKey: key) as? DataType else {return defaultValue}
return value
}
static func saveComplexData<DataType>(data: DataType, for key: String) where DataType: Codable {
let encodedData = try! JSONEncoder().encode(data)
defaults.setValue(encodedData, forKey: key)
}
static func retrieveComplexData<DataType>(defaultValue: DataType, for key: String) -> DataType where DataType: Codable {
guard let retrievedData = defaults.value(forKey: key) as? Data else { return defaultValue}
let decodedData = try! JSONDecoder().decode(DataType.self, from: retrievedData)
return decodedData
}
all of these function as intended, and obviously compile. Even when I run to launch the previewer and compiles my app does it builder properly, its only when it is then trying to launch the preview simulator.
Finally, I thought Id remove those functions entirely and just try to display a View that has no connection to them, so I previewed Text("test") and got the same error.
on Xcode 13 beta 3 & 4 I am able to run the simulator, but I cannot work only on those betas as they are still fairly unstable.
Any help is appreciated :)
I've seen quite a bit of weird behavior with frameworks, I think due to changes to the simulators to support Apple silicon. My temporary workaround is, in my app/extension targets, to add "arm64" to the Excluded Architectures build setting when building for the simulator (as your preview appears to be trying to do), and setting "Build Active Architecture Only" to No for all schemes. Might be worth a try.
As per triplette in apple developer answers.
Try to check it out
https://developer.apple.com/forums/thread/657913
I believe it's not an issue with your code it's an issue with Xcode due to apple silicon macs. try to do a software update and reinstall the Xcode.
Related
I've started a document-base macOS app in SwiftUI and am using a FileDocument (not a Reference FileDocument) as the type of document. In every tutorial I've seen, even in Apple's own WWDC video discussing it (https://developer.apple.com/wwdc20/10039), a struct is always used to define the FileDocument.
My question is: is there an issue with using a class in the struct defining the document. Doing so doesn't result in any Xcode warnings but I wanted to be sure I'm not creating any issues for my app before going down this path.
Below is some example code for what I'm talking about: declaring TestProjectData as a class for use within the DocumentDataAsClassInsteadOfStructDocument - struct as a FileDocument?
public class TestProjectData: Codable{
var anotherString: String
init(){
anotherString = "Hello world!"
}
}
struct DocumentDataAsClassInsteadOfStructDocument: FileDocument, Codable {
var project: TestProjectData
init() {
project = TestProjectData()
}
static var readableContentTypes: [UTType] { [.exampleText] }
init(configuration: ReadConfiguration) throws {
guard let data = configuration.file.regularFileContents,
let _ = String(data: data, encoding: .utf8)
else {
throw CocoaError(.fileReadCorruptFile)
}
let fileContents = try JSONDecoder().decode(Self.self, from: data)
self = fileContents
}
func fileWrapper(configuration: WriteConfiguration) throws -> FileWrapper {
let data = try JSONEncoder().encode(self)
return .init(regularFileWithContents: data)
}
}
It appears that yes, we need to use a struct for documents. See this post for a thorough example of the issues you can run into if you use a class instead of a struct.
SwiftUI View doesn't update
SwiftUI's architecture is all about using value types for speed and consistency. E.g. on a state change we create all the View structs and then SwiftUI diffs and uses the result to init/update/deinit UIView objects.
I believe the same thing happens with FileDocument. The struct is diffed on a change and the difference is used to init/update/deinit a UIDocument object.
If you init object vars inside these structs then basically it is a memory leak because a new object will be init every time the struct is created which is every time something changes. Also chances are you'll end up using the wrong instance of the object because there will be so many. You can see this type of problem surface when blocks are used inside body, the callback usually happens on an older version of the View struct, which isn't a problem when everything is value types but it is a big problem if referencing old objects.
Try to stick to value types in SwiftUI if you can, if you use objects you'll run into all kinds of headaches. And I don't think ReferenceFileDocument even works yet - I seem to remember it needs some kind of undo manager workaround.
Environment: mac OS, Catalina, I tried on iOS simulator
AudioKit framework's structure is like this
I added the following code , rebuild the xcode target, and the change is not updated in the new framework
// see the right channel data
public class Table: NSObject, MutableCollection, Codable {
public
convenience init?(rhs file: AVAudioFile) {
let size = Int(file.length)
self.init(count: size)
guard let data = file.toFloatChannelData() else { return nil }
for i in 0 ..< size {
self[i] = data[1][i]
}
}
}
I have tried Product -> Clear Build folder , both on target AudioKit and Cookbook
I have tried Product -> Clear Build folder , and put alt, on both
I have tried to quit Xcode , and reboot MBP
Still not work.
How to update the swift framework.
I'm trying to add some drag-and-drop support to my SwiftUI macOS app to allow the user to drop .stl files onto the window. I’ve got the drop working, but I only seem to be able to validate against public.file-url, rather than the specific public.standard-tesselated-geometry-format (provided by ModelIO as kUTTypeStereolithography).
In my code, I do something like this:
func
validateDrop(info inInfo: DropInfo)
-> Bool
{
debugLog("STL: \(kUTTypeStereolithography)")
let has = inInfo.hasItemsConforming(to: [kUTTypeFileURL as String, kUTTypeData as String])
return has
}
func
performDrop(info inInfo: DropInfo)
-> Bool
{
inInfo.itemProviders(for: [kUTTypeFileURL as String, kUTTypeData as String, kUTTypeStereolithography]).forEach
{ inItem in
debugLog("UTIs: \(inItem.registeredTypeIdentifiers)")
inItem.loadItem(forTypeIdentifier: kUTTypeFileURL as String, options: nil)
{ (inURLData, inError) in
if let error = inError
{
debugLog("Error: \(error)")
return
}
if let urlData = inURLData as? Data,
let url = URL(dataRepresentation: urlData, relativeTo: nil)
{
debugLog("Dropped '\(url.path)'")
}
}
}
return true
}
This works well enough if I look for kUTTypeFileURL, but not if I look for kUTTypeStereolithography when I drop a .stl file onto the view.
I tried declaring it as an imported type but a) that didn’t seem to work and b) shouldn’t be necessary, since the existence of a symbolic constant implies macOS know about the type. I also don’t really know what it conforms to, although I tried both public.data and public.file-url.
I’d really like to be able to validate the type so that the user isn’t mislead by the drop UI. Currently, it indicates that my view will accept the drop if it’s not an .stl file, which I don’t want it to do.
I have File Promises implemented in a Cocoa app that allows dragging images from a view and dropping them to folders on the machine or to apps like preview or evernote. In the past this has worked well using the NSDraggingSource delegate and 'namesOfPromisedFilesDropped' method. This method would return the drop location and would allow me to write the image data directly there. So when dropping to an application icon like preview, or within an app like evernote, the file would be written and the app would either load or the image would simply show within.
Unfortunately this method was deprecated in 10.13 so it no longer gets called in new OS versions. Instead I've switched over to using the filePromiseProvider writePromiseTo url method of the "NSFilePromiseProviderDelegate" delegate. This method gets called, and the image data is processed. I get the destination URL and attempt to write the image data to this location. This works perfectly fine when simply dragging to folders on the Mac. But, when dragging to other app icons like Preview.app, or directly to a folder in Evernote, I get an error 'Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"'.
I've attempted this using full URLs, and, URL paths. Regardless of either, when dragging to other apps it simply will not allow the drop or creation of the file at that location.
Is there some entitlement that may be missing? I've even attempted the Apple source code found here with the same error: File Promises Source
Here is the code I'm using now that's returning the error with inability to write to outside app locations. This only works for dragging to folders on the computer.
extension DragDropContainerView: NSFilePromiseProviderDelegate {
internal func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, fileNameForType fileType: String) -> String {
let fileName = NameFormatter.getFormattedNameFromDate() + "." + fileType.getFileType().typeIdentifier
return fileName
}
internal func operationQueue(for filePromiseProvider: NSFilePromiseProvider) -> OperationQueue {
return workQueue
}
internal func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, writePromiseTo url: URL, completionHandler: #escaping (Error?) -> Void) {
if let snapshot = filePromiseProvider.userInfo as? SnapshotItem {
if let data = snapshot.representationData {
do {
try data.write(to: url)
completionHandler(nil)
} catch {
completionHandler(error)
}
}
}
}
}
Any help on this issue would be great. Ultimately, I simply want to be able to drag the image to an app and have that app accept the drag. This used to work but no longer does.
Update 1:
After extensive experimentation I've managed to find a 'solution' that works. I don't see why this works but some how this ultimately kicks off a flow that fires the old 'deprecated' method.
I create the dragged item;
let draggingItem = NSDraggingItem(pasteboardWriter: pasteboardWriter(forImageCanvas: self))
draggingItem.setDraggingFrame(screenshotImageView.frame, contents: draggingImage)
beginDraggingSession(with: [draggingItem], event: event, source: self)
This calls the below method;
private func pasteboardWriter(forImageCanvas imageCanvas: DragDropContainerView) -> NSPasteboardWriting {
let provider = FilePromiseProvider(fileType: kUTTypeJPEG as String, delegate: self)
provider.userInfo = imageCanvas.snapshotItem
return provider
}
This sets up the custom file promise session using the subclass below. As you can see, I'm not handling any logic here and it seems to be doing very little or nothing. As an added test to verify it's not really doing much, I'm setting the pasteboard type to 'audio'. I'm dragging an image not audio but it still works.
public class FilePromiseProvider : NSFilePromiseProvider {
public override func writableTypes(for pasteboard: NSPasteboard)
-> [NSPasteboard.PasteboardType] {
return [kUTTypeAudio as NSPasteboard.PasteboardType]
}
public override func writingOptions(forType type: NSPasteboard.PasteboardType,
pasteboard: NSPasteboard)
-> NSPasteboard.WritingOptions {
return super.writingOptions(forType: type, pasteboard: pasteboard)
}
}
So long at the above methods are implemented it apparently kicks off a flow that ultimately calls the 'deprecated' method below. This method works every time perfectly in Mojave showing that there must be an issue with the NSFilePromises API. If this method works, the file promises API should work the same but it does not;
override func namesOfPromisedFilesDropped(atDestination dropDestination: URL) -> [String]?
Once this method gets called everything works perfectly in Mojave for drags to app icons in the dock and directly into applications like Evernote returning the app to 100% drag drop functionality as it used to work in previous OS versions!
My file promises delegate is still in place but looks like the below. As you can see it's not doing anything any longer. However it's still required.
extension DragDropContainerView: NSFilePromiseProviderDelegate {
func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, fileNameForType fileType: String) -> String {
return ""
}
func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, writePromiseTo url: URL, completionHandler: #escaping (Error?) -> Void) {
}
}
Any comments on this 'solution' would be great. Any suggestions on how to do this better would also be welcomed. Please note, that according to Apple, there "is no guarantee that the file will be written in time" using the File Promises API. But with the above, the old deprecated method is somehow called in Mojave and works flawlessly every time.
Thanks
I'm running Xcode 9, Swift 4, High Sierra. In my code I have a mapping that, cut out and stripped down, includes this as the first lines in the closure:
let foo = graph.edges.map { (edge: Edge<Node>) -> (Int, Int) in
print(edge)
let fromvertex = (edge.from as? VertexElement)
.
.
.
}
There's a breakpoint on the line let from vertex ...
When run, the code is successful up to the breakpoint, which is where the problem starts. If at that point I execute po edge.from in the debugger, I get the expected result. If I step one line, and so execute the assignment, I get Thread 1: EXC_BAD_ACCESS (code=2, address=*whatever*). I can then execute po edge.from or even po (edge.from as? VertexElement) at that point and still get the expected results.
How can this be? There's no optional involved in edge.from, and I'd think the data is there correctly since the debugger finds it.
Edge is (as you'd expect) a generic class, with the first part of the definition being this:
public class Edge<T>: NSObject, NSCoding, Codable where T: Hashable {
public typealias Weight = SimWeight
public let from: Vertex<T>
public let to: Vertex<T>
public var weight: Weight? = nil
.
.
.
}
and then, the first part of Vertex, also a generic, looks like this:
public struct Vertex<T>: Equatable, Codable where T: Hashable {
public var data: T
public let index: Int
public var gridX: Int?
public var gridY: Int?
.
.
.
}
Node is another, concrete class (not a generic)
Finally, I have address sanitization turned on.
All that said, I neither can see where the exception is coming from, nor why the debugger can get the data when the program cannot. Any ideas what's wrong (or even how to debug it?)
I can only suspect a compiler problem, because it's fixed now by reorganizing the code. Specifically, I created this method within Edge:
func indirectEdge() throws -> IndirectEdge {
guard let fromvx = self.from as? VertexElement,
let tovx = self.to as? VertexElement,
let weight = self.weight else {throw TypeError.notVertex}
return IndirectEdge(from: fromvx.index, to: tovx.index, weight: weight)
}
and then changed the code at the top of this post to be:
guard let indirectEdges = try? graph.edges.map({ (edge) throws -> IndirectEdge in
return try edge.indirectEdge()
}) else {throw SimFileError.unimplementedOperation(why: "Don't know how to encode this graph")}
.
.
.
At that point everything began to work, without the exceptions. (yes, I changed the later code to accept the IndirectEdge; that code is further on and shouldn't have any effect.) What I expected was that the exception would move into the indirectEdge method, but that's not what happened. It's good the code works now, but scary that I can't figure out why.