TVision over NCurses nicely remotes mouse interactions with ssh.
In a regular linear control flow, e.g. of a configuration script, one might introduce several transient Dialog Views to enter complex parameters.
1.) It turns out, that a TApplication creates screen management objects, which do not end with the TApplication's lifecycle,
such that the contsole screen is not freed and subsequent console output is not readable.
A working solution is to call TScreen::suspend() after the TApplication object has been destroyed.
TMyApp myApp();
bool res = false;
try
{
myApp.run();
res = mxApp.getOK();
}
catch (const std::exception& x)
{
...
}
std::this_thread::sleep_for(std::chrono::milliseconds(50));
TScreen::suspend();
std::this_thread::sleep_for(std::chrono::milliseconds(50));
...
Question: Is this a valid approach or are there further objects to be released, for a proper cleanup,
or same might be reached in the TApplication's destructor?
2.) The code fragment above worked without delay frame around TScreen::suspend() in the Debug version.
Switching to Release build, though, the SSH-client got confused,
the protocol entered some raw mode, began displaying mouse moves and key strokes were no more accepted.
Question: Are there TVision- or NCurses-internal states to be set to reach controlled behaviour without delays,
or can one clearly conclude, that the problem is on the network/ssh side?
TVision over NCurses nicely remotes mouse interactions with
ssh.In a regular linear control flow, e.g. of a configuration script, one might introduce several transient Dialog Views to enter complex parameters.
1.) It turns out, that a
TApplicationcreates screen management objects, which do not end with theTApplication's lifecycle,such that the contsole screen is not freed and subsequent console output is not readable.
A working solution is to call
TScreen::suspend()after theTApplicationobject has been destroyed.Question: Is this a valid approach or are there further objects to be released, for a proper cleanup,
or same might be reached in the
TApplication's destructor?2.) The code fragment above worked without delay frame around
TScreen::suspend()in the Debug version.Switching to Release build, though, the SSH-client got confused,
the protocol entered some raw mode, began displaying mouse moves and key strokes were no more accepted.
Question: Are there TVision- or NCurses-internal states to be set to reach controlled behaviour without delays,
or can one clearly conclude, that the problem is on the network/ssh side?