Add a parameter in the DisplayCueImage box to not send the triggers to the acquisition server.

It is sometimes useful to create a control display that shows the cued images to the experimenter (not the subject) on a different screen. But doing so, duplicated events (one per display) are sent to the acquisition server. This is wrong. This PR adds a boolean parameter to the DisplayCueImage box. By default this parameter is true (i.e. triggers are sent), but using this parameter it is possible to add multiple DisplayCueImage boxes but have only one that sends the triggers to the acquisition server.

The parameter is set to true by default to keep the old behaviour. However, this setup can lead to scenarios in which multiple triggers are sent, without the experimenter noticing it immediately. Putting the parameter to false by default would have the advantage that the experimenter would immediately see that sthg is wrong (triggers would not appear on the signal display)...

Note also that the testing has been done only at the interface level as lua boxes currently do not work on linux (see issue #3 (closed)).

Hi,

Before merging, sorry a big update took place on this plugin (coding rules, modernization, standardization, simplification variable name ...) so conflicts will appear. If you can recover the last master you can easily resolve conflicts.

Then, I am not against your modifications at all but a big work must take place by changing the parameters or behavior of boxes.....

• Update the scenarios of examples and tests using this box. (already the example of the box but also p300 scenarios I think.) The only way I see is to open all quickly and you will see the gray box that is not up to date.
• And finally update the documentation of the box.
• Bonus track: the test cases to update but doesn't concern your case, we don't test (NOT YET) the boxes of visualization. Thibaut

I thought I already caught those (coding rules, modernization, standardization, simplification variable name ...) as I already had to adapt my change after the rebase I did before making the pull request. You mean that there were another bunch of changes ?

In any case, the changes I have made are small, it will probably be quite easy to redo the changes over the newest version of the code...

As for updating all the scenarios, you are right. I have not thought of it... Indeed, I had to update the test scenario I used to test the box. But, I doubt I will have time to do that manually. At the very best, I will write a script that automates the change. In this simple case, there is actually nothing to do beside removing the old box, and adding a new one and then copying the same parameters, but doing so with the designer is both time consuming and error-prone. I guess it is a simple id change... I do not know openvibe file structure well enough to know where to find all the examples.

For the documentation, you are totally right...

I admit never having tested to replace the boxes by a script. I know it's a long time ago but I had to do it manually because some scenarios had never had an update and sometimes on several boxes. ^^