Best practices? - OnGUI and coroutines

Unity Engine
1

This question relates to GUI elements and animation of those elements.

It is my understanding that from a “best practices” standpoint:

  • OnGUI() should be used primarily for drawing UI elements using variables (which are set/modified elsewhere…see next)
  • Above-mentioned variables should be manipulated/modified in Update() or functions and coroutines called from Update() (for animating)

The above sounds great, makes sense. However, here is my question:

Are there potential issues or is it bad-form to call coroutines from OnGUI? (or within functions called by OnGUI() )

(Or is my understanding of best practices incorrect?)

2

Not really. You might have a function called when someone clicks on a button, for example.

You’d just want to keep them computationally simple. You wouldn’t want to recalculate the relative positions of 100 objects multiple times per frame, for example.

3

OK, thanks. One point of reference was HiggyB’s post HERE…

Does not explicitly say NOT to call a coroutine from OnGUI, but the implication was that above is the recommended method.

4

Well for that, yes. After all, it’s a computation that you want tied to frames-per-second, so it needs to be done in Update.

5

Yeah, you don’t want to call coroutines from within an OnGUI function, just the same as not calling them in Start or Update. The reason here is that OnGUI is called by our engine multiple times per frame in order to do painting and event detection, etc. Use of coroutines inside of an OnGUI call would break that and so it’s not allowed.

As GargerathSunman noted, and as the quote from me you cited, if you need to use coroutines as part of your GUI development then have those in some sort of a helper function instead. In the case of the quote you cited from me, I was referring to animating of UI elements in specific (IIRC) and so the animation of various properties is handled outside of OnGUI, whereas OnGUI just used the variables with whatever value they have. In other cases you might have a button that when clicked introduces some behavior, but here yet again a helper function is the way to go if that behavior involved a coroutine.

Make sense? If not then keep asking and we’ll make sure it does! :slight_smile:

6

Thanks for the very informative answers guys. Not calling co-routines from OnGUI makes sense. But not from Start or Update? I’m not clear on the reason for that exactly? Even the docs (third example) shows using StartCoroutine from Start…??

As for “helper functions”, I’ve seen that mentioned a number of times in this context, but I could not find any examples. So I’ve assumed those are simply a function outside of Start or Update, which is called by Start or Update, which then calls StartCoroutine, yes? But I fail to see how that effectively differs? (versus calling StartCoroutine directly from Start or Update)

7

I guess HiggyB actually meant Update and FixedUpdate

The periodically called “callbacks” have the coroutines disabled for the same reason as ongui: you don’t want hundreds of parallel coroutines related to a function call that was finished long ago

8

No, I meant what i wrote. You don’t want your Start or Update functions to contain coroutines, period. The example cited from the docs initiates a coroutine that exists in another function. The yield is not contained inside of Start so calling StartCoroutine initiates a separate function to act as the coroutine. Start is just as invalid a place to contain coroutines as Update, LateUpdate, FixedUpdate, OnGUI.

9

Thank u all in advance and sorry to bump such an old question.

What do you mean by a helper function?

@ the mo I have:

void OnGUI() {

				
		if(GUI.Button(new Rect(unitW, unitH, 14*unitW, 2*unitH), theAnswersEng[0], answerStyle)) {

			StartCoroutine(gameMode(2f));
		}

    }	
	
	 IEnumerator gameMode(float waitTime) {
		Destroy(gameObject, 1);
        yield return new WaitForSeconds(waitTime);
		Debug.Log("AMHERE");
		GameObject.Find("GUI/Controls").SendMessage("turnChildrenOn", SendMessageOptions.DontRequireReceiver);
    }

I do get to Destroy(gameObject, 1); but I dont reach Debug.Log(“AMHERE”);

So, a helper function would be?

10

I’ve got the funny feeling that I’m making it worse by adding the Destroy(gameObject, 1);
If i do this instead, it works

	 IEnumerator gameMode(float waitTime) {
        yield return new WaitForSeconds(waitTime);
		Destroy(gameObject);
		GameObject.Find("GUI/Controls").SendMessage("turnChildrenOn", SendMessageOptions.DontRequireReceiver);
    }

But is it ok to do it that way?

11

Calling Destroy(gameObject) will destroy the gameobject containing this script, so anything after Destroy(gameObject) won’t execute

12

I’m sure he has figured it out or given up in the past six years.

We discourage reviving threads this old. So much information in this thread is out of date.

Either way, your information is incorrect. Destruction happens at the end of the frame, not immediately. So an executing script will still continue to run after the destroy call. Coroutines on the other hand, will stop at the next yield statement.