Project

General

Profile

Actions

Support Request #8345

closed

EBPRODUCTSUPPORT-4751 Qt issues in different setups nad Signal View problem

Added by hidden over 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Customer:
ELEKTROBIT
Department:
SUPPORT
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
Known Problem
Platform:
Windows 7 64bit
Topic:
ADTF::Common
FAQ Links:

Description

Supportanfrage

Wir haben das ein paar Fragen/Vorschläge zu den zukünftigen Releases von unserem ADTF Trainer:

"Q1: Is the ADTF 3 Support Toolbox (3.1.0) still supported by ADTF 3.6.1, ADTF 3.5?

Q2: The display toolbox 3.3 has been linked with Qt 5.9.7 but is intended for use with ADTF 3.4 or 3.5 that had been linked with Qt 5.9.0. So it is officially supported to link ADTF filters/service with newer versions of Qt?
For Q2 I found a partial answer: I get a lot of crashes depending on Qt with a simple playback project (with the example_file.adtfdat) and Signal View from Display Toolbox 3.3
The crashes seem to disappear when I update the folder "D:\ADTF\3.5.0\3rdparty\qt5" to Qt 5.9.7
So Qt seems not to possess binary forward compatibility but only binary backward compatibility.
Ergo: The Display Toolbox 3.3. is not usable with the plain ADTF 3.5 installation.

My improvement suggestion would be to improve the release process so that there are regular stages with releases of ADTF and toolboxes fitting together.
Q3: When is the release of display toolbox 3.4 to be expected?

Lösung

"Q1: Is the ADTF 3 Support Toolbox (3.1.0) still supported by ADTF 3.6.1, ADTF 3.5?

yes

Q2: The display toolbox 3.3 has been linked with Qt 5.9.7 but is intended for use with ADTF 3.4 or 3.5 that had been linked with Qt 5.9.0. So it is officially supported to link ADTF filters/service with newer versions of Qt?
For Q2 I found a partial answer: I get a lot of crashes depending on Qt with a simple playback project (with the example_file.adtfdat) and Signal View from Display Toolbox 3.3
The crashes seem to disappear when I update the folder "D:\ADTF\3.5.0\3rdparty\qt5" to Qt 5.9.7
So Qt seems not to possess binary forward compatibility but only binary backward compatibility.
Ergo: The Display Toolbox 3.3. is not usable with the plain ADTF 3.5 installation.

ADTF is binary compatible as long as its dependencies are. This is not new, this has been the same in 2.x universe.
There are some issues with different QT versions that will work, some may not. We recommend to use the toolboxes with the released core version.

But I don't know what's going wrong on your side.
ADTF 3.4, ADTF 3.5 and Display TB 3.3 use all Qt 5.9.7.

My improvement suggestion would be to improve the release process so that there are regular stages with releases of ADTF and toolboxes fitting together.

yes, this is the way we want to improbve the process

Q3: When is the release of display toolbox 3.4 to be expected?

It has been this week, see https://support.digitalwerk.net/news/78

Then some improvement suggestion for the Signal View: The selected signals get automatically unselected when playback finishes. Could this improved so that the selected signals stay selected also for the next replay?"

Known Problem -> ADISTB-837

Das sollte unbedingt in die Release-Info der ADTF version.

Das gibt es mittlerweile seit ADTF 3.6.0, siehe External Dependencies
Und so steht es auch seitdem immer in Release Notes.

Für die Versionen davor wäre der Workaround direkt im Paket zu schauen, also .\3rdparty\qt5\lib\cmake\Qt5\Qt5ConfigVersion.cmake
Dafür können und werden wir nichts patchen.

Vielleicht waren die Abstürze insgesamt auch Zufall. Ist leider ein etwas instabiles tool

Yep, ich würde auch kein ADTF >= 3.5.0 (wegen Filter API; aber am besten gleich ADTF >= 3.6.x wegen UX) empfehlen, auch was Qt Version & Support betrifft.

Könnt Ihr nochmal nach dem Cmake issue schauen? Wo kommt der Output her? Kann das gefixt werden?

Der Output kommt genau aus diesem File -> .\pkg\adtfui\ADTFQTMacros.cmake
Hier passt die Abfrage nicht, das wurde mittlerweile gefixt in ADTF 3.6.0, für ältere Versionen müsste das manuell angepasst werden.


Files

image001.png (9.63 KB) image001.png hidden, 2019-09-18 12:45
Actions #1

Updated by hidden over 4 years ago

  • Project changed from Public Support to 7
  • Status changed from New to In Progress
  • Topic set to ADTF::Common
  • Customer set to ELEKTROBIT
  • Department set to SUPPORT
  • Affected Products ADTF 3 Support Toolbox 3.1.0, ADTF 3.5.0, ADTF 3.6.1, ADTF Display Toolbox 3.3.0, ADTF Display Toolbox 3.4.0 added
Actions #2

Updated by hidden over 4 years ago

Hallo Anja,

"Q1: Is the ADTF 3 Support Toolbox (3.1.0) still supported by ADTF 3.6.1, ADTF 3.5?

yes

