It is actually a bit complicated. Here is what part of the page management code looks like in screen1:
And this is how it typically looks in the other screens:
The reason it is so complex is that I wanted the possibility for the user to get back to the previous screen as well when using the “back” function. Normally, using “back” would return to the calling screen, but in my case, the previous screen is always screen1, so I had to buffer the screen that was in use when the user decided to switch page.
The important thing to manage in this instance is to not use the "close screen’ procedure, but the “close screen with result” with the result being the name of the screen that should be opened next. That way, screen1 knows which screen it was that just closed and which one it should open next, keeping this in memory. If the user clicks ‘back’, then screen1 will know what screen to re-open.
This is a bit vintage, that is how I resolved to do things 3 years ago, with screen1 being only a splash screen and a hub for screen management, and users were expected to be able to jump from any screen to any other. Perhaps I’d do it differently now. The app I am focusing on now has the screen1 as the main processing one, and every other screen always go back to screen1 (no jumping between the “currency conversion management” and the “colour management” for instance) so I do not need to track where the user had been before.
By the way, I notice that your screen shots are showing elements in vivid yellow and deep purple, the colours I have in my blocks are more like antique gold and mauve. Do you adjust the colour of your screen shots deliberately or is there a colour control setting that I am unaware of?