Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Instanced UI not begin shown

Discussion in '2017.2 Beta' started by w34edrtfg, Jul 8, 2017.

  1. w34edrtfg

    w34edrtfg

    Joined:
    Nov 23, 2014
    Posts:
    72
    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
     
    Last edited: Jul 8, 2017
  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,471
    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.
     
  3. Enrico-Monese

    Enrico-Monese

    Joined:
    Dec 18, 2015
    Posts:
    77
    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.
     
  4. w34edrtfg

    w34edrtfg

    Joined:
    Nov 23, 2014
    Posts:
    72
    Right, ty for the reminder!
     
  5. ChrisJohnson

    ChrisJohnson

    Joined:
    Feb 20, 2013
    Posts:
    64
    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.
     
    Last edited: Jul 10, 2017
  6. w34edrtfg

    w34edrtfg

    Joined:
    Nov 23, 2014
    Posts:
    72
    @ChrisJohnson you're right, i thought i had fixed it making another unity hack in the code but nope. Its just partially fixed.
     
    ChrisJohnson likes this.
  7. MassiveTchnologies

    MassiveTchnologies

    Joined:
    Jul 5, 2016
    Posts:
    87
    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?
     
  8. Tuni

    Tuni

    Joined:
    May 24, 2013
    Posts:
    74
    We have the same bug.
     
  9. Gwom

    Gwom

    Joined:
    Aug 5, 2015
    Posts:
    21
    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)
     
  10. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    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)
     
  11. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,471
    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.
     
    firejerm and hippocoder like this.
  12. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    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 :D , 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.
     
    Last edited: Jul 15, 2017
  13. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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.
     
  14. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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.
     
  15. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    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.
     
  16. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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.
     
  17. nhold

    nhold

    Joined:
    May 2, 2017
    Posts:
    50
    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.  
     
    Last edited: Jul 21, 2017
    Enrico-Monese and plauk like this.
  18. plauk

    plauk

    Joined:
    Jun 4, 2013
    Posts:
    10
    Oh, thanks for this. I thought I was going mad. Glad to see it wasn't me that broke my menu system.
     
  19. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    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?
     
  20. Alex-Lian

    Alex-Lian

    Guest

    Is there a bug reported that I could track please? Could someone post it accordingly?
     
  21. Enrico-Monese

    Enrico-Monese

    Joined:
    Dec 18, 2015
    Posts:
    77
    Finally got around to send a bug report
    Case 935722
     
    Last edited: Jul 27, 2017
    MassiveTchnologies likes this.
  22. plauk

    plauk

    Joined:
    Jun 4, 2013
    Posts:
    10
    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
     
    Enrico-Monese likes this.
  23. Alex-Lian

    Alex-Lian

    Guest

    In following up, fix is in flight and should be in b6.
     
    plauk and Player7 like this.
  24. nhold

    nhold

    Joined:
    May 2, 2017
    Posts:
    50
    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!
     
    Player7 likes this.
  25. Player7

    Player7

    Joined:
    Oct 21, 2015
    Posts:
    1,533
    Yeah the only disappointing thing about this news of the fix being in b6, is that b5 wasn't released last week.
     
    Enrico-Monese, JakubSmaga and nhold like this.
  26. Enrico-Monese

    Enrico-Monese

    Joined:
    Dec 18, 2015
    Posts:
    77
    Seems fixed in b6