applicationWillTerminate not being called

[Dreamspinner]

When my OS X app closes (via the Quit button in the menu), I need to write out a text file. The applicationWillTerminate method isn't being called. It's in my app delegate. I've spent hours & hours reading posts on the same problem, with no resolution. The Apple doc didn't help either.

[chown33]

Post your code.

A common cause of uncalled delegate methods is incorrect spelling (usually a typo) or wrong parameters. Without seeing your actual code, that would be my first guess.

[Dreamspinner]

Originally Posted by chown33

Post your code.

A common cause of uncalled delegate methods is incorrect spelling (usually a typo) or wrong parameters. Without seeing your actual code, that would be my first guess.

- (void)applicationWillTerminate:(NSNotification *)notification{
		[self putSettings:(nil)];
}

[chown33]

Please explain how you know the method isn't being called.

Did you set a breakpoint on it and see if it's being triggered? Is there some code like an NSLog in putSettings:? Exactly what code is in putSettings: and what does nil as a parameter mean?

What other methods of NSApplicationDelegate are implemented? Is one of them applicationShouldTerminate:? Have you set a breakpoint on that? How about any of the application-launch methods?

What have you tried to debug this?

http://www.mikeash.com/getting_answers.html

[Dreamspinner]

Originally Posted by chown33

Please explain how you know the method isn't being called.

Did you set a breakpoint on it and see if it's being triggered? Is there some code like an NSLog in putSettings:? Exactly what code is in putSettings: and what does nil as a parameter mean?

What other methods of NSApplicationDelegate are implemented? Is one of them applicationShouldTerminate:? Have you set a breakpoint on that? How about any of the application-launch methods?

What have you tried to debug this?

http://www.mikeash.com/getting_answers.html

I set breakpoints and put NSLogs in both methods. I have tried putSettings defined as an action, and as returning void. nil was a kludge to satisfy the compiler.

I did have applicationShouldTerminate: with breakpoint an NSLog, but it wasn't getting called either.

- (void)awakeFromNib{ works.

//- (IBAction)putSettings:(id)sender;{
- (void)putSettings;{
	NSString *line1 = portsButton.titleOfSelectedItem;
	NSError *err = nil;
	NSString *path = [[NSBundle mainBundle] pathForResource:@"RotorSettings" ofType:@"txt"];
	
	
	line1 = [line1 stringByAppendingString:(portsButton.titleOfSelectedItem)];
	line1 =[line1 stringByAppendingString:(@":")];
	line1 =[line1 stringByAppendingString:(baudButton.titleOfSelectedItem)];
	
	if(![line1 writeToFile:path atomically:YES encoding:NSUTF8StringEncoding error:&err]) {
    //handle error

	}
}

[chown33]

Originally Posted by Dreamspinner

I set breakpoints and put NSLogs in both methods.

Show your code with the NSLogs. If you got no output, then say that you got no output.

We can't read your mind. We don't know what you did unless you tell us. We can't read your screen or see your code unless you post it. I gave the link of the Getting Answers article for a reason: you're not providing adequate information or explanation for debugging.

Debugging is detective work. You have to gather evidence, get information, and put logical connections together. You have to build the case and present your findings so others can see the evidence, information, and logical connections for themselves. Without evidence, all you have is unsubstantiated beliefs and expectations.

I have tried putSettings defined as an action, and as returning void. nil was a kludge to satisfy the compiler.

What was the error message or warning that made you think you need a kludge? Maybe what you did to satisfy the compiler is the cause of things not working.

An error message or warning is evidence. The code that causes the message is also evidence. Naively applying kludges in order to make the visible problem go away isn't necessarily a real solution.

I did have applicationShouldTerminate: with breakpoint an NSLog, but it wasn't getting called either.

So you have two methods of the same delegate object that aren't being called. This is evidence.

Logically speaking, what might be some possible causes for multiple methods of the same delegate object not being called?

I want you to think of some possible answers for this question. I already outlined one in my first reply: misspelled method names. So think of some others before continuing.



The first thing that comes to mind for me is that the object you think is acting as app-delegate isn't really the app-delegate. Either some other object is the real app-delegate, or no object is.

So think about how you'd gather evidence and information that the object you think is app-delegate is really the app-delegate. Start by describing how you set the app-delegate. Then show the code for the entire app-delegate class, not just isolated methods of it.

- (void)awakeFromNib{ works.

The NSApplicationDelegate protocol doesn't have an awakeFromNib method. So if that method is being called, it's not because the object receiving the message is the app-delegate. It's because that object is playing another role, one associated with loading a nib.

//- (IBAction)putSettings:(id)sender;{
- (void)putSettings;{
	NSString *line1 = portsButton.titleOfSelectedItem;
	NSError *err = nil;
	NSString *path = [[NSBundle mainBundle] pathForResource:@"RotorSettings" ofType:@"txt"];
	
	
	line1 = [line1 stringByAppendingString:(portsButton.titleOfSelectedItem)];
	line1 =[line1 stringByAppendingString:(@":")];
	line1 =[line1 stringByAppendingString:(baudButton.titleOfSelectedItem)];
	
	if(![line1 writeToFile:path atomically:YES encoding:NSUTF8StringEncoding error:&err]) {
    //handle error

	}
}

This code has a serious problem, a misplaced semicolon, which I've hilited in red.

I don't know what this will do as written, but I can tell what it doesn't do. It doesn't define the brace-enclosed block as the body of a method. To define a method, the opening brace must be the first non-whitespace non-comment after the last parameter name - no semicolon.

If you copy-pasted the method declaration from your @interface (I'm guessing, since you haven't posted code), then you must replace the semicolon with a { } block, not append a { } block after the semicolon.

FWIW, all C-like languages work this way. The body of the function or method goes directly after the declaration of the name and parameters. Depending on exactly which language, an intervening semicolon may result in invalid code, which the compiler will reject, or it may result in syntactically correct code, which the compiler will accept, but with a completely different and unintended meaning.