I'm working with a document-based core-data OS X application. The problem I'm having is that whenever I edit any field on the document, after I press tab or click to something else (i.e. I finish editing/change focus), the document is marked as clean and undo is reset. When I try to save the file, however, the resulting document opens without the data I entered. What might be the problem, or, any pointers on where to look to fix this? Here's some stuff I know and things I've already tried:
I know it's not somehow saving because it never stops at the breakpoint in my overridden writeSafelyToURL:(NSURL *)inAbsoluteURL ofType:(NSString *)inTypeName forSaveOperation:(NSSaveOperationType)inSaveOperation error:(NSError **)outError and it also never sends an NSManagedObjectContextDidSaveNotification.
The documents are packaged in an NSFileWrapper directory with the core data store inside (and also some other files). I access the entities through an NSObjectController and a couple NSArrayControllers. It happens with both core data properties and manually registered changes in the rest of the file wrapper.
Update: At the suggestion of Martin, I tried NSUndoManager's notifications, and all I can seem to glean from it is that more than one undo manager is in play. If I add an observer for NSUndoManager, it won't post if I specify an object, and then if I don't, the notification object is not equal to [self undoManager]. I added updateChangeCount to my category on NSPersistentDocument, and it never gets called. setDocumentEdited basically confirmed that something about losing first responder is passing NO into that method. What could be causing this, and how can I fix it?
You could break on the method setDocumentEdited: of NSWindow to see which operation updates the change status.
In addition updateChangeCount: of NSDocument might be a place to take a look at.
NSUndoManager also posts several Notifications which can give additional hints what to look at.
The answer is actually pretty silly considering how long this stumped me. I was working on some objects on load, and I accidentally set [[self undoManager] disableUndoRegistration] at both the points where I should disable and enable. It was a little more than that, though. A related element in Interface Builder needed to be checked Prepares Content. When I had done both those things, the problem vanished.
Related
I have made like an "Asteroid" copy, that works pretty well! I made it with different modules (enemies, controls and background). Now I have also made like a starting screen, where the player can choose to play the game, view highscores etc.
The problem is that I have no clue how to implement this into a storyboard.. I might have misunderstood the use of modules.
I am starting in a Scene1, which is the intro+buttons to start the game. Next, I want to move to scene2(when player presses start button), and that seems to be no problem, and scene 1 gets purged. But when I die, I want to move to scene1 again. Problem is that some listeners dont get removed, and the game crashes shortly after scene switch.
I guess the main problem is that in my scene2, I have put in require("background"), enemies and controls in my enterscene, which I dont know how to remove when it should be purged.
Ive entered all of the modules and put them in the same group that gets purged on exitscene, but not everything gets removed.
How do you think I would fix this the easiest way? I am very new to Corona and still in a early learning stage.
Display objects, like display.newImageRect()'s and display.newText() that are created in the createScene() function and added to the "group" display group will be automatically removed when the scene is purged.
Any timers, transitions, or audio.plays that have onComplete handlers, as well as network requests and any event handler that attaches to the Runtime must be removed by hand. If you're various object you are creating are doing any of these things, their remove functions should undo these actions so that removing them will clean them up.
I find it best if I'm adding runtime handlers, timers, etc. to do it in enterScene() and make sure I undo them in exitScene(). Then if its something that is done in createScene() it should be cleaned up in destoryScene().
modules are kind deprecated to start.
Second, putting stuff in other files and calling them with "require" is supposed to be used to call libraries, not code that will run. "require" is not a dofile, or a eval, it will run once, and only once (when the first "require" of the file is made).
If you still want to put things in other files, like loading your background, you need to do a "background.lua" file that has a "background.load()" function and a "background.unload()" function, and call them in appropriate places.
I have a cocoa app that allows the user to enter a query. I'm using an NSWebView with a TextArea HTML object. The problem is, as soon as I type anything into the textarea, my document gets marked as updated. Does anyone know of a way to prevent this?
I've verified that using a NSTextField does not reproduce this behaviour, but I specifically want to go with the HTML/TextArea for styling.
So basically: Can I make it so an NSDocument does not get marked as edited unless I manually call:
[document updateChangeCount: NSChangeDone];
This post on the Apple mailing list seems to match your problem exactly.
The solution suggested is to set a custom undo manager to the webview (sounds like hard work), however a quick-and-dirty hack looks to me like subclassing updateChangeCount and perverting things to your way of thinking.
I have some NSManagedObject subclass in my app, and I'm trying to understand when and how to save changes.
I will try to explain myself, for example class A is NSManagedObject subclass.
During app life cycle I do:
App launched
...
Create an instance of class A
...
Change some properties of A instance
...
App go to background
...
App becomes active again
...
Change some more properties of A instance
...
App terminates
When do I need to call [context save:] ??
Do I call it after every change in A instance? Or maybe I call it only when app go to background?
Should I call it after creation or deletion of any A instance?
A nice approach is place UIManagedDocument in your AppDelegate. Then you can call [context save] whenever some change occurs in the app (like a crash). The order I like to follow is something like:
Create UIManagedDocument object (in application did load or wherever)
and assign it to a property
Setup the document (check whether it exist on disk or is already open, etc.. and respond accordingly)
Pass the UIManagedObjectContext to the initial UIViewController in your app (from there you can pass the context to other view controllers)
UIManaged document will save the context for you.
Take a look at the UIManagedDocument documentation to configure persistent store options (you send an NSDictionary of options to your UIManagedDocument instance, see the first example through the link below).
UIManagedDocument documentation:
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIManagedDocument_Class/Reference/Reference.html
Also see the CoreData lecture and demo (lectures 13 and 14) of the iPhone and iPad application development course with Paul Hegarty available free on iTunesU (Fall 2011).
The data will not be saved to the persistent store until you call save. So, it depends on what you want in your app. If you want it to be able to recover the last value it ever had, then you should save after each modification.
Easy change is to just save after making modifications.
You could do something a bit more fancy, like only save after some set amount of time, so many changes are grouped together... and catch any event that will put your app in the background and then save...
But, that's what UIManagedDocument does automatically for you, so you could just use that instead.
Depending on the amount of changes that you make and the volume of data that needs to be saved with each change, yo can choose to save a little or a lot. If you are just saving a string or a number or a bool, then go ahead and call save: on your context as soon as the changes were made.
If it is a lot of data, you may want to coalasce your changes and then save it on a background queue so that you are not blocking the main queue. This way you are not waiting to go to the background to perform your saves.
Tim
I'm trying to use a recent feature of the Scintilla component, which provides OSX-like text-highlighting effect (the yellow animated bouncing box), and I'm stuck with an error that pops up intermittently :
EXC_BAD_ACCESS
pointing to this particular line :
if (layerFindIndicator!=nil)
if ([layerFindIndicator animationForKey:#"animateFound"])
[layerFindIndicator removeAnimationForKey:#"animateFound"];
(the ifs are mine; just in case I caught the object layerFindIndicator being nil, or deallocated or whatever... Unfortunately, it doesn't help...)
layerFindIndicator is seemingly a subclass of CAGradientLayer. (You may see the full code for layerFindIndicator, here).
Since, I'm an absolute newbie to Quartz Core, could please give me any hint as to HOW this could be debugged?
Since, I'm an absolute newbie to Quartz Core, could please give me any hint as to HOW this could be debugged?
This doesn't have anything to do with QuartzCore specifically (at least, I hope not)—it's general this-object-has-been-killed-before-its-time-how-do-I-find-the-killer stuff.
In Xcode:
Edit your current scheme.
For the Profile action, set it to use the Debug build configuration.
Dismiss that and then hit the Profile command.
Xcode will build for that action and then launch Instruments.
Instruments will prompt you to choose a template; you want the Zombies template. Once you've chosen it, Instruments will create a trace document and run your application. Switch to your application (if it isn't already frontmost), then do whatever causes the crash.
If the crash really is a dead-object crash, Zombies will reveal it. You'll get a flag in Instruments's timeline saying something like “message sent to zombie object 0xd3c2b1a0”, and your program will probably exit shortly thereafter.
In that flag is a tiny little button that looks like this: ➲ except it'll be gray. Click on it.
That takes you to the history of that object (actually of that address, including any previous objects or other allocations that have started at that address). Show your Extended Detail Pane (the one that appears on the right showing a stack trace), then scroll down to the end and then move backward (upward) step by step through time, looking at releases and autoreleases, looking for the one that isn't balancing out the object's allocation or a retain.
The solution will probably involve one or more of:
Changing a property to be strong or weak rather than assign/unsafe_unretained
Adding a property where you previously did not strongly own an object
Rearchitecting some things, if it's not clear which of the above you need to do or if either one of them seems like a filthy hack
Switching to ARC to get weak properties and __weak instance variables (both of which get set to nil automatically when the referenced object dies) and to get local variables being implicitly initialized to nil
But it'll depend on what you find in Instruments. And, of course, there's the chance that your problem—the bad access—isn't a dead object at all and all of the above will not help you.
Try this:
if (layerFindIndicator!=nil){
if ([layerFindIndicator animationForKey:#"animateFound"]){
[layerFindIndicator removeAnimationForKey:#"animateFound"];
}
}
Also check to see if it is released else were.
EDIT:
Another thing I found was you didn't have an white space in the if. Your code should now look like this:
if (layerFindIndicator != nil){
if ([layerFindIndicator animationForKey:#"animateFound"]){
[layerFindIndicator removeAnimationForKey:#"animateFound"];
}
}
I'm struggling to use Chromium Tabs in Cocoa and I really seem to be missing something.
I've subclassed CTBrowserWindowController (ppEditor), CTBrowser (ppDocumentBrowser), CTTabContents (ppDocument) and CTTabContentsController (ppDocumentController)
Editor creates new Documents by : [self addTabContents:(ppDocument*)doc]; (and I've also tried first adding a Document Controller for the specific document first, but this doesn't work either)
I'm connecting my outlets from TabContents.xib (either to File Owner : ppDocumentController or to an instance of ppDocument I'm adding to the XIB), but it doesn't work and the outlet instances show up (intermittently) as NULL pointers.
So, what could be going wrong?
NOTE :
When connecting actions (either to the ppDocument class, or the ppDocumentController), these - weirdly so - do work....
There is some cross-referencing between classes (e.g. there is a pointer to ppDocument from ppDocumentController, as well as one from ppDocument to ppDocumentController)
Problem solved.
Although, I have no idea how - I basically did the whole thing from scratch and ooops, it worked (I must have missed something in the first place...)