Instanced UI not begin shown

I've upgraded from Unity 2017.01f1 to 2017.02b2 and now, instantiated UI is not shown until i add a new ui gameobject (any).

Ex:



The Canvas object is begin spawned like this:

Code (CSharp):

1.  
2. void Awake () {
3. GameObject menu = (GameObject)Instantiate(canvasPrefab);
4.             menu.AddComponent<EventSystem>();
5.             menu.AddComponent<StandaloneInputModule>();
6. }
7.  

CanvasPrefab is:


I've tried to fix it executing:

Code (CSharp):

1. Canvas.ForceUpdateCanvases();

Made no difference.
Manually disabling & reenabling the Canvas also works. But doing that ingame, doesn't

 

If this issue is important to you, I recommend to submit a bug-report following the advice in this document. Using the bug-reporter seems to be an important step, because that makes sure the report is in their bug-tracking pipeline and has to be processed at some point. Using the forum is often used to add to an already submitted bug-report a little more attention.

It's advantageous to attach a project to the bug-report that Unity can use to reproduce the issue and test their fix against. The easier an issue can be reproduced by QA, the more likely it is to get forwarded to a developer, who might or might not work on a bug-fix for that at some point.

After you submitted the bug-report, you receive a confirmation email with a Case number. Unity often asks us to post the Case number in the forum thread, which allows them to find that bug-report if they look at your post.

Following these steps will increase the chance that Unity is looking at your issue tremendously.

 

I also noticed this. This also affects UI that starts off disabled and is then show with gameObject.SetActive(true). Doesn't appear until you add something like w34edrtfg explained.

 

Right, ty for the reminder!

 

I have the same problem, that if a UI component starts off disabled when the scene starts then it wont show up after you re-enable it.

 

@ChrisJohnson you're right, i thought i had fixed it making another unity hack in the code but nope. Its just partially fixed.

 

Can confirm this bug also. UI elements that start disabled fail to draw when calling SetActive. Perhaps it's some issue with the canvas renderer not updating when it should?

 

We have the same bug.

 

I also have this, have no clue how to solve it... Any ideas, gratefully received as most of my front end involves turning on and off elements (the ones that work, I hide off screen and bring on when needed but cant do this for all of them)

 

yeah

