-3

Class1.m

    #import Class2.h

    Class2* test = [[Class2 alloc] init];

    UIButton* button1 = [UIButton buttonWithType:UIButtonTypeRoundedRect];
    [dropButton addTarget:test action:@selector(actionPressed:) forControlEvents:UIControlEventTouchDown];

Class2.m

    #import Class1.h

    -(UIButton *)actionPressed:(UIButton *)buttonPressed{
       NSLog(@"Test");
       return buttonPressed;
    }

The response function does not work and I am not sure why. App crashing during simulation. Advise on a fix would be greatly appreciated.

Guido Hendriks
  • 5,706
  • 3
  • 27
  • 37
Mike D
  • 25
  • 1
  • 4
  • 1
    What is the crash you are getting? And please share all code not just a little snippet, you are creating your button in code so where do you add it to the subview? Where do you set the frame. And finally why are you returning the `buttonPressed`? You already have the button. – Popeye Jan 17 '14 at 09:06
  • If you're just setting `test` to a local variable, it may be being deallocated before your action is triggered. – James Frost Jan 17 '14 at 09:30
  • I am getting the error: Undeclared selector 'buttonPressed'. It is most likely the local variable declaration as you suggested. How would i change this to an instance variable? Would it be an instance of Class 1 or Class 2? – Mike D Jan 19 '14 at 20:05

1 Answers1

-1

Seems like test is a local variable. Without the actual errors it's hard to tell, but that's probably where it goes wrong. You should change it to an instance variable, in that case the Class2 object would be retained until deallocation of Class1.

Guido Hendriks
  • 5,706
  • 3
  • 27
  • 37
  • Better would be to change it to a property which would create the ivar in the background. – Popeye Jan 17 '14 at 10:31
  • As far as I can see, there isn't a single advantage in this case. But probably couldn't hurt either. – Guido Hendriks Jan 17 '14 at 12:26
  • I have had a play and if you do it as a stand a lone `ivar` it will pass nil in. If you do it as a property which auto generates the `ivar` as well as the getters and setters it will work. Also the convention is these days that you wouldn't have any `ivars` in the `@interface` in the `.h` file any more, you would replace these with properties and if you needed any `ivars` these would be done in the implementation due to `ivars` these days should be private to the class and not default or public. – Popeye Jan 17 '14 at 12:42
  • Do a simple google search you will find this all over the place. Including Stackoverflow, discussions.apple.com, Apple documentation (Recommends using property over ivar as it now auto creates the ivar and sticks to the KVO model) blogs. Not hard to find. Also included in iTunesU courses. – Popeye Jan 17 '14 at 12:52
  • First hit on StackOverflow: http://stackoverflow.com/questions/7836182/property-vs-ivar-in-times-of-arc. Without knowing the precise use of this question, this might apply on it. – Guido Hendriks Jan 17 '14 at 14:08
  • Check the date of the answer `Nov 30 11` things have changed since then, back then it would have been best to do the `ivar` as well as the property but xcode has become more intelligent now, even though that does actually back me up with putting it in the implementation file instead of the interface. – Popeye Jan 17 '14 at 14:16