Eigentlich ist die Anforderung ganz einfach: In einer xml-Datei steht ein Pfad in dem Hex-Dateien abgelegt sind, aus einem angeschlossenen Gerät werden aus dem EEPROM Informationen ausgelesen und ein Dateifilter gesetzt und aus dem definierten Pfad soll die jüngste Datei, die zu dem Filter passt, automatisch ausgewählt werden. Doch leider funktioniert die Vorauswahl nicht, obwohl augenscheinlich der richtige Pfad konfiguriert ist.

Weiterlesen …

Wenn man mit einem Programm die Registrierung auslesen muss, sollte man besonders bei 64-Bit Systemen aufpassen. Öffnet man das Tool regedit bekommt man die  64-Bit-Ansicht der Windows-Registry angezeigt. Soweit so gut.

Öffnet man die Registry aber aus dem Code heraus, kommt es darauf an, wie man das Executable Kompiliert hat. Mit der Einstellung X86 öffnet man die Registry in der 32-Bit-Ansicht. Mit der Einstellung X64 öffnet man die Registry in der 64-Bit-Ansicht. Bei AnyCPU kommt es noch auf die Einstellung unter Prefer 32-Bit an. Richtig: ist hier ein Haken gesetzt, wird die 32-Bit, sonst die 64-Bit-Ansicht geöffnet. Klingt ziemlich verworren? Ist es auch.

Den Abhängigkeiten über das Platform-Target kann man dadurch umgehen, dass man beim Öffnen der Registrierung angibt, in welcher Ansicht man die Registry öffnen will. Und das geht so:

//needed for the registry access
using Microsoft.Win32;
//search in current user
RegistryKey currentUser64 = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, RegistryView.Registry64);						
RegistryKey currentUser32 = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, RegistryView.Registry32);						

 Nützlich kann es bei dieser Verarbeitung noch sein, dass man nach der Architektur des Betriebssystems unterscheidet. Dazu kann der folgende Einzeiler verwendet werden:

Weiterlesen …

Mich erreicht eine Fehlermeldung vom Kunden. Bei bestimmten Geräten wird die Status-LED in der Initialisierungsphase nicht korrekt geschaltet bzw. sie bleibt aus. Ich lasse mir einen Trace schicken und stelle fest, dass beim Auslesen der Daten aus dem EEPROM etwas schief läuft und für die Revision kein Wert zurückkommt. Ich schaue in den Code und entdecke das folgende Schmuckstück Programmierkunst. Diese Abfrage macht sicher nicht das was sie soll.

if (buffer[1] == 0x00)
{
	//answer seems to be ok
	iFeederRevision = Convert.ToInt32(string.Format("{0:x2}{1:x2}", buffer[3], buffer[2]), 16);
}
else if (buffer[1] == 0x00)
{
	iFeederRevision = 1;
}

Ihr kennt das? Ihr habt schreibt euch ein eigenes Steuerelement und leitet dieses von einem vorhandenen Steuerelement ab. Wenn ihr im Visual Studio auf die entsprechende Datei doppelt klickt öffnet sich das Entwurfsfenster.

Für manche Steuerelementerweiterungen mag das Sinn machen. Für manche nicht. Wenn ihr die Codeansicht anzeigen wollt, könnt ihr mit F7 dorthin wechseln oder ihr tragt die folgende Anweisung in den Quellcode ein:

[System.ComponentModel.DesignerCategory("Code")]
public class UptimeTablePanel : Panel, IGUIPanel, IGUIDragAndDrop

„Egal, was der Bediener eingibt, es steht immer nichts in den manuellen Messwerten drinnen“: so lautet die Fehlerbeschreibung beim Kunden. Und tatsächlich es lässt sich nachvollziehen. Man trägt einen Wert ein, verlässt die Zeile bzw. klickt auf Ok und dann verschwindet der wert wieder. Ein Blick in den Code macht auch schnell deutlich, warum das so ist.

if (oNewValue != null)
{
  clsMesBO.TValue = oNewValue.ToString();
}
{
   clsMesBO.TValue = null;
}

Hier fehlt ein else. So wie es programmiert ist, werden alle Werte mit null überschrieben.