Input.GetMouseButtonDown(0) called twice in OnGUI()

Is there any strange behaviour that I should know about?

        private void OnGUI()
        {
            if (Input.GetMouseButtonDown(0))
                Debug.Log("Click");
        }

Simple as that.
Called twice always.
Only one of these scripts in the scene
Don’t know what the hell is going on :hushed:

As per the docs, it’s expected “Your OnGUI implementation might be called several times per frame (one call per event)”.

Another similar thread that might help here . You’ll get different events for each call as per.

Also, FYI there’s a dedicated forum for IMGUI here.

Also: this appears to be an attempt to implement a new OnGUI-based UI in runtime code. Is that correct?

There is no reason to be creating new OnGUI interfaces for runtime right now. There is even less reason to be learning how to create new OnGUI interface for runtime, which given this question seems to be a thing you’re just learning. It’s been obsolete for years; it acts unusually, is difficult to design and maintain, and performs like crap. It’s currently really only supported in runtime for legacy UI that was written long ago.

Learn to use the Canvas-based system instead.

Yep, we only use this in the editor runtime to display the behaviour of native webview integrations (which are only available on device). So this will not compile into production code, no worries! I just wanted to make sure there is a way for the other developers to access the underlying URL by clicking the dummy Web-View canvas. However it’s opening twice now. ¯_(ツ)_/¯

I don’t understand why this would be called multiple times per event, or even which events are ment. And I do not have the time to dig in all the querks, I’ll probably just implement a dirty hack then to prevent this :stuck_out_tongue:

There’s one or more calls for input events, there’s a call for rendering, and often there’s one or more calls for layouting if the GUILayout functions are used. If you’re thinking that’s a lot of calls… yes, that’s a part of why it performs so terribly.

There’s a variable Event.current which is set during OnGUI, and you can get information about what’s happening this run-through. Event.current.type for example will tell you why it’s being called, so if type is MouseDown, you know you’ve received a click. This is how you’re supposed to check for input in OnGUI.

1 Like

I’ve written an IMGUI crash course some years ago that should cover most things there is to know about the system. As mentioned at the top of the answer Unity Answers has somehow messed up the markdown rendering some years ago and hasn’t managed to fix it ^^. There’s a mirror on my github which displays markdown properly.

As StarManta said if you want to check a key down event inside OnGUI you would have to do

Event e = Event.current;
if (e.type = EventType.MouseDown && e.button == 0)
{
  
}

The Input class should not be used at all inside OnGUI.

ps: The IMGUI system ist not nearly as bad as some try to portrait it. Yes it usually results in a relatively high number of drawcalls. That’s of course because it’s an immediate mode GUI system. So during the Repaint event you can directly draw to the screen. The bad reputation came mainly from the performance on legacy mobile devices back then. On modern devices a relatively moderate UI would not really be that much of an issue. Of course if you’re already at the performance limit on such weak devices you want every improvement you can get.

However the different UI systems actually have different strengths and weaknesses. While the uGUI (UnityEngine.UI) has a nice WYSIWYG approach it’s relatively easy to build static UIs. Anything dynamic can quickly become quite painful. If you have a lot of changing or animated elements the usability and also performance of the UI system drops as well. Also having really long scroll lists is quite difficult with the new UI system. You either have to instantiate all the elements at the beginning, do clever dynamical reloading or object pooling as the user scrolls. With the immediate mode GUI this is rather trivial. I’ve done this for example in my UVViewer editor window for the triangle / vertex list. It has no issues displaying a list of 10k or 20M triangles as only the ones visible will be rendered.

I really don’t want to suggest that anyone should use the old IMGUI system in production, I just wanted to point out it’s not as bad as some people suggest. For example, this old demo that should visualize how FixedUpdate works is essentially an empty scene with just a single script and everything you see is done in OnGUI.