Support Request #4815
closedSupport for NSSUBPROP_VALUELIST in ADTF 3.x
Description
Supportanfrage
Wie geht das unter ADTF3?
Lösung
Mittels Plugin Description, siehe https://stackoverflow.com/questions/52829773/in-adtf-3-how-can-we-create-a-drop-down-list-for-the-filter-properties
Für eine API Erweiterung wurde ACORE-9812 erstellt
Updated by hidden over 5 years ago
Timo Steinwender wrote:
Wie geht das unter ADTF3?
Das erklärt es aber kann man nicht hier einfach eine property_type_description für machen? z.b. für eine std::list<adtf_util::cString>
Updated by hidden over 5 years ago
- Status changed from New to In Progress
- Topic set to ADTF::SDK
- Customer set to VW
Updated by hidden over 5 years ago
Hallo Timo,
erst einmal Entschuldigung für die späte Antwort. Leider ist wegen Urlaub und Vorbereitung abissel was drunter und drüber gegangen.
NSSUBPROP_VALUELIST kannst du ab jetzt über die Plugindescription beschreiben. Grundsätzlich werden nun alle Properties nicht mehr im Code selbst beschrieben sondern über die Plugindescription.
Als beispiel schau dir mal unseren demo_data_triggered_filter in den Examples an.
Auszug aus der Plugindescription:
<property_description>
<name>calculator_function/operator</name>
<type>tUInt32</type>
<value>0</value>
<list>
<property_list_enumeration>
<name>PLUS</name>
<value>0</value>
</property_list_enumeration>
<property_list_enumeration>
<name>MINUS</name>
<value>1</value>
</property_list_enumeration>
<property_list_enumeration>
<name>MULTI</name>
<value>2</value>
</property_list_enumeration>
<property_list_enumeration>
<name>DIVIDE</name>
<value>3</value>
</property_list_enumeration>
</list>
</property_description>
Updated by hidden over 5 years ago
- Status changed from In Progress to Customer Feedback Required
Updated by hidden over 5 years ago
Sebastian Geißler wrote:
Hallo Timo,
erst einmal Entschuldigung für die späte Antwort. Leider ist wegen Urlaub und Vorbereitung abissel was drunter und drüber gegangen.
NSSUBPROP_VALUELIST kannst du ab jetzt über die Plugindescription beschreiben. Grundsätzlich werden nun alle Properties nicht mehr im Code selbst beschrieben sondern über die Plugindescription.
Als beispiel schau dir mal unseren demo_data_triggered_filter in den Examples an.Auszug aus der Plugindescription:
[...]
Vielen Dank für die Antwort, aber das wusste ich bereits. Florian hatte mir bereits einen Link von Stackoverflow zukommen lassen. Den hatte ich hier auch nochmal im Ticket gepostet.
Der Sinn dieses Tickets war jedoch, dass man das programmatisch lösen können sollte. Eine Anpassung der Property files halte ich nicht für praktikabel. Die ValueList verwenden wir im Schnitt 3 mal pro Filter und ist eine der meist genutzten property-typen.
Was spricht denn dagegen z.B. den Typen: std::list<adtf_util::cString> zu supporten?
Updated by hidden over 5 years ago
- Status changed from Customer Feedback Required to In Progress
Hallo Sebastian,
hast Du die Antwort von Timo gesehen?
Updated by hidden over 5 years ago
@Martin: Kannst du das Thema unter dem Gesichtspunkt des Filter API Redesigns betrachten ?
Um es kurz zu machen:
Timo möchte a) sich eigentlich eine Property Variable sparen, weil sie nur einmal zum Init gebraucht wird ohne Callback und b) eine Liste im Code definieren.
Warum das in der Plugin Description seitesn Architektur geschieht, habe ich schon versucht zu erklären.
Vielleicht hast du ja eine alternative Erklärung bzw. einen Kompriss für eine Anforderung.
Updated by hidden over 5 years ago
Eine Property vom Type std::list<adtf_util::cString> kann man machen, das wäre aber dann eine Property die mehrere Strings enthält und nicht eine Auswahl zur Verfügung stellt. Sowas gibts übrigends auch schon für cFilenameList.
Hier will man ja die zur Auswahl stehenden Werte einschränken. Heißt der Weg wäre über ein Enum oder eine eigene Klasse die nur diese Werte abbilden kann. Leider gibt es derzeit aber keine Möglichkeit dass der Plugin Description Generator an dieses dieses Werte-Array rankommt.
Mit einer gröberen Erweiterung des IProperty Interfaces könnte sowas machbar sein. Dann könnte ich mir für den Anwender folgendes vorstellen:
list_property<tUInt32> oProp("my_prop", 1);
oProp.Add("value1", 1);
oProp.Add("value2", 2);
SetProperty(oProp);
@Flo, wollen wir das?
Updated by hidden over 5 years ago
- Subject changed from NSSUBPROP_VALUELIST to Support for NSSUBPROP_VALUELIST in ADTF 3.x
- Description updated (diff)
- Status changed from In Progress to To Be Closed
- Resolution set to Product Issue Opened
- Product Issue Numbers set to https://www.cip.audi.de/jira/browse/ACORE-9812
- Support Level changed from 2nd Level to 3rd Level
Produktticket ACORE-9812 angelegt, hier soll das Thema bewertet werden.
Supportfall an dieser Stelle abgeschlossen.
Updated by hidden over 5 years ago
- Project changed from 4 to Public Support
- Private changed from Yes to No