Allow creating an event template

[CyGa]

Hi,

Some of my events have a common events arguments and/or reply payload.
Creating a template would speed up their creation.

Also, when using round trips from TestStand, I made a modification to the content of a round trip event to easily handle termination.
It could be nice if this modification could be saved as a template, so that every round trips I create to be used within a TS sequence would contain automatically that modification.

[Olivier-JOURDAN]

Cool idea but we need to investigate how much time this requires to implement. We will postpone this idea for a later DQMH version.

[mbaudot]

Is this still a need now that the Neosoft Testandifier is out there, and that we have the ability to Duplicate Events in DQMH 7.1 ??

[CyGa]

The TSifier has nothing to do with this. The 'roud trip used with TS' story was just an example.

The idea is to :
* Avoid recreating a payload (req/resp typedef) at each event

* Avoid event modification (if needed) to be reapeated for each new event.

As we have templates for a module, I'd like to have a template for an event.

Copying an event means I've got one already in my project.

Across several projects, I sometimes use the same type of events (ex. specific broadcast with log data for debugging).

The idea is to save this event once as a template, and be able to use it whatever the project I'm working on.

[mbaudot]

Just to clarify, are you talking about the implementation of a request, or what you set on the Events Creation dialog?

[CyGa]

The template could preset both the typdefs and the event settings. That would be a good start.

Otherwise, it could completely obfuscate the settings of the Events Creation dialog and simply duplicate the template to create a new event.

I would agree with both approches. The idea is to avoid repetitive clicks to produce already 'well known' code.

[joerg.hampel]

After consideration and discussion, we decided to decline this feature request.

Implementing this natively in the framework feels difficult to to in a very generic way. We feel it makes more sense to implement this feature using the existing scripting hooks and API, as one can then cater to their individual situation and requirements.

There is a video of one of our Trusted Advisors showing how a feature like this could be actually implemented facilitating the existing framework features (ie scripting hooks) which we will publish shortly. 

We really appreciate your input, declining the idea does not mean it didn't help us fine-tune the scope of DQMH and reconsider our strategy. Please keep those ideas coming 😉