digitalwerk community: hiddenhttps://support.digitalwerk.net/https://support.digitalwerk.net/themes/digitalwerk_theme/favicon/dw.ico?16823609612021-11-22T13:06:06Zdigitalwerk community
Redmine Public Support - Support Request #15761: Open of adtf session without using batch/shell from adtf...https://support.digitalwerk.net/issues/15761#change-736792021-11-22T13:06:06Zhidden
<p>@Florian: Die benutzte Environment in eine der Dateien (session, project) mit einzutragen ist sicherlich das angenehmste. Ich könnte mir aber auch vorstellen, dass sich nur der CE in einer permanenten Liste merkt, welches die letzte Env zu einem Projekt war und diese dann auswählt, wenn das Projekt geöffnet wird. Das wäre nicht so intrusive.</p> Public Support - Support Request #15761: Open of adtf session without using batch/shell from adtf...https://support.digitalwerk.net/issues/15761#change-736622021-11-22T11:53:28Zhidden
<p>Mein Kommentar als "Außenstehender": Wie du schon sagst Florian, das adtfproject ist eigentlich nur zusammen mit der adtfenvironment nutzbar. Also sollte sich der CE auch merken, welche die letzte genutzte adtfenvironment eines Projektes war. Ansonsten ergeben die "Recent Projects" und auch "Open Project" nur bedingt Sinn.</p> Public Support - Support Request #15569 (Closed): ADTF_DISPLAY_TOOLBOXConfig.cmake required ciomp...https://support.digitalwerk.net/issues/155692021-10-26T12:38:56Zhidden
<p><strong>Supportanfrage</strong></p>
<p>Auch wir sind darauf reingefallen, dass man nicht zwei Komponenten gleichzeitig aus der DisplayToolbox 3.6 suchen lassen kann. z.B: <em>find_package(ADTF_DISPLAY_TOOLBOX REQUIRED COMPONENTS base mixinextension graphics drawer)</em><br />Das Problem ist schon seit min. v1.5 bekannt, aber leider immer noch nicht gefixt - obwohl es noch nur ein Einzeler wäre!<br />Siehe #13539, #14832, [ADISTB-1141]</p>
<p>Mir ist aber noch ein zweites Problem aufgefallen:<br />Es wird auf die falschen DisplayToolbox_FIND_REQUIRED_*-Variablen zugegriffen. Das muss ADTF_DISPLAY_TOOLBOX_FIND_REQUIRED_* heißen.</p>
<p>Mein Vorschlag für einen Patch, der - zumindest bei mir - beide Probleme behebt:<br /><pre>
$ diff ADTF_DISPLAY_TOOLBOXConfig.cmake.org ADTF_DISPLAY_TOOLBOXConfig.cmake
6,7d5
< get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
<
10c8,9
< if(DisplayToolbox_FIND_REQUIRED_${component})
---
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
> if(ADTF_DISPLAY_TOOLBOX_FIND_REQUIRED_${component})
16a16,17
>
> unset(_IMPORT_PREFIX)
</pre></p>
<p><strong>Lösung</strong></p>
<p>Fix erfolgt mit ADTF Display Toolbox 3.7.0</p> Public Support - Support Request #15291: 2d-Display destroys AdvancedDockingSystemhttps://support.digitalwerk.net/issues/15291#change-711812021-09-28T11:29:42Zhidden
<p>It happens everytime. And also with all the drawer examples from display-toolbox-example-project.</p> Public Support - Support Request #15291 (Closed): 2d-Display destroys AdvancedDockingSystemhttps://support.digitalwerk.net/issues/152912021-09-27T08:16:08Zhidden
<p><strong>Supportanfrage</strong></p>
<p>The 2D-Display somehow destroys the layout of the AdvancedDockingSystem.</p>
<p>The display window has no Tab-Bar and there are drawing artefacts at the side. The display window cannot be moved. <br />See attached screenshot.</p>
<p>Using: ADTF/3.12.7, adtf_display_toolbox/3.6.0</p>
<p><strong>Lösung</strong></p>
This is a long known issue related to 2D, 3D and Qml Filter, we facing a bug within Qt 5.12.
<ul>
<li>[ACORE-10774] - Missing content or tab title of QtQuick Filter in certain layout situations</li>
</ul>
<p>It can only be solved by migrating to Qt 5.15.2, for which we have to change our Windows platform to VS 2019 VC142.<br />Both part of 2021/Q4.</p> Public Support - Support Request #14987: Missing adtf_sample_stream_tracer.plugindescriptionhttps://support.digitalwerk.net/issues/14987#change-696632021-08-20T08:03:01Zhidden
<p>Worked. Thanks.</p> Public Support - Support Request #14987 (Closed): Missing adtf_sample_stream_tracer.plugindescrip...https://support.digitalwerk.net/issues/149872021-08-18T23:38:58Zhidden
<p><strong>Supportanfrage</strong></p>
<p>At least in ADTF3.12.5 and in ADTF3.12.7 the adtf_sample_stream_tracer.plugindescription file is missing. Also the one in bin/debug.</p>
<p><strong>Lösung</strong></p>
Since ADTF 3.11 the Sample Stream Provider has been changed to RPC and getting part of the core objects:
<ul>
<li><a class="external" href="https://support.digitalwerk.net/adtf/v3/adtf_html/page_sample_stream_trace_provider_plugin.html">https://support.digitalwerk.net/adtf/v3/adtf_html/page_sample_stream_trace_provider_plugin.html</a></li>
</ul>
<p>You can remove the provider service and clean the plugin lists.</p> Public Support - Support Request #12226: ADTF 2 dat file compressionhttps://support.digitalwerk.net/issues/12226#change-530332020-10-08T08:20:43Zhidden
<p>Unfortunately the ziplib is C++11, since we need a solution for ADTF2 we cannot use this.<br />We are now using cFileCompression (after closing the original stream). I seems to work fast enough.</p>
<p>Thanks. Ticket can be closed.</p> Public Support - Support Request #12226: ADTF 2 dat file compressionhttps://support.digitalwerk.net/issues/12226#change-529172020-10-05T10:49:35Zhidden
<p>Oh, I just found cFileCompression.</p>
<p>In fact, I has hoping for a stream compression, which compresses "along the way" of writing the file.<br />Is it wise to compress a file at cFilter::Stop() or cFilter::Shutdown()? This might slow down the shutdown process heavily? Which strategy is used by the HD-Recorder?</p> Public Support - Support Request #12226 (Closed): ADTF 2 dat file compressionhttps://support.digitalwerk.net/issues/122262020-10-05T10:36:14Zhidden
<p><strong>Supportanfrage</strong></p>
<p>Quick question:<br />For our own filter we want to write compressed files (using zip or gzip). The HD-Recorder can compress its dat-files.<br />So, are there any public functions within the ADTF2-SDK or any available libraries in the ADTF2 installation we might use?</p>
<p><strong>Lösung</strong></p>
<p>cFileCompression is the only functionality available.<br />The Recorder compresses DAT Files after they have been closed.<br />As the DAT Format requires random write access to the file, a streaming based compression is not an option.</p> Public Support - Support Request #11675: Record log messages as Media Sampleshttps://support.digitalwerk.net/issues/11675#change-502112020-07-16T11:16:00Zhidden
<p>Thanks. Can be closed.</p> Public Support - Support Request #11675 (Closed): Record log messages as Media Sampleshttps://support.digitalwerk.net/issues/116752020-07-10T12:34:07Zhidden
<p><strong>Supportanfrage</strong></p>
<p>We would like to record all log messages (LOG_INFO, LOG_ERROR, ...) into a dat-file. In ADTF2.14!</p>
<p>Is this possible? Can we write our own "logging-sinks" to transform messages into mediasamples?</p>
<p><strong>Lösung</strong></p>
<p>yes it is possible, you have to implement an <a href="https://support.digitalwerk.net/adtf/v2/adtf_sdk_html_docs/classucom_1_1_i_console_listener.html" class="external">IConsoleListener</a> and register at <a href="https://support.digitalwerk.net/adtf/v2/adtf_sdk_html_docs/classucom_1_1_i_console_device.html" class="external">IConsoleDevice</a>, like this:</p>
<pre><code class="cpp syntaxhl"><span class="n">cObjectPtr</span><span class="o"><</span><span class="n">IConsoleDevice</span><span class="o">></span> <span class="n">pConsoleDevice</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="n">IS_OK</span><span class="p">(</span><span class="n">_runtime</span><span class="o">-></span><span class="n">GetObject</span><span class="p">(</span><span class="n">OID_CONSOLE_DEVICE</span><span class="p">,</span> <span class="n">IID_CONSOLE_DEVICE</span><span class="p">,</span> <span class="p">(</span><span class="n">tVoid</span><span class="o">**</span><span class="p">)</span><span class="o">&</span><span class="n">pConsoleDevice</span><span class="p">)))</span>
<span class="p">{</span>
<span class="n">pConsoleDevice</span><span class="o">-></span><span class="n">CON_RegisterListener</span><span class="p">(</span><span class="k">this</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
<p>Then you can access the Log Messages and create Media Samples.</p> Public Support - Support Request #6409: Support for IPv6 in ADTF 2.xhttps://support.digitalwerk.net/issues/6409#change-274092019-03-06T13:53:48Zhidden
<p>OK. Danke. Ticket kann dann geschlossen werden.</p>
<p>Wir brauchen das auch für die in Entwicklung befindliche Anbindung von Steuergeräten mit BroadR-Reach. Das ist aber noch nicht SomeIP. Sondern eben anscheinend "nur" normale IPv6/UDP-Pakete.<br />Wir werden dann wohl was eigenes implementieren müssen.</p> Public Support - Support Request #6409 (Closed): Support for IPv6 in ADTF 2.xhttps://support.digitalwerk.net/issues/64092019-03-06T11:15:12Zhidden
<p><strong>Supportanfrage</strong></p>
<p>Wir suchen ADTF2-Filter zum Senden und Empfangen von UDP-Paketen, aber für IPv6!</p>
<p>Ich nehme stark an, dass die bestehenden UDP-Filter der Device-Toolbox nur IPv4 können. Könnt ihr das bestätigen?<br />Die Sourcen der Ethernet-Filter liegen auch in der DeviceToolbox. Leider wird dabei aber eine (closed-source) Socket-Klasse aus (Core-)ADTF genutzt.<br />Ich nehme stark an, dass diese Klasse nur IPv4 kann. Könnt ihr das bestätigen?</p>
<p>Wer könnte einen IPv6-Filter haben?</p>
<p><strong>Lösung</strong></p>
<p>Derzeit gibt es weder in ADTF 2.x noch in ADTF 3.x und deren Basiskomponenten einen Support für IPv6.<br />Es sind auch keine externen Komponenten bekannt, die hier unterstützen.</p>
<p>Mit SOME/IP wird zumindest kurzfristig das Tracing via PCAP IPv6 unterstützen, langfristig auch die Kommunikation/Senden.<br />Das betrifft den Support für BroadR-Reach, was aber noch nicht fest verplant ist (zeitlich) aber kommen wird.</p> Public Support - Support Request #6181: HD_PLAYER_FILE could not be resolvedhttps://support.digitalwerk.net/issues/6181#change-264602019-02-15T10:58:27Zhidden
<p>Mein Senf dazu:</p>
<p>Eine (lokale) cMacroResolver-Instanz kann nur ein paar wenige statische Macros auflösen (envvars, ...).<br />Es gibt aber eine adtf-weite Instanz vom MacroResolver. Bei der werden die "dynamischen" Werte registriert.</p>
<p>(Nur) Bei String-Properties werden die Macros übrigens automatisch (mit Hilfe der adtf-weiten Instanz) aufgelöst.</p>
<p>So sollte es gehen:<br /><pre>
tChar resolved[1024];
memset(resolved, 0, 1024);
ucom::cObjectPtr<adtf::IMacroResolver> _pMacroResolver;
if (IS_OK(_runtime->GetObject(NULL, IID_ADTF_MACRO_RESOLVER, (tVoid**)&_pMacroResolver)))
{
if (IS_OK(_pMacroResolver->ResolveMacros("$HD_PLAYER_FILE$", resolved, 512)))
{
LOG_INFO(cString::Format("Via Object: '%s'", resolved));
}
}
</pre></p>