Support Request #10621
closed(Generated) DDLs to use for SignalView and HDRecorder
Description
Supportanfrage
while using ADTF 2.14.3 as a Developer I have to use *.description files to enable visualization of Connection Data via SignalView and record it via HDRecorder.- Unfortunately I have to handle big interfaces which are changing on regular basis. How is it possible to generate proper (functioning) DDLs from these headers? I know about the documented possibility with the MediaDescriptionEditor, which does not work due to unknown reasons.
- How can data, once being recorded with the HDRecorder into a dat file, be converted into csv files with the ADTF DAT-Exporter, when a proper DDL exists? For DDLs which enable recording via HDRecorder and display in SignalView, this does not work.
- What are the possibilities to debug and check DDLs and their handlung/usage? I know the adtf_mediadescriptioneditor.exe -check -descriptionfile= possibility, which however proves near to nothing except XML validity.
Feel free to answer in german. Thanks in advance!
Lösung
Hast du im Recorder die Property gesetzt, dass eine Description mit generiert wird? Dadurch wird neben das .dat file ein gleichnamiges .dat.descrption file gelegt, so dass deine Datenströme beschrieben sind. Das wird dann auch vom Datexporter für den csv Export verwendet.
Was die Konvertierung von Header zu DDL betrifft, so gibt es dort zahlreiche Einschränkungen, dass müsste man im Detail betrachten was da schief gehen kann. Leider sind wir hier in 2.x limitiert und hier wurde keine Aufwans mehr reingesteckt.
Alle Verbesserungen wurden mittlerweile in 3.x umgesetzt.
Der existierenden Header2DDL Konverter funktioniert nicht.
Der hat keinen richtigen C++ Parser, da kann sooo viel schief gehen. Geht schon bei verschachtelten Strukturen los und hört bei zuvielen oder zuwenigen Leerzeichen auf.
Falls es irgendwie praktikabel für dich ist, hier eine Möglichkeit mit immer noch viel manuellem Overhead:
Du schreibst eine kleines Executable mit dem ADTF3 SDK, dass die Header einbindet und mit Hilfe von https://support.digitalwerk.net/adtf/v3/adtf_html/classadtf_1_1mediadescription_1_1flash_1_1structure.html dann eine structure<> Objekt erzeugt. Mit Hilfe von https://support.digitalwerk.net/adtf/v3/adtf_html/classadtf_1_1mediadescription_1_1flash_1_1c_d_d_l_printer.html kannst du dir dafür dann eine DDL ausgeben lassen.
Heißt du musst zwar die Member selbst angeben/überprüfen, aber es ist zumindest typsicher und die DDL passt sicher zum Header.
Tut mir leid, dass wir da nix besseres anzubieten haben.
Zum Recording: In der .description Datei landen natürlich nur Beschreibungen von Daten, die diese im Media Typ hinterlegt haben
Updated by hidden about 4 years ago
- Project changed from Public Support to 20
- Status changed from New to In Progress
- Topic set to ADTF::DDL
Hallo Andre
Hast du im Recorder die Property gesetzt, dass eine Description mit generiert wird? Dadurch wird neben das .dat file ein gleichnamiges .dat.descrption file gelegt, so dass deine Datenströme beschrieben sind. Das wird dann auch vom Datexporter für den csv Export verwendet.
Was die Konvertierung von Header zu DDL betrifft, so gibt es dort zahlreiche Einschränkungen, dass müsste man im Detail betrachten was da schief gehen kann. Leider sind wir hier in 2.x limitiert und hier wurde keine Aufwans mehr reingesteckt.
Alle Verbesserungen wurden mittlerweile in 3.x umgesetzt.
Ich hoffe die Ausführungen oben helfen dir weiter.
@Martin: zusätzliche Anmerkungen?
Updated by hidden about 4 years ago
- Description updated (diff)
- Status changed from In Progress to To Be Closed
- Resolution set to No Customer Feedback
Updated by hidden about 4 years ago
Hallo Florian,
danke für deine Antwort.
Gibt es für die automatische Generierung der DDLs aus Headern bzw. deren zahlreiche Einschränkungen eine Liste? Diese Einschränkungen empirisch im „Produktivbetrieb“ zu erarbeiten ist recht mühsam und die Nutzerakzeptanz unseres Frameworks leidet mit jedem weiteren Treffer.
Die .description beim Recording mitzuschreiben habe ich bestimmt schon ausprobiert, aber ich kann mich nicht entsinnen, das Ergebnis mal gegen die .descriptions ge-diff-ed zu haben, die wir auf anderen Wegen erstellt haben. Ich gehe das nochmal an.
Beste Grüße,
André Seitz
Updated by hidden about 4 years ago
- Status changed from To Be Closed to In Progress
Updated by hidden about 4 years ago
Hallo Andre,
eine explizite Liste haben wir nicht, was der Parser alles kann.
@Martin: Kannst du es vielleicht auf den Punkt bringen ?
Updated by hidden about 4 years ago
Hi Flo und André,
um es so wie von dir gewünscht auf den Punkt zu bringen: Der existierenden Header2DDL Konverter funktioniert nicht.
Der hat keinen richtigen C++ Parser, da kann sooo viel schief gehen. Geht schon bei verschachtelten Strukturen los und hört bei zuvielen oder zuwenigen Leerzeichen auf.
Falls es irgendwie praktikabel für dich ist, hier eine Möglichkeit mit immer noch viel manuellem Overhead:
Du schreibst eine kleines Executable mit dem ADTF3 SDK, dass die Header einbindet und mit Hilfe von https://support.digitalwerk.net/adtf/v3/adtf_html/classadtf_1_1mediadescription_1_1flash_1_1structure.html dann eine structure<> Objekt erzeugt. Mit Hilfe von https://support.digitalwerk.net/adtf/v3/adtf_html/classadtf_1_1mediadescription_1_1flash_1_1c_d_d_l_printer.html kannst du dir dafür dann eine DDL ausgeben lassen.
Heißt du musst zwar die Member selbst angeben/überprüfen, aber es ist zumindest typsicher und die DDL passt sicher zum Header.
Tut mir leid, dass wir da nix besseres anzubieten haben.
Zum Recording: In der .description Datei landen natürlich nur Beschreibungen von Daten, die diese im Media Typ hinterlegt haben.
Grüße,
Martin
Updated by hidden about 4 years ago
- Status changed from In Progress to Customer Feedback Required
- Resolution changed from No Customer Feedback to Workaround Available
Updated by hidden about 4 years ago
- Project changed from 20 to Public Support
- Description updated (diff)
- Status changed from Customer Feedback Required to To Be Closed
- Private changed from Yes to No
Updated by hidden almost 4 years ago
- Status changed from To Be Closed to Closed