How to programmatically exit out of scene graph's Scene?

I would also like to know the answer to this question.

somehow one has  to get into the main loop by manually creating an event by I don't see how this can be achieved.

while(true)
   event = m.port.WaitMessage(0)
   eventType = type(event)
   if eventType = "roSGScreenEvent"
      if event.isScreenClosed() then return
   end if   
end while

I had the same problem. It's just one of the countless shortcomings of the scenegraph "architecture", that there is no natural way to do that!

Though I got this to work, in a less-elegant way:

• In your scene, define an interface field e.g. "LaunchSubScene" as string


• In your main.brs, before starting the message loop, you do this: m.scene.observeField("LaunchSubScene", m.port)


• In the message loop, you get an event, when the "LaunchSubScene" has been changed and from there you can show a different scene or close the current scene


• Now, in your scene you only need to the the "LaunchSubScene" field to get it going

"softworkz" wrote:
I had the same problem. It's just one of the countless shortcomings of the scenegraph "architecture", that there is no natural way to do that!

"Architecture"? What architecture? 😉
Whoever conceived this was not Architect - more like "the Archenemy of software developers"!

Though I got this to work, in a less-elegant way: ...

I actually think yours is the most elegant way possible so far. Another way would be by using the "global component", which is clunkier. This observeField() with a port - is there an example on that, or did you reverse-engineer it from the passing mention in TFM? 

PS. wait - why do you want to exit from a Scene in the first place? Given that RSG as of now does not support multiple scenes (does it? i don't remember there being transitions between scenes - or overlay scenes - which i remember from scenography on another platform) - why not leave the scene alone and instead attach your real UI as a child underneath the "singleton" scene, then replace it?

"EnTerr" wrote:
"Architecture"? What architecture? 😉
Whoever conceived this was not Architect - more like "the Archenemy of software developers"!

Must have been a guy thinking he would be special if he creates something really special, forgetting that special alone is not enough - it must be good as well...

"EnTerr" wrote:
This observeField() with a port - is there an example on that, or did you reverse-engineer it from the passing mention in TFM?

observeField with a port is actually documented. I couldn't find an example, but - here things are getting funny again: The eclipse plugin comes with a project template that is using observeField with port for a search feature (it doesn't show how to work with multiple scenes, though).

"EnTerr" wrote:
PS. wait - why do you want to exit from a Scene in the first place? Given that RSG as of now does not support multiple scenes (does it? i don't remember there being transitions between scenes - or overlay scenes - which i remember from scenography on another platform) - why not leave the scene alone and instead attach your real UI as a child underneath the "singleton" scene, then replace it?

Yes, there are no transitions. I don't know what they are "supporting". They aren't even serious about answering questions in this forum. That's really embarrassing, given they are proposing a "new technology" here. All I can say is that I found a way to work with multiple scenes (even preserving the global context).
Now, I wouldn't say that this is a good way to create scenegraph applications in general, and I'm not doing that either. Actually I got only three different scenes: Main (all channel content presented in a single scene), Options and ConnectionWizard. The latter two are using the sliding panels approach with a PanelSetScene while the main content is using a different approach.
I'm not sure if there's a feasible method to have a sliding panels UI and a custom UI within the same scene, but even if it was, it would mean a lot of mixed code at the scene level for all possible cases and I wanted to the codebase clean and structured. That's why I'm working with three scenes and why I think there are valid cases for using multiple scenes.

"softworkz" wrote:
Yes, there are no transitions. I don't know what they are "supporting". They aren't even serious about answering questions in this forum. That's really embarrassing, given they are proposing a "new technology" here. All I can say is that I found a way to work with multiple scenes (even preserving the global context).
Now, I wouldn't say that this is a good way to create scenegraph applications in general, and I'm not doing that either. Actually I got only three different scenes...

Well i suspect by calling createScene() repeatedly you might be able to instantiate multiple Scene subclasses and that (undocumentedly) may replace the scene. But "what is in a Scene" that makes you want to subsclass specifically from Scene node for your screens and not from Group (its parent)? I.e.

What's in a name? that which we call a "scene"
By any other name would smell as sweet;

The type Scene has only 4 meager fields that i doubt you need. So in my thinking - Scene always stays (because roSgScreen is particular to it), has nothing else in it - the real screens then come with scene.createChild()/replaceChild()/removeChild(). Isn't that an option?

I'm not calling CreateScene() repeatedly, I'm actually working with multiple roSGScreens as well.

It's nothing sweet, that a "Scene" has got, but there are actually two "Scene" base objects:
Scene and OverhangPanelSetScene.
In one case I need the first and in the other case the latter. 

"softworkz" wrote:
I'm not calling CreateScene() repeatedly, I'm actually working with multiple roSGScreens as well.

Wow, the indignation. RSG is for masochists, huh.
I did try a second screen.createScene() idea and that did not pan out. Seems to do... nothing. No error nor did it replace the first scene.

It's nothing sweet, that a "Scene" has got, but there are actually two "Scene" base objects:
Scene and OverhangPanelSetScene.
In one case I need the first and in the other case the latter. 

Aha! I knew i have seen a library subclass of Scene, i just couldn't find it (OverhangPanelSetScene). My next crazy idea is if a Scene can have another Scene as a child. Since roSgScreen is particular about having Scene (or subclass thereof) at the top - but other than that don't think there is anything special that distinguishes Scene from ther UI nodes - in other words it seems scenes should be (ab)usable as regular nodes further down the tree too.

As mentioned, to get it working, you need to create a second roSGScreen object as well.
As for scene nodes as child nodes in a graph, I don't know, but I see no use for that..

"softworkz" wrote:
As mentioned, to get it working, you need to create a second roSGScreen object as well.
As for scene nodes as child nodes in a graph, I don't know, but I see no use for that..

I thought i explained it twice already but apparently am not good enough conveying it. The idea is to have 1 roSgScreen with 1 (dummy) Scene and then all other (real) scenes to be exchanged as an only child under the persistent root. Since roSgScreen apparently is not prepared to have it's root node change and having superfluous node (with no other content) on top should not slow down rendering

Perhaps I should stop trying your patience 🙂 and figure out first hand if that can work with the live RSG, since "the best-laid plans of mice and men often go awry".

"EnTerr" wrote:
Perhaps I should stop trying your patience 🙂 and figure out first hand if that can work with the live RSG, since "the best-laid plans of mice and men often go awry".

I apologize for my ignorance - I thought you were interested how I got it working while telling what you tried without success.. 🙂

Regarding ideas: I already had and tried so many that didn't work... Let's focus on what's actually working - hehe, but you should definitely try this because an unproofed concept is nothing worth!