<?xml version="1.0" ?>
<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/" 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
  xmlns="http://purl.org/rss/1.0/"
  xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel rdf:about="https://www.bugs.dmxcontrol-projects.org/">
    <title>DMXC Bugtracker -</title>
    <link>https://www.bugs.dmxcontrol-projects.org/</link>
    <description>DMXC Bugtracker -DMXControl 3: Recently edited tasks</description>
    <dc:date>2026-06-04T21:28:42Z</dc:date>
    <items>
      <rdf:Seq>
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5588" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5589" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5587" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5586" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5583" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5585" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5584" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5152" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=4674" />
                <rdf:li rdf:resource="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5581" />
              </rdf:Seq>
    </items>
    		
  </channel>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5588">
    <title>FS#5588: Zusätzliches Preset für Datum bei einem Label im Softdesk</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5588</link>
    <dc:date>2026-06-04T21:28:42Z</dc:date>
    <dc:creator>Stefan Schmidt</dc:creator>
     <description>

Hallo,In dem Menue für Label kann ich Custom (was eigenes) oder Clock (Uhr) auswählen.Ist es möglich das um Date (Datum) zu erweitern.



Gruß Steff

</description>
    <content:encoded><![CDATA[
<p>
Hallo,<br />In dem Menue für Label kann ich Custom (was eigenes) oder Clock (Uhr) auswählen.<br />Ist es möglich das um Date (Datum) zu erweitern.
</p>

<p>
Gruß Steff<br />
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5589">
    <title>FS#5589: Startparameter für Kernel zum unmittelbaren Aufbau einer lokalen Verbindung zum Umbra</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5589</link>
    <dc:date>2026-06-04T19:28:36Z</dc:date>
    <dc:creator>Stefan Kistner</dc:creator>
     <description>

Ich merke gerade auf meinen Laptop in den letzten Tagen sehr regelmäßig, dass der Kernel sich nicht lokal mit dem Umbra verbindet - obwohl ich alle drei Instanzen lokal ausführe.



Mein Wunsch wäre an dieser Stelle, den Kernel über einen Startparameter direkt zum Aufbau einer lokalen Verbindung zu zwingen, wodurch der automatische Verbindungsaufbau komplett deaktiviert wird.



Ich kann ja auch aktuell schon den Befehl &amp;#8220;connect localhost&amp;#8221; in den Kernel eingeben, selbst wenn der Umbra noch nicht gestartet ist. Sobald der Umbra gefunden wurde, kann der Befehl auch umgesetzt werden.

</description>
    <content:encoded><![CDATA[
<p>
Ich merke gerade auf meinen Laptop in den letzten Tagen sehr regelmäßig, dass der Kernel sich nicht lokal mit dem Umbra verbindet - obwohl ich alle drei Instanzen lokal ausführe.
</p>

<p>
Mein Wunsch wäre an dieser Stelle, den Kernel über einen Startparameter direkt zum Aufbau einer lokalen Verbindung zu zwingen, wodurch der automatische Verbindungsaufbau komplett deaktiviert wird.
</p>

<p>
Ich kann ja auch aktuell schon den Befehl &#8220;connect localhost&#8221; in den Kernel eingeben, selbst wenn der Umbra noch nicht gestartet ist. Sobald der Umbra gefunden wurde, kann der Befehl auch umgesetzt werden.<br />
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5587">
    <title>FS#5587: DMXControl 3.X.X Projekt wird beim Beenden nicht gespeichert, DMXC wird nicht beendet</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5587</link>
    <dc:date>2026-06-04T06:08:53Z</dc:date>
    <dc:creator>Karsten</dc:creator>
     <description>

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.


Fehlerbeschreibung



Wenn ich beim Beenden von DMXC Speichern aktiviert habe passiert nichts, DMXC wird nicht beendet. Ich muss das Projekt vorher speichern, den Haken beim Beenden wegnehmen, jetzt erst wird das Programm geschlossen. Das trat bislang bei allen von mir eingesetzten DMXC 3.x Versionen auf. Zurzeit ist DMXC 3.3.2 installiert.




Erwartetes Verhalten



DMXC sollte beim Beenden das aktuelle Projekt speichern, wenn diese Funktion selektiert ist.



</description>
    <content:encoded><![CDATA[
<p>
Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.
</p>

<h2 id="fehlerbeschreibung">Fehlerbeschreibung</h2>
<div class="level2">

<p>
Wenn ich beim Beenden von DMXC Speichern aktiviert habe passiert nichts, DMXC wird nicht beendet. Ich muss das Projekt vorher speichern, den Haken beim Beenden wegnehmen, jetzt erst wird das Programm geschlossen. Das trat bislang bei allen von mir eingesetzten DMXC 3.x Versionen auf. Zurzeit ist DMXC 3.3.2 installiert.
</p>

</div>

<h2 id="erwartetesverhalten">Erwartetes Verhalten</h2>
<div class="level2">

<p>
DMXC sollte beim Beenden das aktuelle Projekt speichern, wenn diese Funktion selektiert ist.
</p>

</div>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5586">
    <title>FS#5586: Automatische Zuorderung von Standard-Formatvorlagen aus Word-Dokumenten</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5586</link>
    <dc:date>2026-06-01T08:32:07Z</dc:date>
    <dc:creator>Stefan Kistner</dc:creator>
     <description>

Ich stelle mir vor, dass beim Import von Word-Dokumente bestimmte Standard-Formatvorlagen wie Standard (-Text), Überschrift 1, Überschrift 2, Überschrift 3 etc. automatisch den Styles im Textbuch zugeordnet werden. Die Formatierung wie Schriftart, Schriftgröße, Schriftfarbe etc. im Word-Dokument wird aber dabei ignoriert. Es sollen die aktuellen Einstellungen der korrespondierenden Styles im Textbuch gelten.

</description>
    <content:encoded><![CDATA[
<p>
Ich stelle mir vor, dass beim Import von Word-Dokumente bestimmte Standard-Formatvorlagen wie Standard (-Text), Überschrift 1, Überschrift 2, Überschrift 3 etc. automatisch den Styles im Textbuch zugeordnet werden. Die Formatierung wie Schriftart, Schriftgröße, Schriftfarbe etc. im Word-Dokument wird aber dabei ignoriert. Es sollen die aktuellen Einstellungen der korrespondierenden Styles im Textbuch gelten.<br />
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5583">
    <title>FS#5583: Textbuchplugin - Docx Import jede zweite Zeile wird nicht auf style 1 gesetzt.</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5583</link>
    <dc:date>2026-05-31T21:17:32Z</dc:date>
    <dc:creator>Joseph Noetzel</dc:creator>
     <description>

Es wird beim Import einer docx Datei jede improtierte Zeile immer abwechselnd mit Style 1 und 99 gesetzt. Praktisch wäre wenn immer Style 1 genommen wird. Oder man kann es aufteilen. Normeler Text Style 1, Überschrift 1 Style 2, Ü2 - Style 3 usw. Wäre aber nur nice to have… 

</description>
    <content:encoded><![CDATA[
<p>
Es wird beim Import einer docx Datei jede improtierte Zeile immer abwechselnd mit Style 1 und 99 gesetzt. Praktisch wäre wenn immer Style 1 genommen wird. Oder man kann es aufteilen. Normeler Text Style 1, Überschrift 1 Style 2, Ü2 - Style 3 usw. Wäre aber nur nice to have… 
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5585">
    <title>FS#5585: TExtbuchplugin - Docx import Zeilen werden immer doppelt angelegt</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5585</link>
    <dc:date>2026-05-31T21:17:17Z</dc:date>
    <dc:creator>Joseph Noetzel</dc:creator>
     <description>

Im Anhang das Dokument wo das Problem auftritt.

</description>
    <content:encoded><![CDATA[
<p>
Im Anhang das Dokument wo das Problem auftritt.<br />
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5584">
    <title>FS#5584: Textbuchplugin - Highlight der aktuellen Cue(list) stärker anzeigen</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5584</link>
    <dc:date>2026-05-31T20:04:11Z</dc:date>
    <dc:creator>Joseph Noetzel</dc:creator>
     <description>

wäre super, wenn man die aktuelle Position von dem Go besser hightlighten könnte. Der Punkt an der Seite ist für mich persönlich etwas unauffällig.



Mein Vorschlag wäre, dass man den Hintergrund von der entsprechenden laufenden Zeile markiert. So ähnlich, wie das selektieren der Zeile.

</description>
    <content:encoded><![CDATA[
<p>
wäre super, wenn man die aktuelle Position von dem Go besser hightlighten könnte. Der Punkt an der Seite ist für mich persönlich etwas unauffällig.
</p>

<p>
Mein Vorschlag wäre, dass man den Hintergrund von der entsprechenden laufenden Zeile markiert. So ähnlich, wie das selektieren der Zeile.
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5152">
    <title>FS#5152: GUI stockt / stürzt ab bei Werteänderung über MIDI</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5152</link>
    <dc:date>2026-05-30T08:44:36Z</dc:date>
    <dc:creator>Stefan Kistner</dc:creator>
     <description>

Mit dem beigefügten Projekt habe ich eine einfache Ansteuerung der Position von in der Stage View ausgewählten Geräten über meinen MIDI-Controller (Traktor F1) realisiert. Bei schnellen, ruckartigen Werteänderungen stockt GUI bis hin zum Einfrieren. Das Stocken betrifft im konkreten Fall unter anderem das Position Control und das Device Control. Hier liegt bei mir die Vermutung nahe, dass bei einer meiner letzten Nutzung im größeren Umfeld deswegen die GUI auch komplett abgestürzt ist. Der gezeigte Auszug aus den beigefügten Logs entstammt der ersten GUI-Session.

2023-09-15 18:44:42,258 [74] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Facade.DeviceProperties.DevicePropertyFacade.&amp;lt;OnProgrammerValueChanged&amp;gt;d__71.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\DeviceProperties\DevicePropertyFacade.cs:Zeile 516.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.&amp;lt;&amp;gt;c.&amp;lt;ThrowAsync&amp;gt;b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()


Nutze ich im gleichen Connectionset statt die Fader / Encoder meines MIDI-Controllers die beiden Slider des ebenfalls enthaltenen Softdesks, werden alle Werteänderungen sauber umgesetzt. Sowohl langsame als auch schlagartige Werteänderungen kommen nahezu verzögerungsfrei im Position Control und im Device Control an.

</description>
    <content:encoded><![CDATA[
<p>
Mit dem beigefügten Projekt habe ich eine einfache Ansteuerung der Position von in der Stage View ausgewählten Geräten über meinen MIDI-Controller (Traktor F1) realisiert. Bei schnellen, ruckartigen Werteänderungen stockt <acronym title="Graphical User Interface">GUI</acronym> bis hin zum Einfrieren. Das Stocken betrifft im konkreten Fall unter anderem das Position Control und das Device Control. Hier liegt bei mir die Vermutung nahe, dass bei einer meiner letzten Nutzung im größeren Umfeld deswegen die <acronym title="Graphical User Interface">GUI</acronym> auch komplett abgestürzt ist. Der gezeigte Auszug aus den beigefügten Logs entstammt der ersten <acronym title="Graphical User Interface">GUI</acronym>-Session.<br />
</p>
<pre class="code">2023-09-15 18:44:42,258 [74] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Facade.DeviceProperties.DevicePropertyFacade.&lt;OnProgrammerValueChanged&gt;d__71.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\DeviceProperties\DevicePropertyFacade.cs:Zeile 516.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.&lt;&gt;c.&lt;ThrowAsync&gt;b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()</pre>

<p>
Nutze ich im gleichen Connectionset statt die Fader / Encoder meines MIDI-Controllers die beiden Slider des ebenfalls enthaltenen Softdesks, werden alle Werteänderungen sauber umgesetzt. Sowohl langsame als auch schlagartige Werteänderungen kommen nahezu verzögerungsfrei im Position Control und im Device Control an.<br />
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=4674">
    <title>FS#4674: Ausgangswert eines Buttons wird bei Profillwechsel nicht zurückgesetzt</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=4674</link>
    <dc:date>2026-05-28T16:32:52Z</dc:date>
    <dc:creator>Stefan Kistner</dc:creator>
     <description>

Im beigefügten Projekt habe ich eine Seitenumschalten zwischen zwei Macroboard-Profilen realisiert, indem ich via eines Counters die Nummern der Macroboard-Profile hoch- bzw. herunterzähle. Die Profile im Projekt sind für ein Stream Deck XL gebaut.



Wechsele ich nun die Seite, muss ich die betreffenden Button 4.8 (Seite vor) bzw. 4.7 (Seite zurück) zweimal drücken. Beim Verlassen der Seite wird der Ausgangswert des Button 4.8 bzw. 4.7 von &amp;#8220;True&amp;#8221; nicht mehr zurück auf &amp;#8220;False&amp;#8221; gesetzt. Zu sehen ist dies in dem Connectionset &amp;#8220;Page-Navigation&amp;#8221;.



Ob dieses Problem mit DMXControl 3.3 auch noch besteht, kann ich erst nach der Freigabe der Aplha 8 prüfen. In der Alpha 7 lässt sich das Projekt auf Grund des mittlerweile behobenen Fehlers aus Ticket &amp;#160;FS#4670&amp;#160; nicht öffnen.

</description>
    <content:encoded><![CDATA[
<p>
Im beigefügten Projekt habe ich eine Seitenumschalten zwischen zwei Macroboard-Profilen realisiert, indem ich via eines Counters die Nummern der Macroboard-Profile hoch- bzw. herunterzähle. Die Profile im Projekt sind für ein Stream Deck XL gebaut.
</p>

<p>
Wechsele ich nun die Seite, muss ich die betreffenden Button 4.8 (Seite vor) bzw. 4.7 (Seite zurück) zweimal drücken. Beim Verlassen der Seite wird der Ausgangswert des Button 4.8 bzw. 4.7 von &#8220;True&#8221; nicht mehr zurück auf &#8220;False&#8221; gesetzt. Zu sehen ist dies in dem Connectionset &#8220;Page-Navigation&#8221;.
</p>

<p>
Ob dieses Problem mit DMXControl 3.3 auch noch besteht, kann ich erst nach der Freigabe der Aplha 8 prüfen. In der Alpha 7 lässt sich das Projekt auf Grund des mittlerweile behobenen Fehlers aus Ticket <del>&#160;<a href="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=4670&amp;feed_type=rss1&amp;topic=edit" title="Repariert | Task made private | 100%"  class = "closedtasklink">FS#4670</a>&#160;</del> nicht öffnen.<br />
</p>
]]></content:encoded>
  </item>
    <item rdf:about="https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5581">
    <title>FS#5581: Breite für Executor-Nummer auf mindestens drei Ziffern erhöhen</title>
    <link>https://www.bugs.dmxcontrol-projects.org/index.php?do=details&amp;task_id=5581</link>
    <dc:date>2026-05-25T10:30:44Z</dc:date>
    <dc:creator>Stefan Kistner</dc:creator>
     <description>

Das Feld für die Executor-Nummer sollte mindestens so groß sein, dass drei Ziffern klar angezeigt werden. Diese Zahl kann vergleichsweise schnell erreicht werden.



Wie im beigefügten Screenshot zu sehen, werden aktuell selbst zwei Ziffern nicht vollständig dargestellt. Ich könne daher vorstellen, dass sich die Breite des Feldes an der Breite des Textes orientiert, um so bei wenigen Executoren wiederum noch mehr Platz für den Text zu haben.

</description>
    <content:encoded><![CDATA[
<p>
Das Feld für die Executor-Nummer sollte mindestens so groß sein, dass drei Ziffern klar angezeigt werden. Diese Zahl kann vergleichsweise schnell erreicht werden.
</p>

<p>
Wie im beigefügten Screenshot zu sehen, werden aktuell selbst zwei Ziffern nicht vollständig dargestellt. Ich könne daher vorstellen, dass sich die Breite des Feldes an der Breite des Textes orientiert, um so bei wenigen Executoren wiederum noch mehr Platz für den Text zu haben.<br />
</p>
]]></content:encoded>
  </item>
  </rdf:RDF>
