UI Toolkit stops updating layouts inside the editor when an exception error happens

Hi, I’m making a window editor to show console logs in a more visual way using UI Toolkit, debug logs appear as buttons so you can click them.

The problem is that when an exception error happens (unrelated error that has nothing to do with UI, for example a “null reference exception” somewhere else in the code) the layout of those visual elements stop getting updated so it breaks the visual representation until I un-pause the editor.

Is there a way to update the layouts inside the editor even when an exception error happens?.

Show us your code. :wink:

I assume you are using an Application.LogCallback to get notified of logs?

Uhm … for what purpose?

You can select any log in the Console, and click any of the blue hyperlinks to open the source of the error (if available).

If you create a button for each log message, this will likely be highly inefficient to create a new button for each. Consider that sometimes you may be logging multiple lines per frame and thus you could easily create thousands of UITK buttons within a mere second.

Thanks for the reply.

Yes I specificaly use Application.logMessageReceivedThreaded to monitor what gets logged.

I create logs as buttons so I can click them to show their stack trace in the window. Also to show logs with different widths, and to nest logs below bigger nesting logs to, for example, show scope of methods and events.

Yes creating thousands of UITK buttons would be a problem, something to keep in mind.

Here is the abreviated code I use:

public void OnEnable()
{
    Application.logMessageReceivedThreaded += HandleLog;
...
}

private void HandleLog(string logString, string stackTrace, LogType type)
{
    logData newLogData = new logData();
    
    
    newLogData.logString = logString;
    newLogData.stackTrace = stackTrace;
    newLogData.type = type;
    
    logQueue.Add(newLogData);
}

     public void Update()
     {
         logData logEntry;
                  
          logEntry = logQueue.ElementAt(0);
          logQueue.Remove(logEntry);

          setupQueuedLog(logEntry);
     }


private void setupQueuedLog(logData _LogData)
{
   // To simplify things I cut a lot of code...
 Button newLogButton = new Button() ... 
newLogButton.AddToClassList("LogButton");
// then I put them in a row visualElement inside a scrollview:
targetLogRow.contentContainer.Add(newLogButton);
}

Curious. Since this would be an editor script, are you calling Update yourself or hooking into EditorApplication.update? This mustn’t be a MonoBehaviour is what I’m thinking.

Its not a MonoBehaviour, and I don’t call it myself, so this Update() is called once per frame automaticaly.

What’s the base class then? Because neither Editor nor EditorWindow implement Update(). Did you check that it is in fact getting called?

The main class is public class VisualConsoleWindow : EditorWindow, and Update() is getting called as it should. On the manual it says:

  • Update: Called once per frame to update the script’s logic.

Here (close to the beginning): Unity - Scripting API: EditorWindow

Thanks for correcting me. I did actually search the EditorWindow page for Update but perhaps I had looked under Editor twice. No idea how I missed that. :face_with_open_eyes_and_hand_over_mouth:

Can you check if Update keeps running after the exception? Perhaps the exception somehow stops the EditorWindow. It will also likely no longer Update if you close the EditorWindow.

The Update() keeps running, but the if I put Time.frameCount and I put it into a debug log, its stuck at 1 when an exception error happens. But it doesn’t stop the Update(), its just the frames that somehow gets stuck, or don’t get processed normaly or something.

When I close the editor window it no longer runs the Update().

Time works differently in the editor. It’s actually normal for Time.frameCount not to advance over several editor-Update calls.

Try logging the EditorWindow’s OnEnable and OnDisable calls. Perhaps you register the callback repeatedly and that may break things.

The exception isn’t occuring in the EditorWindow script, or in code called by it?

I did put logs everywhere but everything seems correct, nothing gets called more than it should, everything works fine.

The problem is when I provoke an exception error outside of the custom UI Toolkit editor window, it seems to me that Unity interrupts layout updates, but I cannot find a way to overcome that, I really need those layout updates in the editor.