Public Support

Kindly discard the filtergraph pictogram in the above description...

Attached picture provides the actual filtergraph scenario

Dear Murali,

the connection with the highest priority is handled first.
You have to know, that a Transmit stubs immediately a Receive (OnPinEvent), so a sample route will be finished to all its connected filters.
Afterwards, the next sequence will be called.

Please have a look at Pins for Filters, especially the example chart.

If you have additional questions, please let me know.

Dear Florian,

The second and third stage filters in the config shown in the filters have dynamic input pins. I want the connect methods of the filters to be called in the forward order (especially connect method of 2nd stage needs to be called before the connect method of 3rd stage). But this is not happening. As per the documentation, the sequence of pin connections happen as per the connections order in system.xml file. But manually editing the system.xml everytime is not user friendly.

I tried with the plugin description optionas specified in the documentation but the connection between the second stage and third stage filter did not happen at all. I am attaching the plugin description files for your reference.

Let me know if I made some mistakes in plugin description. I am not clear of how to provide description for dynamic inputs. For 2nd stage filter, only after the connection of its input dynamic pins done, the connection between 2nd stage output to 3rd stage input dynamic input pins should happen

Dear Murali,

Yes.. But changing the connection order by manipulating the system.xml is not user friendly.

You have to differ between connection order during initialize (appearance in system.xml -> therefore we have no edit mode in ADTF 2.x) and data flow during run (connection priority, you can edit in the properties).
Second thing is imho your use case.

What is the purpose of *.plugindescription file?

Yes, you have to know, the plugin description mechanismus in ADTF 2.x was introduced to show additional information about the filter itself for the user (pins, properties, dependencies).
The purpose was not to load the complete plugin, but this was realized in ADTF 3.x.
This was not possible in the old architecture.

In documentation it is mentioned,

"When the internal data flow of a filter is described via the description, the ADTF session manager uses this information to sort and connect the pins according to their dependencies. This ensures that pins are connected in the correct order when data types of output pins depend on data types of input pins."

But introducing a plugin description file is worsening the scenario as the connect method is not called for 3rd stage filter..

Yes, we know. But ADTF 2.x runs out of maintainance and all new features can only be realized in ADTF 3.x