Lately something weird has been happening to my projects in xcode: I've been trying to learn a lot of new stuff, and doing so by testing things out in different simple cocoa apps (written by me, from scratch). sometimes I will get a code that doesn't have any error messages, but when i run it, i will stop at some break-point. I then conclude that I have probably done something wrong, and restores the code back to the form it was before the error, but from then on out it is impossible to get the code to run. even if i restore the code to a state that i am 100 % sure that has worked before, it just stops at the same break-point. in order to fix this problem, i have to copy my code from the class this has happened to, delete the class, make a new one with the exact same name, paste the exact same code back in the class, and voila, it works again. what on earth is happening? my newest problem code goes like this:
-(IBAction)openFile:(id)sender {
NSOpenPanel *openPanel = [[NSOpenPanel alloc] init];
NSURL *fileURL;
[openPanel setCanChooseFiles:YES];
[openPanel setCanChooseDirectories:NO];
[openPanel setAllowsMultipleSelection:NO];
[openPanel setAllowedFileTypes:[NSArray arrayWithObject:#"txt"]];
if ( [openPanel runModal] == NSOKButton ) {
fileURL = [openPanel URL];
}
[openPanel release];
}
I know this code has worked before. It is currently my only method, and it activates when i press open in the menu. If I delete everything inside the method, so that pressing open should do nothing it stops at a break-point inside the method anyway. I have had exactly the same kind of problem before with openGL codes, and with a method that used c syntax to do file reading. Does anybody know what kind of horrible mistake I'm making over and over again?
A Breakpoint is something you yourself set explicitly to tell Xcode to pause the program at this exact line. Superficially it might look like the program crashed, but in reality it's just waiting for you to tell it to go on.
This page looks like it has a nice explanation of the breakpoint interface in Xcode. (This is from a framework called Cocos2D, but ignore that. You should stick to ordinary Cocoa until you know what you're doing.)
Related
I am running a .app and I need to "restart" it so to speak. Basically I need to tell it to close, then after closing, it should launch the path i tell (which is to itself) with some command line arguments. Is this possible with cocoa? Im getting stuck at the part where my app is closing then closed, then I cant get it back.
My code is in js-ctypes, but here is the objc pseudo code:
default_center = [NSDistributedNotificationCenter defaultCenter];
shared_workspace = [NSWorkspace sharedWorkspace];
notification_center = [[NSWorkspace sharedWorkspace] notificationCenter];
[notification_center addObserver:selector:name:object: ***, ***, NSWorkspaceDidLaunchApplicationNotification, NIL]
And in my observr when it responds with completion of quit it has code to launch. But as my app is closed it never gets to the observer responder.
Here
Thanks
You didn't mention any reason that you cannot launch a second instance of your app from the first instance, rather than the chicken & egg approach of trying to restart after you've quit... I have this code in my AppWillTerminate function where I have a situation like yours:
[[NSWorkspace sharedWorkspace] launchApplicationAtURL:appUrl options:NSWorkspaceLaunchNewInstance configuration:nil error:&error];
( To get the AppWillTerminate to be called in the first place, I had to disableSuddenTermination before calling [app quit] )
There's also some flag in the app's plist file like "allow multiple instance" or something.
Also, KNOW THIS: if your app is sandboxed, this will not work UNLESS it is code signed with an AppleStore given id, or with a Developer ID Application id. Also, it won't work on X.7 no matter what, when sandboxed.
METHOD TWO,
is to create a "Helper App". Your KillerApp goes through the Quit process, and right before it dies, it launches "HelperApp", which is a tiny command line tool which waits for KillerApp to really die, then relaunches it.
In XCode, the code for the HelperApp, a "Command line tool", is like this:
#import <Cocoa/Cocoa.h>
int main( int argc , char *argv[] ) {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
pid_t parentPID = atoi(argv[2]);
ProcessSerialNumber psn;
while ( GetProcessForPID(parentPID, &psn) != procNotFound )
sleep(1);
NSString* appPath = [NSString stringWithCString:argv[1] encoding:NSUTF8StringEncoding];
BOOL success = [[NSWorkspace sharedWorkspace] openFile:[appPath stringByExpandingTildeInPath]];
if ( ! success )
NSLog(#"Error: could not relaunch application at %#", appPath);
[pool drain];
return (success) ? 0 : 1;
}
As you can see, you call the HelperApp with a couple parameters from your KillerApp... And in the case where you don't need to be sandboxed, that's about it.
If you DO need sandboxing, then it gets more complicated, of course. You need to create a "privileged helper tool", and thank goodness there is sample code for it.
"SMJobBless" is the Apple sample code project which outlines how to do this, but it's kind of weird-- it doesn't actually DO anything. Thankfully, somebody took that project and created "SMJobBlessXPC" from it, which really does finish the job, ( and when you get it working, your KillerApp can actually communicate with your HelperApp ). The downside is that you need to exactly maintain the plist files of the two apps in terms of code signing.
My MacOS Cocoa application displays a window of static text, meaning it should not be changed by the user, should not be first responder, etcetera. The only thing that happens to the text is that each word of it changes color (from "idleColor" to "highlightColor", and then back again) at a specific point in time. It is similar to a Karaoke display - individual words change color, and then change back, under program control, based on a list of timed events.
All of this works beautifully under MacOS 10.7 and 10.8. BUT, under 10.9, the text color does NOT change UNLESS I click in the window and continually move the cursor around, so I am manually highlighting (and un-highlighting) some of the text, continuously. If I do this, the regular words behave as intended. Essentially, it feels like the OS is refusing to update the window under program control, unless I am forcing it to update by manually performing something that requires the UI to respond.
The code that performs the color changes is as follows:
if (sEvent.attribute == HIGHLIGHT_ON) {
[sTextView setTextColor:highlightColor range: currentRange];
textIsLitUp = YES;
}
else {
[sTextView setTextColor:idleColor range: currentRange];
textIsLitUp = NO;
}
[sTextView setNeedsDisplay:YES];
(sTextView is a subclass of NSTextView.)
Now, if I comment out that last line, then I get the same, incorrect behavior under 10.7 and 10.8. In other words, under 10.9, the setNeedsDisplay method is not working, or not working the same way.
Does anyone have any ideas about working around this, or have any other light to shed on the problem? Or am I doing something terribly wrong? It is CRITICAL to the application that the changes to the textColor happen without latency!
EDITING MY QUESTION - to answer it:
Found the answer elsewhere here! I needed to call setNeedsDisplay on the main thread - it was in a secondary thread. The weird thing is that it always seemed to work fine under 10.7 and 10.8. It only broke under 10.9. So I just changed this:
[myTextField setNeedsDisplay:YES];
To this:
dispatch_async(dispatch_get_main_queue(), ^{[myTextField setNeedsDisplay:YES];});
…and it seem to have worked. Hope this helps someone else…
You don’t want to do any of the changing of AppKit objects in non-main threads—it’ll work sometimes, maybe even often, but then every once in a while it’ll crash, and you’ll wonder why. So:
[sTextView setTextColor:idleColor range: currentRange];
needs to be on the main thread, too.
The app crashing with signal SIGABRT (the debugger output is child already added. It can't be added again) in the simulator and on the device. Runs fine when I profile the app in Xcode while running it on the simulator or the device. Why is this?
Update: I've figured out that this line of code is causing the problem:
Mover *moverObject = [[[Mover alloc] init] autorelease];
NSMutableArray * array = [moverObject moveToward:startPoint :finalPoint]//<-- This is the problem
moveToward is method that returns a NSMutableArray containing the points from the startPoint to the finalPoint. This worked fine early today but after I started testing something new I guess I broke it. I made no changes in the actual Mover.h/.m just in the GameLayer.m (where I was adding code). I'm not sure what I added to cause the problem.
Update 2: I did some more digging using breakpoints and I found that
GameLayer *gameLayerObject = [[GameLayer alloc] init];<-- This causes the crash
Inside mover.m where the method moveToward:: is, this is the furthest it will go without crashing. Again the error is child already added. It can't be added again. Why does this happen?
This may just be coincidence. Hard to say because you didn't post any code.
The error message is clear though: you're trying to addChild the same node more than once, either to the same parent or to a different parent. Check your code for situations where this can occur.
I have a ridiculous problem with Xcode 4.3.2. Whenever I declare a new variable say
NSMutableDictionary *var = [NSMutableDictionary alloc] init];, Xcode autocompletes NSMutableArray in LHS of the expression but not in RHS.
This is irritating obviously. Often causes typos which I have to re-correct going back and certainly hampers the flow. From my experience it doesn't happen in any other situation.
Anyone else ever faced this? Should I raise a bug?
I think that's because Xcode doesn't know if you want to make some operation with the class and tries to find an appropriate variable. So if you want Xcode to autocomplete your class name in RHS, first write [] then start typing inside: [NS...]
I'm looking for a good way to tell my Cocoa application to quit itself. Rest assured that this will not be used for production code. I'm just looking for an easy way to run one test and then close the application during debugging.
I have found that exit(0); will close the app, but it bypasses all of the normal application exit procedures, and I would like to keep all of them in place.
Essentially I want things to work as if a user pulled "Quit" from the menu, but I want it to happen automatically after I have finished with my test.
My code currently looks like this:
#if (SUPERFANCY_TESTING_MODE)
[self doSomething];
exit(0); // <-- I need something better to go here
#endif
You can pretty much rest assured that your app is going to get killed at least some of the time. Thus, defending against exits the like of exit(0); is required.
However, NSApplication implements the -terminate: method.
[NSApp terminate: nil]; ought to do what you want.
I would generally suggest posting it via -performSelector:afterDelay: with a delay of 0.0 to force it to happen at the top of the next pass through the event loop.
Example:
[NSApp performSelector:#selector(terminate:) withObject:nil afterDelay:0.0];