2017.2.b3 ... broken (2017.2b2 ...broken didn't even see the point to trying it). what is even the point of these weekly releases if they are this broken unity? how are these sort of bugs even slipping past all these regression tests, why even bother releasing them honestly.

..anyway things like thise should show (not even any tests for this), like button presses that set other ugui panels states to active.. instead appear to be disabled (though scene hierarchy shows that their state is being toggled on/off) .. resizing the editor game window seems to trigger an update on these gameobjects and they show/hide properly, so you don't need to add anything.. though I guess maybe for a hacky workaround...

Unity might aswel start doing daily releases or minor patches for beta builds as there just no point to using beta builds waiting out a week for another build just to see if its worth using, because of bugs like these (not even ones you can avoid hitting).. and given that it seems like final releases like 2017.1 aren't really fully polished releases, they have plenty of bugs, so I'm tied to trying out newer beta builds to get fixes for older bugs, while also getting these sort of complete regressive bugs in newer releases... catch 22


"Any ideas, gratefully received as most of my front end involves turning on and off elements (the ones that work, I hide off screen and bring on when needed but cant do this for all of them)"

...would just be doing workarounds for something that clearly broken from essential normal behavior.. rollback to earlier unity version if possible (they all seem to be various states of buggyness, I'll be going back to 2017.1 even though its broken aswel, il2cpp builds crashing among other issues, that appear to be fixed in 2017.2.b3)

 

Unity will most likely release weekly patches for the current 2017.1 build, as they did for older versions. See their release plan here.

There should be no need to use a beta build, if you're looking for bug-fixes only. Beta builds are often unstable to some point in time, due to new features that break things.

Patch releases do not introduce new features, just bug-fixes. Patch releases are often a good choice when looking for a more robust Unity build.

 

Well you're not telling me anything I don't already know.. Infact I don't even know why you posted the response, it avoids what I'm getting at. Which is for all Unity's blog posts about putting in place tests to prevent regressions in releases (ok maybe not that many posted blogs about it ) .. a bug like this shows up.. I just want to know they will put in place some tests to make sure it won't slip past so easily, that or improve the beta download page to show bugs that do show up on regressions tests are then made known to users and highlighted above the normal known issues that don't really have regression tests. Maybe this bug was seen and it was just an eh who uses ugui anyway, just chuck this thing out and fix it another week..

"There should be no need to use a beta build, if you're looking for bug-fixes only"

Not true, 2017.2 has fixes for the issues I was having.. no patches for 2017.1 yet, no point going to 5.6 either.... As I already said its catch 22..

Where only the latest beta builds get most the fixes and improvements on things sooner, especially for things that are on going in development ...at this point its really just about dodging the bad beta releases (but you still have to try them out cus you can't know every issue or forum thread is something that will effect your project).. And you can't just sit on an old build and backport the newer fixes/improvements you do want, probably be a full time job doing just that with unity's code base , so you are kind of forced into keeping upto date with newer builds whether you want to or not.

And new features and code changes that cause odd quirks and bugs that can be worked around or avoided during development that would not be easily tested for, is one thing that can't be helped and no blame for that, hopefully a patch would fix at a later date for that release without going to a beta releases.. however bugs like this one, you would think would show up immediately in testing on newer build releases as an regression to expected behavior, and I don't see it as anything that was listed as a 'known' bug in the b3 notes that would be easily noticeable by users that would let them know.. "oh no point in using this build then" because that's for sure going to cause annoyance and not be easily ignored for continued development/testing.

 

If you are looking for a clear answer on if you should or should not use beta here it is:

1. Unity uses the latest beta as the main place to discover and fix bugs, provide feedback and so on but...

2. these bugs fixes are very efficiently backported with proper QA for main releases and...

3. ...beta will often have code that's unfinished. This alone is reason you shouldn't be using beta for important projects, regardless of bug fixes. This will nearly guarantee the beta will have a higher amount of total bugs.

There's not much QA applied to beta. It's really development in progress. It's bleeding edge. Do you want that risk? if so use beta.

 

Nope. You're fixing one thing and inviting a bunch of totally untested code in to ruin everything else. That's not catch 22, that's pointless risk because you can't wait a couple of weeks.

 

I'm not, and never was.

Do I want to use 2017.1 with broken behavior, bugs and build crashing.. when its fixed in 2017.2 right now? except the last 2beta releases for it that have been thrown out with pretty bad regressions to expected behavior. Can't be helped perhaps? Maybe so, but I'm still gonna question the intention of releasing weekly beta's that have what look to me as such obvious regressions that should have automated tests and perhaps that information should be made public on the beta download page, so you know a weekly beta might be a minefield of bugs that have failed pre-existing tests... you can't expect people to bother with testing newer builds with that sort of pure indifference to wasting people's time. And then trying to make out those people shouldn't be using the beta builds either when Unity is pretty much forcing users into this sort of releasing approach. When nothing in old builds is really ever finished feature complete wise, polished and bug free.

It is still a catch 22.. though beta testing these sort of releases may indeed a pointless risk not even worth bothering with, if not even basic QA and regression testing for pretty common usage cases is not even applied before its thrown out for public testing. Which is the really the entire point of my posts on this thread, whether that improves or not will most likely see less people bothering.

And yet if people don't bother testing this stuff with their projects then how can you expect weeks to go by with more bugs being found and fixed with future final releases. When less people testing, will directly mean less steps to reproduce and less projects to show said issues being reported etc. Oh just wait a couple of weeks you say, right... and then a couple more after that, for bugs for that are reported in the final releases then, instead of sooner. Wow jeez

As I said before ..."at this point its really just about dodging the bad beta releases" ...and that still hasn't changed, not exactly going to be testing much with builds that broken.

 

Alright but that's not going to change Unity's behaviour so you'll have to look at sticking with a stable build and not upgrading at the earliest opportunity to create sanity for yourself.

Your stance on "dodging the bad beta releases" is probably something that's exclusive to you, there's no way Unity or anyone else would recommend it.

If you are experiencing less stability on final public releases, then that is Unity's fault, and Unity will need to be more careful. But it doesn't change the fact that public final releases should always be the most stable. If they are not then Unity needs to improve, it's that simple.

You can't keep using betas to fix bugs. That makes no sense for anyone and should just be a one off for you.

 

The basic workaround is to always start with your UI in the scene and enabled, then disable it at the end of the frame.

Code (CSharp):

1.      
2.     public void ShowThing() // This could be Start() or when enabling a GO that has UI that is supposed to start off.
3.     {
4.         StartCoroutine(InitialSetupHack());
5.     }
6.  
7.     private IEnumerator InitialSetupHack() // You can't just make Start an IEnumerator, that fails.
8.     {
9.         yield return new WaitForEndOfFrame();
10.         someView.SetActive(false);
11.         someOtherView.SetActive(false);
12.     }
13.  

 

Oh, thanks for this. I thought I was going mad. Glad to see it wasn't me that broke my menu system.

 

Well its still broken in 2017.2.b4

I'm using 2017.1f3 until they have patches for that to use.. though like I said before things that I care about are broken in 2017.1 are fixed in 2017.2 right now ..however this bug is a no go for using 2017.2 ...not even with an exiting project.

Maybe, though I doubt it.

Depends where you are with a project, how its built, how much of its tied into unity stuff like prefabs, animation setup, new features that aren't complete etc ...and ton of other things.. for me yeah I'll stay on a beta build that has some new stuff to use if it isn't apparently buggy in areas I'm using, I can always merge the newer updates to a project with an older backup and fall back to using an earlier unity release seeing as its mostly code changes anyway, I'm sure I will settle down on build like 2017.1f patch blah or 2017.2f . Maybe I would have stayed with 5.6 if the project was tied into areas that I wouldn't trust jumping onto newer releases as much.... still not really what I was getting at in the posts here, and this is just engaging on stuff I'm well aware of, and the general consensus of those who don't bother with beta's and don't like anyone complaining about it or how some bugs should have regression tests for such common use areas like this... and beta users supplied with said notice of those areas being broken, it just wastes people's time (because yknow I have to wonder if in the future unity would still release a weekly beta even if it didn't even start up properly at this point! ) ...5.6 is probably the last stable unity build that hasn't got so many moving and unfinished parts in it (well it has but you wouldn't even bother using those areas, where as 2017.1 you could be more inclined to use those areas, seeing as its finished and kicked out of beta).. but its not entirely stable even in its final release...infact 2017.1f3 still has the problem of not even starting up and giving you access to opening your projects, unless you have internet connection working and that bug was meant to be fixed for f3.. fixed in otherwise buggy 2017.2 though go figure)

Well I could say the same thing about unity can't just keep releasing unfinished releases as final when they are clearly still wip... and where most the fixes and progress just moves onto the next major build, which definitely sums up 2017.1 > 2017.2 imo.

If unity stated this bug would likely not be fixed for another month or more I'd probably go ahead and start implementing it and wrap its usage in a compiler symbol for when they do finally fix it.. but as it stands would be a waste of time they might fix this issue next week right?

 

Is there a bug reported that I could track please? Could someone post it accordingly?

 

Finally got around to send a bug report
Case 935722

 

Found a couple of duplicate reports of the issue. Looks like there is a fix in review: 922641
edit: Although, that was from 2017.2.0b1

Duplicate here: 934190

 

In following up, fix is in flight and should be in b6.

 

Whatever you want dude, I wanted to work and test my project now so needed to do it, looks like it'll be another week at least anyway. I should also mention that b4 crashes when you use WaitEndOfFrame() so you should WaitForSeconds() instead.

Awesome work!

 

Yeah the only disappointing thing about this news of the fix being in b6, is that b5 wasn't released last week.

 

Seems fixed in b6