Skip to content

Controlled Framework Shutdown and Timing #218

Description

@SamGinrich

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions