Is this a known bug? I have an editor script which worked just fine in 2019.4 and in 2020.1.b16 the progressbad is not displayed anymore in the GUI.
Yes just encountering the same problem. I present a progress bar when my editor tool sends a webrequest, to block user input⌠but this doesnât work anymore. I am a little behind, on b7.
I tried the example here: Unity - Scripting API: EditorUtility.DisplayProgressBar just in case something was wrong on my end, but it does not work either.
From release notes:
Hmm. This is strange. Like I mentioned, maybe its not the a good use of the progress bar⌠but if any editor tools depended on the progress bar as a way of preventing users input until a process is complete, there is a small window of time where those scripts might run into some problems. We were also using it as a way of showing the user that their action was acknowledged and was being worked on right now.
I had opened a bug for it yesterday: 1264191
3 Likes
That would be the case only if that editor tool runs in parallel, like on another thread?
I would assume the change still blocks the main thread for those first 0.3s, because itâs very simple to implement it that way, but itâs not blocking anymore?
I find this change very interesting, because I wrote a âReporting UI progress properly in Unityâ article a few years ago and it seems itâs exactly what they implemented now.
http://web.archive.org/web/20160804220745/http://console-dev.de/?p=447
Yeah, that is the case for me (Web requests, file uploads, etc)
2 Likes
I also use it for file upload that runs async. The state is all shown correctly (eg buttons disabled) just the progress does not pop up anymore as it did in 2019.3
1 Like
Just educated guessing, but @Aras could this be a potential side-effect of what I think your team has done with the nice progress popup that now shows more info while Unity is busy?
Hmm yeah so the issue is that this API was only ever mean to be used for âblockingâ operations, i.e. where the control never returns to Unity for the duration of the progress bar. Doing it from inside OnGUI does return control to Unity though, at which point (due to the new âbusyâ progress bar in 2020.1) the code goes âha! Iâm no longer not-responding! no need to keep on showing the progress barâ
For âbackgroundâ operations in the editor, the Unity - Scripting API: Progress class is what you most likely want to use.
2 Likes
I just changed it to the new Progess() mechanism. This is so much cooler!! And looks way more professional. Thanks for providing this.
2 Likes
Is there any existing documentation on this busy progress bar? Iâm seeing a similar issue where I need to perform a blocking operation in the editor, but EditorUtility.DisplayProgressBar isnât drawing anything.
@Aras , all the background operations gets canceled when the editor enters play mode. What to do if a file upload operation needs to be blocking until it is running? (Like not get auto cancelled by doing something else in the editor)
Anyone? Please tell me if this is possible or not. The new background process in 2020 is good, but if by mistake the user hits the play button in the editor, the background process shuts down. How can I work around this to ask the user to wait until the process completes or keep the process running in background?
I am not able to find much information on this in the Unity Docs.
1 Like
In a blocking call, we canât update the progress of the current progress bar, but if we use EditorCoroutines, we lose the ability to block the user from performing potentially conflicting operations while the task is being performed. Any way to do a blocking task while also updating the progress bar?
1 Like
Yeah I need to block the editor while I am doing some work. I have an async method that does a bunch of stuff over the course of a few frames in the editor (web requests, configuring some services). during this time I want to prevent the user from clicking around the editor, so I want to display the progress bar. I want it shown when I âdisplay progress barâ, and I want it gone only when I call âclear progress barâ.
The new progress bar changes are confusing. The progress bar is trying to be too clever, and not allowing me to drive it the way I want. I want to drive the blocking progress bar popup window myself fully and completely.
âEditorUtility.DisplayProgressBarâ is no longer a command but a suggestion, and this kinda sucks.
bump I guess. I need a way to block the editor from input until I am done doing what I need to do. otherwise I need to write a lot of code to work around the fact that the user might perform some action (like hitting play) and interrupt what I am trying to do.
I understand this is a heavy handed solution (to block the entire editor), but this is for internal tools and we are a small team. It saves us a lot of work to just be able to suspend the editor until our work is done.
Just curious: if you want to block the entire editor anyway, why use an async method? If you want to be heavy handed, do it on the main thread and block the editor.
Because you want to show a progress bar if the task takes a while. Currently the progress bar wonât update if you do a blocking call.
1 Like
In my case, I have a few Async methods that I need to chain together. Async/await is really easy to work with. I have an Async method to perform some git operations, another to launch a local nodejs server and wait for it to start listening so I can test locally, and another case where I want to perform a few http client Async web requests. Itâs just easier and cleaner to write Async/await code.
Problem is the editor isnât really frozen when I am doing these things and the progress bar Api refuses to let me block input like it used to.
1 Like