for anyone else having this issue, it comes down to being sure that the screen closes, behind you each time.
to do that you have to break the event loop so what i did and is working at this time.
is add EXIT WHILE after each command like this
while true
msg = (wait 0, screen.Get MessagePort())
if msg.isButtonPressed() then
if msg.GetIndex() = 1
show welcomeScreen()
exit While
end if
if mgs.GetIndex() = 2
showWhatever()
exit while
end if
end if
end while
close.Screen()
this is just an example, but gives you an idea, that each time i break out of the WHILE loop and it still reads the screen.Close()
hope that helps
this could be wrong and anyone feel free to pipe in if it is.
The navigation order of screens naturally follows a stack. It is best to structure your code with a function for each screen. The function should set the screen up and then execute an event loop. That way when you exit the event loop, the firmware’s internal currently displayed screen stack will match the event loop from the next function on your BrightScript call stack.
Any other navigation order of screens other than a stack calls for sophisticated programming skills, and a management of references to screen objects that you can explicitly call Close() on.
I have closed each and get back to the screen as needed but its still acting odd with the buttons on the welcome screen.
so if i got 3 screens away and i hit the “go home” button. it will take me back there no problem…
it appears to close all the screens behind me but then when i hit the start button it takes 3 clicks and/or going back up to start before i can actually start…
i will upload the package and let you see it, its hard to describe