Recording and Playback should be triggered using RM messages. For example:
/*!
Command to control Data Monitor
*/
class var_datamon_cmd : public rm_message_var
{
public:
RMMSG_CONST(var_datamon_rec,DATA_MONITOR_CMD,1)
generic_var<char> command; /* 0 = stop recording,
1 = start recording
2 = load playback file (switch to playback mode if required)
3 = stop playback (switch to realtime mode if required)
4 = pause
5 = playback 0.1x
6 = playback 0.25x
7 = playback 0.5x
8 = playback 1x (real-time)
9 = playback 2x
10 = playback 5x
11 = playback 10x
12 = playback 20x
13 = playback 30x
14 = playback 60x */
string_var<31> filename; /* Only valid when command is 1 or 2 */
} datamon_cmd;
The benefit of this is :
- Data Monitor can be controlled by an external program via the RM (ie. exports an external control interface)
- Widget plugins can be written that will automatically trigger recording based on certain conditions (eg. receipt of a certain message)
- The keyboard shortcut can also share the same interface
As in the typical RM design, a controller object will be written to service the request:
class recording_control : public mpt_autoshow
{
public:
virtual void operator()();
}
recording_control::operator()()
{
if (dirty)
{
dirty = false;
if (datamon_cmd.command == '\1')
DataMonitorLogger::start_record(datamon_cmd.filename);
else if …..
}
}
This will help to maintain a standard design across the entire program. The difference between var_datamon_cmd and other messages are:
- it is a static message, not built by a factory
- it is never recorded
Uploading ....