Hi!
I have made a very simple example in Nifty GUI. There are 2 screens, one is loaded at the start and second is changed to after 2 seconds (done in simpleUpdate function).
There is a null pointer exception, which hints that the second screen is never bound. How come that this can happen? Is nifty not thread safe or smth? Notice that if I try calling bind earlier (simpleInitApp), I also get null pointer exception in the bind method, that complains about TextRenderer in label control.
Please see the example at:
http://www.megafileupload.com/en/file/437306/NiftyGUIProblem-zip.html
I am also summoning @void256 here, since this is very simple case and it is very strange that it is not working correctly. I am assuming that this could be a bug in nifty.
Please show code or it will be very hard to guess what could be wrong.
Bind is called when the screen is about to be shown for the first time. Calling nifty.goTo (“screenName”) doesn’t call bind instantly, it just signifies to Nifty that you wanna change screen. Once the screen is initialized, bind will be called, and the screen will appear.
So you need to remove:
[java]statsMenu.setLabel(“NOW ON STATS!”);[/java]
after the goTo statement, because the screen is not initialized yet
Ok, this is all clear to me, but how can I then know when it is safe to change this label in the new menu after I switch to it?
It looks to me that I would need to somehow enqueue this call to this menu, have the menu contain list of all the callables, have a callback function to the update loop, somehow check when the screen is bound and run the list of updates when this happens. Seems totally overcomplicated for this matter.
Note that if I try binding the screen earlier (commented line), I get different null pointer exception, probably because screen is not initialized, so it is not possible to do this before.
This makes it impossible to have dynamic screens that need to be up to date when they are first shown.
Any other suggestion for this matter? 
There are callbacks to the screen when it starts - just use that callback to set up all the display and until then store the values somewhere the screen can access them.
For ad-hoc changes after that there is the enqueue method on the main application which can be used to execute code on the render thread.