So I recently encountered a bug in my code that lead to me wondering whytf OnEnable wasn’t being called yet the OnDisable’d’ part of the code was working fine, the subtle difference I wasn’t noticing at the time was that I had typed void OnEnabled(){ …code…} …and so nothing inside of it was being run as Unity only calls OnEnable() …
After realizing this I gave my entire projects folder a search for all .cs files for OnEnabled and OnDisabled… turned out I had a few more occurrences of this oversight… 2scripts with OnEnabled, and one with OnDisabled… where funnily enough the code inside that turned out to cause more errors when it did get run with the amended function name
Anyone else done this mistake?
Anyway I can’t help but feel that Unity probably should give a warning message on detecting functions named OnEnabled() and OnDisabled() on compile…yeh its not correct english, but those suffix’d names are often used in other frameworks for functions… its also just so easy to make that naming mistake for those particular function names imo, especially when not directly testing the code written in them at the time to notice the code isn’t even being run
how would it ever be able to tell, you can quite happily create functions called whatever you like. Perhaps these were meant to be user created functions that the user was meaning to use, but then didn’t. Did you mean to create your own, did you mean to implement the ones that hook into the unity engine? compilers can’t know your intentions, they just mechanically check the syntax.
"compilers can’t know your intentions, they just mechanically check the syntax. "
Yeh… which is why I suggested a warning notice… it isn’t going to change anything, its just a reminder to the user that its detected a function call that is awfully similar to a known built in function that they might have been intending to use.
Don’t see what is hard about adding such a minor usability check to prevent such subtle mistakes.
The thing is, somebody else would be irritated if they actually used a method called OnDisabled… see the problem? We get the freedom to name our methods whatever we so choose, so we have to just “know” what to use in cases like this, rather than unity holding our hand…
I do see what your saying though, but it’s just unrealistic for the devs of unity to spend time they could be spending squashing bugs, or implementing new features on something as trivial as a small gotcha in method naming.
MonoBehaviour should define all of the Unity-messages as virtual methods - the compiler crashes if you try to do “public override void OnEnabled”. Unity were considering doing that breaking change when going from 4 to 5, but decided against it - I think that was the wrong choice.
There’s a lot of new users that are wondering why their “update” or “start” methods don’t work, which is the same problem.
it’s a two-edged sword, as i observed when creating a base class with all the unity callbacks tends to slow down things, as these virtual functions get reflected and registered into unitys internal callback lists, and are being called even when not overridden in a child class.
That would not be the case if they were defined as virtual by Unity. The implementation now is “add the behaviour to the Update list if it has defined Update”, so the only needed change would be “add the behaviour to the Update list if it has overriden Update”.
part of the code was working fine, the subtle difference I wasn’t noticing at the time was that I had typed void OnEnabled(){ …code…} …and so nothing inside of it was being run as Unity only calls OnEnable() …