views:

24

answers:

2

Hi I am writing an iPhone app that that is trying to create a second a view when the user clicks on an element in UITableView. The code looks like

  ReplyToViewController *reply = [[ReplyToViewController alloc] initWithNibName:@"ReplyTo" bundle:nil];
 reply.delegate = self;
 Message *message = [resultData objectAtIndex:indexPath.row];
 int dbid = [message.bizid intValue];
 NSLog(@"dbid=%d",dbid);

 reply.currentMessage = message;
 reply.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
 [self presentModalViewController:reply animated:YES];

The reply object gets created properly and the view is proper. Last line in above code segment calls some framework code which eventually calls the viewDidLoad method of the ReplyToViewController. Address of the reply object in the above code and the address of the object in viewDidLoad is not same.

Any idea where this new object is coming from? How do I debug? I also added init method the following method in ReplyToViewController hoping that it will get called and I can find who is creating this new object. But it does not stop in this method.

Any help will be greatly appreciated.

- (id) init
{ 
 /* first initialize the base class */
    self = [super init]; 
 return self;
}

// Following gets called from the 1st code segment.
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil 
{
    if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) 
 {
        // Custom initialization
    }

    return self;
}

- (void)viewDidLoad 
{
    [super viewDidLoad];
    NSLog(currentMessage.text]; // THIS returns nil and the program fails later in the code.
}
A: 

I'm sure this is unrelated, but I figure this:

NSLog(currentMessage.text];

Should be this:

NSLog(currentMessage.text);

Also, I've found that Analyzing (Cmd+Shift+A) my code always helps to track down potential memory leaks and prevent overzealous memory allocation.

David Foster
A: 

The most likely explanation is a reporting error.

Usually when people see a different address for an object it's because they used the wrong format descriptor in their log statements.

A common error is:

NSLog(@"Object address=%i", myObject); // any numerical formatter %d,%f...

... which produces a random number. You really want:

NSLog(@"Object address=%%qX",&myObject);

... which dumps the address in hex.

Another mistake is:

NSLog(@"Object address=%%qX",&[myObject description]); 

... which returns the address of the description string which changes every time.

There are others but you get the idea.

If you're using log statements, check the address in the debugger instead to confirm it's a different object.

Unrelated, but I would get rid of the class' initializer methods because they don't do anything but call the super. You might as well just let the compiler default to the super if you don't customize.

TechZen