Project

General

Profile

Actions

Support Request #11907

closed

Detection Pintype/-direction

Added by hidden over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Customer:
AUDI
Department:
AST
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
Solved Issue
Product Issue Numbers:
Affected Products:
Platform:
Windows 10 64bit
Topic:
ADTF::FilterSDK
FAQ Links:

Description

Support Anfrage:

wir lässt sich bei ADTF 3 ermitteln, ob es ein Inputpin oder ein Outputpin ist, wenn ich über this->GetPins() alle Pins des Filters auslese?

Bei ADTF 2 war das über die GetDirection() Methode möglich, aber die gibt es bei ADTF 3 nicht mehr.

Lösung:

Der Editor im CE legt diese Pins nur im CE an, sodass sie im Graphen verwendet werden können. Diese dynamischen Pins werden dann zu Laufzeit über RequestDynamicInputPin() (https://support.digitalwerk.net/adtf/v3/adtf_html/classadtf_1_1filter_1_1flash_1_1c_graph_object.html#a47e3cf5bcffe517ed81f1c285f3b36a1) und RequestDynamicOutputPin() (https://support.digitalwerk.net/adtf/v3/adtf_html/classadtf_1_1filter_1_1flash_1_1c_graph_object.html#a35e74067c9a2c20d99b8fa230c382fa9) beim Filter angefordert und der muss sie in diesen Funktionen dann erstellen. In der Doku sind jeweils Beispiele aufgeführt.

Das bedeutet der Weg über GetPins() ist hier der Falsche :-). Der Vollständigkeit halber: Den Typ eines Pins findet man über einen ucom_cast<> zu IInPin oder IOutpin raus.

Eigentlich reicht es, wenn ihr euch die Reader/Writer (der Returnwert) von CreateInputPinund CreateOutputPin() in den Request Funktionen merkt (so wie es die Beispiele machen).

Die Methode RequestDynamicPin wird immer für alle Pins des Filter aufgerufen, die nicht statisch erzeugt worden sind oder? Dann wäre der Weg darüber eigentlich besser.

Ja genau!


Files

image001.png (31.2 KB) image001.png hidden, 2020-08-12 14:30
Actions

Also available in: Atom PDF