Bugtracker DMXControl 3

Das 3Dconnexion-Plugin kann beim Starten der GUI nicht initialisiert und deswegen zur Zeit auch nicht genutzt werden. Das Log der GUI sagt hierzu folgendes:

2020-10-08 13:16:17,904 [Main GUI] ERROR Lumos.GUI.Plugin.PluginManager - Error when initializing Plugin: _3DxPlugin
System.ArgumentException: Das Argument picture muss ein Bild sein, das als Icon verwendet werden kann.
   bei System.Drawing.Icon.Initialize(Int32 width, Int32 height)
   bei System.Drawing.Icon..ctor(Stream stream, Int32 width, Int32 height)
   bei System.Drawing.Icon..ctor(Stream stream)
   bei Lumos3DconnexionPlugin._3DxForm..ctor()
   bei Lumos3DconnexionPlugin._3DxPlugin.initializePlugin()
   bei Lumos.GUI.Plugin.GuiPluginBase.initializePlugin(IGuiPluginContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Plugin\GuiPluginBase.cs:Zeile 52.
   bei Lumos.GUI.Plugin.PluginManager.initializePlugin(Type t) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Plugin\PluginManager.cs:Zeile 581.
   bei Lumos.GUI.Plugin.PluginManager.org.dmxc.lumos.Kernel.AssemblyScan.IAssemblyListener.scanNewType(Type t, EAssemblyType type) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Plugin\PluginManager.cs:Zeile 561.

Das 3Dconnexion Plugin muss auf DMXControl 3.3 portiert und dann wieder dem Installer hinzugefügt werden.

Das Plugin übernimmt nicht die Werte aus dem Programmer, hat man als erstes eine Auswahl von Geräten positioniert, verändert die Position eines einzelnes Geräts dieser Auswahl und wählt dann wieder die ursprünglichen Geräte wieder erneut aus. Der Programmer wird bei der Position auf den Wert 0 zurückgesetzt.

Für genaue Fehlerbeschreibung siehe Thread Pan/Tilt Ausgangsposition verändern im Forum.

Aktiviere ich die Einstellung “Show Taskbar Icon for floating windows” kann ich diese Fenster zwar auf jedem beliebigen Bildschirm maximieren, aber nicht in die Taskleiste minimieren. Letzteres wäre aber gerade für das Arbeiten mit nur einem Bildschirm hilfreich. Zur Zeit muss ich die Fenster immer aus dem Bildschirm “herausschieben”, um im Hauptfenster zu arbeiten.

Wie im beigefügten Bild zu sehen, entspricht die Höhe des Kontextmenüs zur Executor Page im Executor-Fenter nicht den allgemein üblichen Abmessungen. Dies gilt sowohl für das Standard Theme als auch das Dark Theme.

Getestet mit Alpha 3, Build 11

Aktuell kann ich die Größe und Position der Controls nur durch ziehen und schieben verändern, jedoch nicht über die Eingabe von konkreten Werten. Der Punkt “Layout” bleibt trotz eines ausgewählten Controls leer.

Aktuell werden die Buttons für ABS und REL im Device Control nicht angezeigt. Die Breite des Property Grids entspricht aber bereits der neuen Breite.

Getestet mit Build 1503

Aktuell wird jede (Wert-) Änderung in der Stage View protokolliert, also nicht nur Dimmer, sondern auch Farben oder Goborotationen. Lasse ich also über den Abend die Stage View die ganze Zeit mit laufen, wächst das Logfile der GUI auf eine unter Umständen für den PC nicht mehr händelbare Größe an. Daher sollte das Logging für den Normalbetrieb unbedingt deaktiviert werden. Ggf. könnte man drüber nachdenken, das Logging bei Bedarf einzuschalten, wenn man sich auch die Debug-Infos ausgeben lässt.

Wenn bei einem Gobo eines Goborads der step wie folgt aussieht, kann der Goboshake nicht deaktiviert werden.

<step type="gobo" mindmx="5" maxdmx="7" caption="Gobo 1">
  <step for="goboindex" mindmx="5" maxdmx="7" />
  <step for="goborotation" mindmx="32" maxdmx="34" />
  <range type="cw" handler="goboshake" mindmx="60" maxdmx="67" minval="0.1" maxval="5" />
</step>

Werden die untergeordneten step mit “for” entfernt, arbeitet das Goboshake wie gewünscht.

Ein Beispiel für das falsche Verhalten kann mit dem mitgelieferten Martin MAC 700 Profile im 16BT-Modus nachgestellt werden.

Ich habe zwei DMX-Interfaces hinzugefügt und diese dann deaktiviert (siehe Bild 1). Aktualisiere ich die Ansicht, werden zwar beide Interfaces durch die grau hinterlegten Zellen als deaktiviert gekennzeichnet (siehe Bild 2). Der Haken wird aber wieder gesetzt, was dann zu Verwirrung führt.

Dieser Fehler steht aber nicht im Zusammenhang mit Ticket  FS#3864  bzw. darf nicht als solcher verstanden werden.

Im Anhang die Log-Dateien der Sitzung.

Im Log von DMXControl 3.2 Build 1042 ist mit folgender Fehler aufgefallen. Vollständige Logs finden sich im Anhang.

2018-09-06 19:28:14,863 [Log-Thread] ERROR org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode - Unable to process invalid Value 0:    bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractRangesHandlerNode.handleNumericValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractRangesHandlerNode.cs:Zeile 382.
   bei org.dmxc.lumos.Kernel.HAL.Handler.AbstractHandlerNode.handleValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\HAL\Handler\AbstractHandlerNode.cs:Zeile 447.
   bei org.dmxc.lumos.Kernel.HAL.Handler.HandlerRegistry.handlePropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\HAL\Handler\HandlerRegistry.cs:Zeile 329.
   bei org.dmxc.lumos.Kernel.Devices.DeviceBeam.pushPropertyValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Devices\DeviceBeam.cs:Zeile 221.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.afterPropertyValueSet(HALHandleContext ctx, Boolean invokeHal) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 212.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.setCurrentValue(HALHandleContext ctx, Boolean invokeHal) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 201.
   bei org.dmxc.lumos.Kernel.DeviceProperties.AbstractDeviceProperty`1.setCurrentValue(HALHandleContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\DeviceProperties\AbstractDeviceProperty.cs:Zeile 185.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.setPropertyValueInternal(IPropertyValue value, IMixable source) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 692.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.setPropertyValue(IPropertyValue value, IMixable source) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 580.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.processRegisterValues(RunContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 438.
   bei org.dmxc.lumos.Kernel.Run.MainProcessRunable.ActionBag.Invoke(RunContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Run\Thread\MainProcessRunable.cs:Zeile 51.
   bei org.dmxc.lumos.Kernel.Run.MainProcessRunable.processActions(RunContext ctx) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Run\Thread\MainProcessRunable.cs:Zeile 297.
   bei org.dmxc.lumos.Kernel.Run.ThreadWrapper.WrappedStart() in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Run\Thread\ThreadWrapper.cs:Zeile 204.
   bei System.Threading.ThreadHelper.ThreadStart_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.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Threading.ThreadHelper.ThreadStart()

Mit der Beta 5 habe ich häufig insbesondere beim Speichern des aktuellen Projekts das Problem, dass die GUI abstürzt. Folgender Eintrag im Log der GUI zu finden.

2022-12-23 16:24:17,453 [Log-Thread] DEBUG Lumos.GUI.Run.GuiRunManager - InformSaveProject [before=True] took 105 ms
2022-12-23 16:24:17,531 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.User_gClient - UserContext of current User changed
2022-12-23 16:24:17,540 [92] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
System.InvalidOperationException: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
   bei Lumos.GUI.Facade.User.UserContextFacade.ProcessDeviceChangedMessage(UserContextChangedMessage message) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\User\UserContextFacade.cs:Zeile 43.
   bei Lumos.GUI.Facade.GUISession.UserContextFacadeUpdater.<ProcessChange>d__3.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeUpdaters.cs:Zeile 38.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Facade.GUISession.FacadeContainer`2.<ProcessChangeMessage>d__21.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeContainer.cs:Zeile 142.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   bei Lumos.GUI.User.UserManager.<OnUserContextChanged>d__65.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\User\UserManager.cs:Zeile 282.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>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()

Der Kernel führt zu dem Zeitpunkt des Absturz folgende Aktionen aus:

2022-12-23 16:24:17,475 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Saving Project FS#4944 - Master window
2022-12-23 16:24:17,484 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - saveProject KernelInputManager.
2022-12-23 16:24:17,796 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.FileAccessUtil - Deleted D:\Arbeit\MSK event GbR\Software\DMXControl 3.3.0\Kernel\Temp\b42fdf64-174b-4edc-97eb-b4cb45012ba3.tmp
2022-12-23 16:24:17,796 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Project FS#4944 - Master window successfully saved.

Beim Erstellen eines Matrix-Effekts ist mir die GUI abgestürzt. Die Logs mit dem Fehlerbericht sind angehängt.

Folgende Vorgehensweise führt zu einem Absturz der GUI:

• Einfügen eines neuen Device zum Projekt
• Ändern verschiedener Werte in der StageView
• Anschauen dieser Werte in der ChannelOverview
• Direktes Löschen des Geräts aus dem Projekt, ohne den Programmer etc. zurückzusetzen

Dies ist vielleicht nicht ein alltägliches Szenario. Es ist mir beim Überprüfen der DDFs unter die Finger gekommen.

Ändere ich in der Tabellen-Ansicht des Patch-Fensters verschiedene DMX-Adressen stürzt die Matrix-Ansicht ab. Um die Matrix-Ansicht zu sehen, muss das Patch-Fenster einmal geschlossen und wieder neu aufgerufen werden.

Auf Grund einer System.OutOfMemoryException kam es zu einem Absturz der GUI. Logeintrag bei Systemzeit 2018-04-19 20:51:43,531. Log für Kernel und GUI im Anhang beigefügt.

Füge ich Geräte einer vorhandenen Gruppe hinzu, werden die Icons der Devices zwar an der richtigen Stelle in der Stage View platziert. Das Icon einer vorhandenen Gruppe, die dann auch vorher in der Stage View positioniert war, wird hierbei das Icon an die neue Position verschoben. Hierbei macht es keinen Unterschied, ob die Icons in der Stage View gelockt sind oder nicht.

Durch die neuen Master kamen weitere Icons in der sowieso extrem breiten Menüleiste des Project Explorers hinzu. Dadurch rutschen häufiger benötigte Icons noch weiter nach rechts.

Daher wäre der Wunsch unabhängig vom Ticket FS#3360, dass diese vier Icons für die vier Master in ein Dropdown-Menü zusammengefasst werden, dessen Obertitel “Add Master” ist.

Sobald in einem Projekt eine Generic Matrix verwendet wird, werden in der Channel Overview die Adressbereiche der Geräte (mit den blauen Balken) nicht mehr gekennzeichnet. Löscht man die Generic Matrix wieder, werden auch die Adressbereiche wieder angezeigt.

Füge ich das Art-Net-Ausgabeplugin neu hinzu, werden die Send- und Recieve-Universen aus meiner Sicht ungünstig adressiert. Im konkreten sieht das wie folgt aus:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 4 - 7

Device 2

• Send U5 - U7: Universes 8 - 11
• Revice U5 - U7: Universes 12 - 15

Möchte ich nun ein 8-Port Art-Net-Node ansprechen, muss ich hier im Device 2 mindestens die Universen für Send neu sortieren. Ich könnte zwar mein Art-Net-Node auch irgendwie umkonfigurieren, aber persönlich finde ich diese Stückelung innerhalb eines Subnet nicht geschickt. Mein erster Vorschlag wäre folgende Standard-Konfiguration:

Device 1

• Send U1 - U4: Universes 0 - 3
• Revice U1 - U4: Universes 8 - 11

Device 2

• Send U5 - U7: Universes 4 - 7
• Revice U5 - U7: Universes 12 - 15

Ich lege ein neues Art-Net-Interface an oder aktiviere ein ggf. vorhandenes (wieder). In beiden Fällen erscheint im Kernel nach einigen Aktionen in der Stage View die folgende Fehlermeldung:

19:55:34 FATAL MainProcessRunable - Main Runnable seams stuck in an endless loop! You might have to restart DMXC... Please report this!

Sobald diese Fehlermeldung erscheint, kann ich in der GUI war Geräte in der Stage View auswählen. Setze ich aber die Farbe auf einer Gerätegruppe, werden diese Werte nicht mehr von den einzelnen Geräten wiedergegeben. Das Herunterfahren des Kernels klappt dann auch nicht mehr, da dieser keine Kommandos mehr entgegen nimmt.

Die beigefügten Logs zeigen den Ablauf:

1. DMXC 3.3.0 RC4 starten ohne zuvor konfigurierte DMX-Interfaces
2. Beliebiges Projekt laden
3. Art-Net-Interfaces einrichten
4. Ein paar einfache Aktionen in der Stage View
5. Auftauchen des Fehlers
6. Schließen der GUI und manuelles Anstoßen des Beenden des Umbras
7. Hartes Schließen des Kernels

Das Aktivieren und Deaktivieren von Bänken über den Menüpunkt “Bank > Aktive” ist aktuell nicht möglich. Der Befehl wird nicht durchgereicht, sodass sich auch der farbige Balken nicht ändert.

In manchen Situationen kommt es vor, dass die Aktualisierung des Input- und Output-Baumes von außen nicht automatisch angestoßen wird, wenn das Input Assignment Fenster geöffnet ist. Ein Beispiel ist hier das Deaktivieren des Group Masters, wie in meinem Live-Tutorial "Clubshow mit DMXC3" bei 23:36 zu sehen. Diese Verschwinden erst, wenn ich das Fenster schließe und neu öffne. Ein weiteres Beispiel ist, dass die finalen Namen von neu angelegten Cuelists etc. nicht durchgereicht werden, sodass im Baum noch “New Cuelist” steht.

Unabhängig von der Tatsache, dass die beiden zuvor beschriebenen Punkte als Fehler zu werten sind und hierzu noch entsprechende Tickets folgen, wäre hier dennoch ein entsprechender Button hilfreich, um die Aktualisierung beider Bäume analog zum Refresh-Button im Project Explorer auch manuell anstoßen zu können.

Wenn das Ausgabeplugin für Art-Net 4 final ausgeliefert wird, musst der Installer im Installationsverzeichnis nach der alten Version suchen und die relevanten Dateien automatisch entfernen.

Das 3DConnexion-Plugin lässt sich zwar fehlerfrei starten und konfigurieren, die “Anbindung” an die Stage View fehlt bis dato. Das soll heißen, ein in der Stage View ausgewähltes Gerät kann über die 3D-Maus nicht gesteuert werden.

Ich habe ein Gerät mit einer 1×6 Matrix (6 Pixel horizontal in einer Zeile). Ändere ich hier die Ausrichtung der Matrix oder möchte diese auf einer Ebene spiegeln, friert die GUI ein. Nach dem Abschießen der GUI lässt sich der Kernel daraufhin auch nicht mehr per Kommandozeile vollständig herunter fahren.

Die Software kann nachverfolgen, ob Änderungen am Projekt vorgenommen wurden. Dies soll in der GUI visualisiert werden. Beim QRM-Meeting vom 16.03.2021 wurde abgestimmt, dass

• Hinter dem Dateiname wird ein Sternchen eingefügt (*), zum Beispiel bei MyProject.zip*
• Das Speichern-Symbol (nicht das Speichern unter Symbol) erhält ein rotes Flag, wenn das Projekt geändert ist

Ändere ich bei einem bereits einmal gespeicherten und wieder geöffneten Projekt zum Beispiel bei einer Auswahl von Devices in der Stage View die Einstellung “Enabled”, so friet die GUI ein. Um weiterarbeiten zu können, muss ich den Prozess “hart” über den Task Manager beenden.

Dieses Ticket beschreibt den eigentlich beobachteten Fehler aus Ticket FS#4683. Im Nachhinein betrachtet war es dort die gleiche Vorgehensweise, nur eben mit dem Eintrag “Mirror horizontal”. Hier war das Projekt zum Zeitpunkt des Auftreten des Fehlers zuvor ebenfalls innerhalb der Sitzung nochmal neu geladen worden.

Im Anhang befindet sich das Projekt sowie die Logfiles, wobei die der GUI nur bis zu dem Zeitpunkt erfasst sind, bis diese über den Taskamanager beendet wurde.

Nach der Behebung von  FS#5168  kann ich im Draw Bitmap Node zwar nun wieder Schriftart und -größe wählen und sie werden vom Node auch gespeichert, jedoch werden diese Änderung nicht mehr an das Macroboard weitergegeben - sowohl hardwareseitig auf dem Macroboard selbst als auch softwareseitig in der Anzeige der Macroboard Profilen. Auch ein Speichern und Neuladen des Projekts schafft keine Abhilfe.

Die Farbe des Textes und auch die Inhalte werden dagegen erwartungsgemäß aktualisiert.

In dem beigefügten Projekt habe ich ein einfaches Beispiel generiert. Eigentlich sollte hier der Button 1.1 des Macro Boards den Text in der Schriftart “Arial” in der Schriftgröße “20px” anzeigen.

Getestet mit DMXControl 3.2.1, Build 600

Lege einen beliebigen Effekt im Device Control auf eine beliebige Funktion eines Geräts, werden jegliche Änderungen an den Parametern des Effekts in der Stage View und der DMX-Ausgabe nicht umgesetzt. Einzig der Effektvisualiser generiert die richtige Vorschau auf Basis der gesetzten Parameter.

Speichere ich den Effekt in einer Cue ab, so wird dieser entsprechend der im Blindflug eingestellten Parameter beim Abspielen der Cue richtig wiedergegeben und auch beim Editieren der Cue zeigt die Stage View den Effekt richtig an. Alle folgenden Änderungen registriert die Stage View und die DMX-Ausgabe jedoch nicht.

Logs der Sitzung siehe Anhang. Auffällig sind hier die beiden folgenden Einträge, welche nach dem Aufruf eines leeren Projekts erschienen:

2020-01-15 20:21:02,619 [305] ERROR org.dmxc.lumos.Kernel.Command.Command - Error while invoking Command: getEffectVectorsFromProgrammer, Paras: 
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 70.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 121.
2020-01-15 20:21:02,647 [305] ERROR org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory - TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.getEffectVectorsFromProgrammer(String sessionName, String groupID, String propID, String effectID) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 2262.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 60.

Ich habe in einem Projekt drei Device Groups mit jeweils unterschiedlicher Anzahl von Geräten. Füge ich einen beliebigen Effekt auf die alle gemeinsam ausgewählten Device Groups und wähle als Group Handling “Parallel Groups”, werden Änderungen am Effekt fortan immer nur auf einer der drei Device Groups wiedergegeben. Die verbleibenden zwei Deivce Groups geben des Effekt mit den ursprünglichen Parametern wieder.

Um die Änderung auf allen ausgewählten Device Groups sehen zu können, muss ich entweder:

• die Einstellung für das Group Handling ändern
• den Effekt in einer Cue abspeichern und diese dann neu in den Programmer laden

In beiden Fällen tritt aber der oben beschriebe Fehler direkt wieder auf, sobald ich einen Parameter des Effekts ändere.

Zur Darstellung des Fehlers ist im Anhang ein entsprechendes Beispielprojekt mit einer vorbereiteten Cuelist zu finden. Zur Reproduktion einfach die Cue in den Programmer laden und die Parameter des Triangle-Effekts ändern.

Getestet mit Build 1492

Ändere ich bei einer aktiven Cuelist während der Ausführung eines Fades die Fadezeit, stoppt die Cuelist.

Ich möchte die Verknüpfungen zu den einzelnen Anwendungen von DMXControl 3 im Startmenü gerne vom Installer im folgenden Pfad ablegen lassen:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.3.0\

Dass es sich hier nun um das Verzeichnis für alle Benutzer handelt, sei erstmal irrelevant, weil ich dies ja nicht explizit festlegen kann.

Scheinbar auf Grund der existierenden Registry-Einträge für die ebenfalls auf meinen PCs installierte 3.2.3 schlägt der Installer der 3.3.0 immer folgenden Pfad vor:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.2.3\

Egal ob ich den Pfad auf meinen Wunschpfad ändere (im Installer trage ich ja dann nur “DMXControl 3.3.0” ein) oder ich sage generell, dass der Installer bitte keine neuen Verknüpfungen anlegen soll - in beiden Fällen landen alle Verknüpfungen im Startmenü immer im “alten” Verzeichnis, also im Verzeichnis “DMXControl 3.2.3”.

Im Anhang die Log-Datei des Installers.

Bei der Bearbeitung des Tickets bitte beachten, dass im QRM22.1 grundlegende Anpassungen am Installer beschlossen wurden, welche bis zum Release auch umgesetzt werden sollen. Hierzu gehören unter anderem die Tickets FS#2763 und FS#4708.

In dem Projekt zu  FS#3958  ist zu beobachten, dass das Anlegen und Löschen von Cuelists jeweils eine Zeit von > 30 Sekunden in Anspruch nimmt, wo dann auch insbesondere die GUI nicht ansprechbar ist und Windows den Status “keine Rückmeldung” erhält.

Der Timecode-Player erwartet, dass die im Cuelist-Track verwendeten Cuelists bei allen Cues mit dem Timecode-Trigger versehen sind. Dies schließt auch die Cuelist Defaults ein.

Daher sollten die Defaults für neue Cues auf Rückfrage automatisch aktualisiert werden, sobald man die Cuelist einem Cuelist-Track im Timecode-Player hinzufügt.

Öffne ich ein Softdesk im Live Mode, bietet mir das Kontextmenü folgende Einträge:

• Fullscreen
• Normal
• Close

Insbesondere beim Verlassen des Fullscreen-Modus des Softdesks ist diese Aufteilung verwirrend, weil man den Eintrag Close im Fullscreen-Modus auch mit “beende Fullscreen” verstehen kann - bis man nach dem Klick hierauf feststellt, dass damit das Softdesk direkt geschlossen wird. Nebenbei “funkt” auch das aktuelle Kontextmenü bei der Touch-Bedienung dazwischen und man schließt versehentlich ein Softdesk, sofern die Funktion für das Aufrufen des Kontextmenüs über Touch (noch) aktiviert ist.

Mit persönlich fallen hierzu folgende Lösungsansätze ein, wobei dies nur ein Brainstorming ist und keineswegs alle Verschläge auch umgesetzt werden sollen:

• Das Kontextmenü wird mit anderen Begriffen kontextabhängig (also Fullscreen oder Normal / Window mode (Fenstermodus)) gestaltet, sodass die Einträge Open Fullscreen und Leave Fullscreen jeweils wechseln.
• Der Eintrag Close wird durch einen Gruppierungs- / Gliederungsstrich von den beiden Eintragen zur Anzeigeart getrennt.
• Im Fullscreen-Modus gibt es nur einen Eintrag zum Verlassen des Fullscreens. Das Schließen wird erst im normalen Fenstermodus möglich.
• Der Eintrag Normal wird in Window view umbenannt.

Durch die Einführung von neuen Fanning-Operatoren wird die Liste der möglichen Fannings im Tooltip “Value not valid” immer länger. Wir sind aktuell bei 14 Fannings angelangt. Hier sollte die Anzahl auf ein paar gebräuchliche Fannings reduziert werden, zum Beispiel auf

• -8 # 8
• -8 > 8

Alternativ greift der Tooltip nur den Fanningoperator auf, den der Nutzer aktuell verwenden möchte. Damit lässt sich der Tooltip auf 4 Zeilen reduzieren.