event = m.port.WaitMessage(0)
eventType = type(event)
if eventType = "roSGScreenEvent"
if event.isScreenClosed() then return
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: ...
"Architecture"? What architecture?
Whoever conceived this was not Architect - more like "the Archenemy of software developers"!
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?
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...
What's in a name? that which we call a "scene"
By any other name would smell as sweet;
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.
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..