Author Topic: OnClick not firing in iPad mini?  (Read 3760 times)

catlard

  • Newbie
  • *
  • Thank You
  • -Given: 7
  • -Receive: 0
  • Posts: 24
    • View Profile
OnClick not firing in iPad mini?
« on: July 11, 2014, 07:30:28 PM »
Hi, everybody!

I'm having a small, but extremely resilient issue -- I have a certain button which refuses to be pushed and fire its OnClick events. It seems like it should be related to the code in the OnClick function, I have some test cases which seem to rule this out:

1. The same code works on iPad and Android, but not iPad Mini.
2. I have tried duplicating the button right next to it, and simply adding the script with the onclick functionality and/or adding it to the delegates list in the inspector. The new button, exactly the same as the old, does not function. The old one still functions.
3. The debug option on the UICamera notes that a the button has been touched, and the button visually reacts to touches (slightly tweens color), but does not fire its onclick. I have placed print statements around it.

My dev environment is a Mac OSX 10.9.3, with Unity 4.3.4f1. I am building with iOS pro, and nGUI version 3.5.7.

Is this possible? Am I on crazy pills?  :'( How can I prove this is happening? Here is the code that I am trying to call in my OnClick function:

  1. public void OnClick() {
  2.                 print ("Fired onclick.");
  3.                 _infoView.CalenderButtonClicked ();
  4.         }

and here is the function that is called as a result of that:
  1. public void CalenderButtonClicked() {
  2.  
  3. //THIS CODE WILL NEVER FIRE.
  4.                 if (DeviceManager.instance._currentDevice == Device_Type.androidPhone || DeviceManager.instance._currentDevice == Device_Type.androidTablet) {
  5.                         DeviceManager.instance.ConfirmLeavingApp("Leave the application to put the wedding date on your phone's calendar? This app might have to reload.", SetCalendarCallbackAndroid, DoNothing);
  6.  
  7.  
  8.                 } else if(DeviceManager.instance._currentDevice == Device_Type.iPadDevice || DeviceManager.instance._currentDevice == Device_Type.iPhoneDevice) {
  9.                         print ("Hello"); //
  10.                         DeviceManager.instance.SetCalendarDate(_weddingInfo._calendarEventTitle, _weddingInfo._startDate, _weddingInfo._endDate);
  11.  
  12.  
  13.                 }
  14.  
  15.         }

I do have more than one UIRoot and UICamera activated at one time in the scene.

Ahhhhh! Oh no.

« Last Edit: July 11, 2014, 07:46:56 PM by catlard »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: OnClick not firing in iPad mini?
« Reply #1 on: July 11, 2014, 09:26:12 PM »
More than one UIRoot... why do you need more than one? I can maybe understand more than one if you have different UI types -- 3D and 2D. As long as they are on different layers, that's fine. Anything else though... and you are bound to run into issues when NGUI will try to find the correct camera responsible for drawing layer XYZ used by the widget.

Any particular reason why you have the OnClick function like that? You can reference the CalendarButtonClicked function directly from your UIButton's On Click Notification section in inspector. OnClick is a built-in notification in NGUI, sent to any collider.

If the "Fired onclick" message is showing up, but the CalendarButtonClicked isn't, then the issue is in your code. Likely "_infoView" is either null (which will give you a null exception), or you have it set to something you don't expect. If it's a singleton, then you may even have more than one.

catlard

  • Newbie
  • *
  • Thank You
  • -Given: 7
  • -Receive: 0
  • Posts: 24
    • View Profile
Re: OnClick not firing in iPad mini?
« Reply #2 on: July 14, 2014, 04:27:05 AM »
Hi, ArenMook!

Thanks again, as always, for your quick response. I'll check this out tomorrow, since I don't have a 4.5 mobile pro license on my current computer. You may be right about the singleton or layering issue. I'm pretty sure _infoView is not null, otherwise it'd show an error message in my on-device-console-message-displaying doohickey.

I use more than one UIRoot per scene because I like to have my UI prefabs as standalone objects -- when I am building a scene programmatically or in the editor, and I drop in (or instantiate) my prefabs, my initial instinct (though perhaps not the right one) has been to store seperate "sections" of my scene under under seperate cameras and UIRoots, because I think of UIRoots and Cameras as working together on a one-to-one ratio. I don't like having multiple cameras in the same location, looking at the same things, if I can avoid it -- it just creates greater margin for error, in my mind. I prefer to have one UI way over here at 100,0,0, and one UI way over there, at 200,0,0. Meanwhile, my Main camera lives at 0,0,0. The reason I feel that way, I guess, is because of the way I think about cameras and locations. I guess it's just what I did without thinking/knowing better. Is it less than optimal, in your opinion?

I fire the OnClick function in scripts on objects (instead of in the editor) for a few reasons:

1) Because I often like to fire OnClick events with custom object types as arguments, and the inspector onclick stuff doesn't seem to allow for that. Don't get me wrong, the inspector OnClick stuff is great for quick and dirty, or just simple stuff, particularly when I was just starting out with nGUI, but I find that I prefer to use programmatic onclick calls 100% of the time, since I know it can handle 100% of my use cases.

2) When I go back through code, I don't want to have to look in the inspector AND in the code for some onclick call, and remember which one I used. I always just check the code.

3) When I'm changing an onclick call in another scene, it doesn't really help to have to go to that scene to change what a button does (if the object with the onclick function isn't on a prefab). I'd prefer to change it in my code -- that way I can fix something without switching between the editor and the code so often.

You are my hero,

Simon