Q2: The display toolbox 3.3 has been linked with Qt 5.9.7 but is intended for use with ADTF 3.4 or 3.5 that had been linked with Qt 5.9.0. So it is officially supported to link ADTF filters/service with newer versions of Qt?
For Q2 I found a partial answer: I get a lot of crashes depending on Qt with a simple playback project (with the example_file.adtfdat) and Signal View from Display Toolbox 3.3
The crashes seem to disappear when I update the folder "D:\ADTF\3.5.0\3rdparty\qt5" to Qt 5.9.7
So Qt seems not to possess binary forward compatibility but only binary backward compatibility.
Ergo: The Display Toolbox 3.3. is not usable with the plain ADTF 3.5 installation.

ADTF is binary compatible as long as its dependencies are. This is not new, this has been the same in 2.x universe.
There are some issues with different QT versions that will work, some may not. We recommend to use the toolboxes with the released core version.

But I don't know what's going wrong on your side.
ADTF 3.4, ADTF 3.5 and Display TB 3.3 use all Qt 5.9.7.

My improvement suggestion would be to improve the release process so that there are regular stages with releases of ADTF and toolboxes fitting together.

yes, this is the way we want to improbve the process

Q3: When is the release of display toolbox 3.4 to be expected?

It has been this week, see https://support.digitalwerk.net/news/78

Then some improvement suggestion for the Signal View: The selected signals get automatically unselected when playback finishes. Could this improved so that the selected signals stay selected also for the next replay?"

@Sebastian: please have a look at that if there is already an issue or some has to be created.

Actions #4

Updated by hidden over 4 years ago

Hallo zusammen,

es gibt mit der SignalView ein Problem, dass die Signal-Zustände nicht gespeichert werden, wenn sich der Runlevel zB. am Ende des der Wiedergabe verändert.
Ticket hierzu https://www.cip.audi.de/jira/browse/ADISTB-837

Viele Grüße
Sebastian Stern

Actions #5

Updated by hidden over 4 years ago

  • Project changed from 7 to Public Support
  • Subject changed from EBPRODUCTSUPPORT-4751 Release information wanted to EBPRODUCTSUPPORT-4751 Qt issues in different setups nad Signal View problem
  • Description updated (diff)
  • Status changed from In Progress to Customer Feedback Required
  • Private changed from Yes to No
  • Resolution set to Solved Issue
  • Product Issue Numbers set to https://www.cip.audi.de/jira/browse/ADISTB-837

Damit sollte alles beantwortet sein oder ?

Actions #6

Updated by hidden over 4 years ago

  • Resolution changed from Solved Issue to Known Problem
Actions #7

Updated by hidden over 4 years ago

Hallo Florian,

Danke. Teilweise:

Bezüglich Qt 5.9.7, das war mir neu. Dass das die Qt-Version ist. Das sollte unbedingt in die Release-Info der ADTF version.
Vielleicht waren die Abstürze insgesamt auch Zufall. Ist leider ein etwas instabiles tool

CMake (Build examples manually) verlang weiter die Qt 5.9.0-Version für das QT_DIR.

Könnt Ihr nochmal nach dem Cmake issue schauen? Wo kommt der Output her? Kann das gefixt werden?

Best regards,
Anja Winkler

Actions #8

Updated by hidden over 4 years ago

  • Status changed from Customer Feedback Required to In Progress
Actions #9

Updated by hidden over 4 years ago

  • Status changed from In Progress to Customer Feedback Required

Hi Anja,

Das sollte unbedingt in die Release-Info der ADTF version.

Das gibt es mittlerweile seit ADTF 3.6.0, siehe External Dependencies
Und so steht es auch seitdem immer in Release Notes.

Für die Versionen davor wäre der Workaround direkt im Paket zu schauen, also .\3rdparty\qt5\lib\cmake\Qt5\Qt5ConfigVersion.cmake
Dafür können und werden wir nichts patchen.

Vielleicht waren die Abstürze insgesamt auch Zufall. Ist leider ein etwas instabiles tool

Yep, ich würde auch kein ADTF >= 3.5.0 (wegen Filter API; aber am besten gleich ADTF >= 3.6.x wegen UX) empfehlen, auch was Qt Version & Support betrifft.

Könnt Ihr nochmal nach dem Cmake issue schauen? Wo kommt der Output her? Kann das gefixt werden?

Der Output kommt genau aus diesem File -> .\pkg\adtfui\ADTFQTMacros.cmake
Hier passt die Abfrage nicht, das wurde mittlerweile gefixt in ADTF 3.6.0, für ältere Versionen müsste das manuell angepasst werden.

Actions #10

Updated by hidden over 4 years ago

Hallo Florian,

vielen Dank. Ihr könnt das Ticket schließen.

Grüße,
Anja

Actions #11

Updated by hidden over 4 years ago

  • Description updated (diff)
  • Status changed from Customer Feedback Required to To Be Closed
  • Platform Windows 7 64bit added
Actions #12

Updated by hidden almost 4 years ago

  • Status changed from To Be Closed to Closed
Actions

Also available in: Atom PDF