Make Awake(), Start(), Update(),... protected virtual for inheritance

[Samhayne]

Hey, =)

I just stumbled over the fact that it's unnecessarily complicated to inherit
from a UIPanel due to it's Awake() method being private.

That's especially problematic as Awake() is Unity's substitute for a constructor.
=> inheriting classes can't initiate values/objects cleanly and it's even impossible to
add components on gameobject creation.

I strongly suggest opening this and other MonoBehaviour methods for overriding
by making them protected virtual.

As soon as you want to create really, really complex UIs you end up scripting
widgets and run into problems there.

[Cripple]

Why do you need to inherit from UIPanel ?

Also if you need to add behaviours to Widgets, just create a standalone MonoBehaviour with [RequireComponent()].

[ArenMook]

Yeeeah... UIPanel was not meant to be inherited from. It should be used as-is. Why would you want to inherit from it?

[Samhayne]

Because of the "is a" relation of self defined panels.
A Shop Panel is a Panel.
(where I also want to have access to all non-private Panel functionality from).

It's very weird OO to define that a Shop Panel "has a" panel.


Chose...

1. // Alternative A:
2. [RequireComponent (typeof (UIPanel))]
3. public class ShopPanelA : MonoBehaviour {
4.     private UIPanel panel;
5.  
6.     void Awake() {
7.         panel = GetComponent<UIPanel>();
8.         NGUITools.AddChild<ItemA>(this.gameObject);
9.         NGUITools.AddChild<ItemB>(this.gameObject);
10.         NGUITools.AddChild<ItemC>(this.gameObject);
11.     }
12. }
13.  
14.  
15. // Alternative B:
16. public class ShopPanelB : UIPanel {
17.     protected override void Awake() {
18.         base.Awake();
19.         NGUITools.AddChild<ItemA>(this.gameObject);
20.         NGUITools.AddChild<ItemB>(this.gameObject);
21.         NGUITools.AddChild<ItemC>(this.gameObject);
22.     }
23. }

[Cripple]

Hi,

Alternative A is better in this case, because you want to "ADD" a new behaviour to your panel, not change its behaviour. Inheritance is fine when you want to override something to change its behaviour.

[Nicki]

It seems to me that this stems from a misunderstanding about what a UIPanel actually is. It could be that the naming is misleading and should be called something akin to "DrawCallCollection".

A UIPanel is not a "panel" like a window or view, it's only the responsible for drawing the widgets inside its sub hierarchy, not for defining screen areas or anything like that, like a UIView would be in native ios development.

So your Shop Panel is not a UIPanel, it has a UIPanel. The two words panel just mean something different.

[Samhayne]

Hey Nicki, =)

True. That's the way how I understood UiPanel.
Just starting to look deeper into Ngui and took for granted that UiPanel would be meant to create panels from.
That's indeed a bit misleading...

Okay. You are right. I am wrong. =)