Bug EditorUtility.DisplayProgressBar not showing up anymore

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: https://docs.unity3d.com/ScriptReference/EditorUtility.DisplayProgressBar.html 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

 

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)

 

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

 

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?

 

Voting time: https://issuetracker.unity3d.com/is...-invisible-slash-not-showing-anything-anymore

 

I just changed it to the new Progess() mechanism. This is so much cooler!! And looks way more professional. Thanks for providing this.

 

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.

 

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?

 

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.

@Aras

 

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.

 

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.

 

I think it's been long enough to where this might be the intended functionality and isn't planned to be addressed. I've added in a request for the functionality to be added back in here:

https://forum.unity.com/threads/fea...rform-a-blocking-operation-in-editor.1009222/

 

The forums are not a good avenue for feedback, it's up to luck if the right Unity developer checks it and many times they don't. The encouraged way is to file bug reports for everything, this gets your feedback into Unity's system and makes sure it's looked at. All of you having a specific use-case should report a bug with it.

Not in my experience. You just call

EditorUtility.DisplayProgressBar

periodically in your blocking code and the progress bar gets updated fine.

 

@Adrian is there a ticketing system or site somewhere? I looked around and every link eventually pushed me to a forum post that said feature requests should be added in as forum posts.

Also regarding your experience what do you mean by "in your blocking code"? Do you just run a while loop and create a stall in the program?

 

@moose0847 AFAIK there are no Unity people hired to collect feedback and reports from the forums. The devs that do check the forum do it voluntarily and often irregularly. There's the public issue tracker but that's mostly for checking the state of current issues. The actual issue tracker is private and you can only submit bug from the editor. The bug reporter is maybe not the right avenue for requesting new features but in this case, where they changed an existing feature and you can create a repo case illustrating how you want to use it and why it's not working, I think it has the most prospects.

I'm using the progress bar when doing batch asset processing that's blocking the editor and update the progress bar in-between. The article @Peter77 posted earlier shows good examples of how it's supposed to be used.

 

Sorry to necro that post, but did anyone ever found a solution?

 

No. We need to over engineer our in-house tools to consider all sorts of different editor user interruptions (asset creation/deletion, play mode enter/exit, assembly reloading, your custom editor window being closed by user, etc). Aras says to use the "background operations" feature instead - because I guess its the *proper* way?

Just let me block the damn editor.

 

Agree... I just try using an Editor Windows, it work... but it update about once every 15 seconds, while the Console keep editing non stop... so sad that something that simple, is so complicated... thank for feedback

 

I also try the "progress" class, and see no way to make it appear visually when call in editor by the menu.

Unity still use the ProgressBar or a similar class


Why can't we have access to it?

 

i have the same problem, still.
using 2021.3.5f1 and inside an OnGUI() i am having some blocking code running for 10+ seconds
it is 3 for() loops each, taking about 4 seconds, and inside it i call EditorUtility.DisplayProgressBar("Light Probe Producer", "checking grid for possible sizes ", x / size_x);

the window is shown, with the text from the initial call, but then no progress bar visual is drawn - nor ever updated.
even if i take mypercentage and add it to the string that never changes from the first showing.

i guess this is what Aras meant in this comment above, but with Progress class it also doesnt work for me.
any ideas how to solve this?

 

DisplayProgressBar is utterly broken for me in 2020 and up (currently using 2021.3.0f, but tried 2020 as well), compared to how it used to work. It may appear, it may not, if it does appear it may update the progress bar, or it may be frozen until it goes away.

In 2019 and older versions is consistently appeared and it was always updated just fine. The new Progress class won't work for me since I'm doing a blocking operation and Progress must be called inside a coroutine, returning control to the editor with yield. I want to block the editor while showing a progress bar.

This is the code I'm using for the ProgressBar:

Code (CSharp):

1.  
2. IEnumerator coroutine = SomeCoroutine();
3. CoroutineJob.ProgressInfo progressInfo;
4.  
5. while (coroutine.MoveNext())
6. {
7.        var progressInfo = coroutine.Current as CoroutineJob.ProgressInfo;
8.        EditorUtility.DisplayProgressBar(title, progressInfo.userReadableInfo, progressInfo.progress);
9. }
10.  
11. EditorUtility.ClearProgressBar();
12.  

The ProgressInfo class is just the return type of my coroutine, which I'm manually advancing inside a while loop and calling DisplayProgressBar inside this loop. This is the intended use case I assume, for it to be called inside a tight loop?

If so, this has worked fine in all previous versions but is completely broken in >2020. Any ideas?