AudYoFlo: Behavior: Report of Property Set Triggers

The properties are a fundamental part of the AudYoFlo system. The underlying software principles can be condiered as very powerful and also allow to define dependency relations and multi-listener functions. The property system in general is described at this location. At this place, solely the very specific mechanism to report modified property values towards connected listeners is described.

A multi-listener functionality is required where multiple frontends are connected to the backend at the same time. In that case, setting a property from within one frontend should leave the other frontends informed about the modified property. Also, sometimes, setting one property causes other properties to be modified as well. This, as a consequence, requires that the UI fields of all connected frontends are updated.

Two different ways to report events to the frontends are supported regarding properties:

1. A message to be emitted in the course of a "property set" operation.
2. A message to be emitted if the property has been modified outside of any "property set" operation.

Emitting a Message in the Course of a "Property Set" Operation

Whenever a property is set, a report of a modified property value can be generated by setting the parameter on_set.report_set in the property call to true. This function is inactive by default. If the parameter is true, the property descriptor is

• either added to a list of modified properties or
• immediately reported

in the set_property call sequence. Internally, the modified property is reported by running the function

jvxErrorType
CjvxProperties::add_property_report_collect(const std::string& propDescr, jvxBool reportDescriptorChanged).

The behavior of this function can be influenced as follows:

1. If the start function jvxErrorType CjvxProperties::_start_property_report_collect(jvxCallManagerProperties& callGate) was called before, the modified properties are collected until the stop function jvxErrorType CjvxProperties::_stop_property_report_collect(jvxCallManagerProperties& callGate) is called. In that case, all moodified properties are reported at once in a comma separated string list.

2. If start and stop functions are not called, the single property is reported immediately.

The described methods allow to report multiple properties at once to not create too many messages if a lot of properties are impacted.

Adding Reports for other impacted Properties

In case a specific property is modified that has an impact on another property, new report messages can be generated by running function add_property_report_collect manually, e.g.,

CjvxProperties::add_property_report_collect(genFFMpegWriter_technology::file_params.file_sub_type.descriptor.std_str(), true);

In this example, the property file_sub_type is not directly impacted by the "property set" trigger but is modified indirectly since another property (here: file_type) was modified. In this case, the property file_sub_type must be refreshed in the connected UI frontends even though it was not directly addressed. By calling the add_property_report_collect function, the descriptor is reported and will be reported to all connected frontend. A special role play the second argument in the call: If the second argument is true, the frontend will be signalled that the property may have even changed its format. For example, if a property is defined as a selection list, even the options to select from should be updated. In the reported identification of the emitted message to report the property modification, the property descriptor text field is then followed by a "+" signe to indicate that the frontend can expect new values in the selection list.

This functions either immediately reports that the property was changed or adds the reported property to a list of modified properties. manager to true when defined such that when one frontend sets a property

Back