It not only looks - it is a modal dialog. The meaning of a modal dialog is blocking the user interface and not code execution.
You want your code execution to block till it gets dismissed? Sure, no problem - somewhere in the main or a task thread you can do this quick&dirty:
while myScene.dialog <> invalid
sleep(500)
end while
Do not do that in the render thread however, since it would block screen redraws. Under no circumstance should you delay event execution in the render thread (those being init(), observer functions, input handlers) for long-running code. No sleeping in the render thread! Your app may get terminated, or worse.
You’ll have to change the way you think about this. You’ll have to break your code in two pieces - the one “after” the dialog put in a different function, which is observing for change of say myScene.dialog field - or onKeyEvent() one
“EnTerr” wrote:
You’ll have to change the way you think about this. You’ll have to break your code in two pieces - the one “after” the dialog put in a different function, which is observing for change of say myScene.dialog field - or onKeyEvent() one
For a fake modal dialog have you considered pausing all the other routines when it is displayed? That way the render thread would simply be running and not changing anything.
“destruk” wrote:
For a fake modal dialog have you considered pausing all the other routines when it is displayed? That way the render thread would simply be running and not changing anything.
Not all, just the current thread.
This in not a fake modal dialog, but real
This is standard behaviour for the modal dialog on traditional systems.
“mape” wrote:
Not all, just the current thread.
This in not a fake modal dialog, but real
This is standard behaviour for the modal dialog on traditional systems.
You don’t understand - the render thread is not just any old thread. It is THE thread that draws the UI. THOU SHALT NOT hog the render thread, ever. That is (for Dune fans), “the spice must flow!”. Everything you do in scene/component functions/events should be fast and return within milliseconds. Think of every call as a hot potato. You need something more long-lived - do it in main or spin off a Task.
EnTerr
Thank you for the answer, but you talk about technical specifics. I trust you and don’t argue.
But I speak about TEORETHICAL behaviour of the modal dialog. How it should be.
If you right, that just means, that make REAL modal dialog (that behaves as modal on other systems) on Roku is impossible.
The defining characteristic of a modal dialog is that it prevents user interaction with the rest of the UI until the dialog is dismissed. And if the user REALLY can’t interact with the rest of the UI until the dialog is dismissed then you have a ‘REALLY modal dialog’. The Scene Graph Dialog component provides a ‘REALLY modal dialog’.
You need to understand a fundamental principle of Scene Graph architecture: The render thread is completely, 100% event-driven. The init() function registers event handlers. The rest of the code in a component defines the event handlers, which get called in response to specific events. This is not the type of architecture where you have a main program loop that waits for user-input, processes the input, then goes back to waiting for the next input, etc. Your program code never waits (nor executes) until the system detects an event that it needs to handle (e.g. a button-click), then calls the appropriate event-handling function, which handles the event, then exits. If you understand that already, then great. If not, you have some more studying to do.
JavaScript browser applications work exactly the same way – with one exception: They allow functions such as prompt() and alert() to block the render thread while waiting for user input. It sounds to me like the question you’re really asking is: “Can a Scene Graph render thread block while waiting for user input?” The answer to that question is unequivocally, NO. The reason is that Roku chose not to allow it, whereas the JavaScript creators did choose to allow it. There may be any number of reasons for their respective decisions, but that’s just the way it is. REALLY.
