Die Umstellung wurde durch die (sehr zähen und langsam fortschreitenden - ich weiß … leider!) Arbeiten am neuen Zeitplaner sinnvoll. Allerdings habe ich trotz erfolgreicher Umstellung der aktuellen Funktionalitäten noch nicht das endgültige Datenbankschema erreicht. Daher wird es vorerst auch kein Preview geben - ich selbst nutze die Version noch nicht produktiv. Nach einer Aktualisierung auf das neue Ablagesystem gibt es auch kein Zurück mehr und ich möchte nicht schon in der Beta Phase Schemamigrationen machen müssen. Etwas Geduld also…

Die Wahl genau dieser Datenbank ergibt sich aus dem Umfeld (privates Lernprojekt, tagesaktuelle Anforderungen) und daher sind andere Datenbanken wie MySQL und Konsorten kein Thema. Die Implementierung ist zwar an vielen Stellen ADO.NET basierend allgemein gehalten, allerdings musste ich insbesondere aus Performancegründen bei der Programmzeitschrift einige Kompromisse schliessen und direkt gegen SqlCe programmieren. Auf der einen Seite stehe ich noch ganz am Anfang und möchte daher nicht die Hoffnung aufgeben, dass bis zum Release von VCR.NET 4.0 etwas Ordentliches daraus wird. Aber auf der anderen Seite ist das für 4.0 nur ein kleiner Nebenschauplatz, an dem ich eigentlich gar nicht lange verweilen wollte. Naja, man kann es sich selbst auch nicht Recht machen, oder…

Soweit zur Information

Jochen

Sorry

Jochen

Update 05.03.2012: Alles wieder wie es sein soll, Dank an den Admin (TheWatcher)!

Im initialen Zustand wird die Auswahlliste als ListBox dargestellt - ohne die typische Sondervisualisierung der ComboBox mit dem Auswahlfeld zum Aufklappen. Verändert sich die Auswahl, so übernimmt die Listbox die Anzeige - auf Aspekte des ausgewählten Eintrags kann im XAML wie gewohnt referenziert werden, wie das Bild links oben und der relative Pfad des Bildes daneben zeigt. Das ist nun wirklich nichts Besonderes bis hierhin.

Die Besonderheit zeigt sich aber, wenn man die Auswahl bestätigt. Die ListBox klappt dann scheinbar zu und zeigt nun nur noch den ausgewählten Eintrag.

Das Beispiel kann man sich selbst einmal hier anschauen, die Quellen gibt es hier. Es handelt sich wirklich nur um eine sehr elementare Implementierung, sicher nicht um ein vollwertiges Control. Was tut das Beispiel jetzt schon:

• Beim Starten ist einer der drei Alternativen ausgewählt - sieht im Beispiel etwas häßlich aus, da meine Beispielbilder einen teilweise transparenten Hintergrund haben und die Auswahleinfärbung der Listbox auch im zugeklappten Modus erscheint: einfach vorstellen, dass der Hintergrund der Visualisierungselemente nicht transparent ist (man kann irgendein FrameworkElement verwenden).
• In der oberen Zeile wird die Auswahl zur Demonstration als Bild und Pfad zusätzlich angezeigt.
• Ein einfacher Klick auf die gewählte Alternative (großes Bild) öffnet die Auswahlliste.
• Die Navigation in der Liste mit Maus oder Tastatur verändert die Auswahl, insbesondere kann diese wie gewohnt mit Strg-Click aufgehoben werden.
• Ein Doppelklick oder die Taste ENTER beendet die Auswahl und schließt die Liste, es wird nun die letzte Auswahl angezeigt.
• Die Eingabe des Pfades in der oberen Zeile kann zur Änderung der Auswahl verwendet werden - uh, Injection Attack möglich, schert hier aber nicht.
• Hat die zugeklappte Liste den Fokus, so kann die Auswahl weiterhin mit der Maus verändert werden - die Liste klappt dazu automatisch auf.
• Im XAML der Seite sieht man, dass die Auswahl vorbelegt werden kann, was natürlich optional ist.

Happy Coding

Jochen

Viel Erfolg

Jochen

Zuerst einmal kann das Testprogramm auch ohne DVB.NET / VCR.NET Installation ausgeführt werden, wenn Silverlight 4 im Web Browser unterstützt wird. Dazu kann man die Startseite des Testprogramms direkt auf meiner Web Site aufrufen. Zwar geht das Planen nicht ohne Geräteprofile, aber auch dafür braucht man keine DVB.NET Installation. Ich habe die Beispielprofile, die auch in der Beschreibung des Zeitplaners referenziert werden, zum Download bereit gestellt. Einfach irgendwo hin lokal kopieren und von dort in das Testprogramm laden - los geht es.

Für den rein lokalen Betrieb einfach die XAP und HTML vom Download Bereich auf die Festplatte kopieren - bevorzugt in das Installationsverzeichnis des VER.NET Recordings Service, in den Beispieltexten wurde die start.html unter dem Namen ScheduleUITestPage.html abgelegt, der Name der Silverlight XAP darf nicht verändert werden. Für den VCR.NET Betrieb benötigt man allerdings zumindest das Halloween 2011 Preview der Version 4.0, damit die Aufzeichnungen und Aufgaben ausgelesen werden können - DVB.NET und VCR.NET.

Bis bald

Jochen

Bis bald (hoffentlich nicht erst wieder in einem Monat)

Jochen

Viel Spaß

Jochen

So weit zur Information

Jochen

Viel Spaß

Jochen

Viel Spaß

Jochen

Dabei ist auch eine neue Infrastruktur für die Anbindung von BDA Geräten entstanden, die mit DVB.NET 3.9 zwar vorbereitet, aber noch nicht vollendet wurde. Aber wie will ich nun sicherstellen, dass bestehende Installation ohne viel Aufwand weiterlaufen? Nun, der Plan sieht drei Optionen vor.

Zum einen wird DVB.NET 4.0 alle 3.9 Geräteprofile einfach unverändert weiter nutzen können. Beim Laden wird automatisch eine entsprechende Anpassung vorgenommen, die sich aber nur zur Laufzeit im Speicher wiederspiegelt und keinen Einfluss auf das gespeicherte Profil hat. Nach der Regel never touch a running system kann man damit eventuell ewig klarkommen.

Allerdings kann die Konfiguration eines solchen Profils nicht mehr verändert werden. Alle Einstellungen werden als nur lesbar angezeigt und eine Veränderung unterbunden. Es ist aber möglich, im Pflegedialog die Implementierung von vor 3.9 auf ab 4.0 zu verändern. Dabei wird dann genau die oben beschriebene automatische Anpassung vorgenommen und in das Pflegeformular übernommen - das gilt nur für BDA Geräte, die Nexus bleibt wie gehabt ein anderes Ding. Erst die Speicherung ändert dann das Profil auf der Festplatte. Das ist dann der Punkt, an dem es nicht mehr von DVB.NET 3.9 verwendet werden kann - ansonsten ist eine Parallelinstallation der beiden Versionen ohne Probleme möglich.

Bleibt schließlich noch die Möglichkeit, ein Geräteprofil einfach neu Anzulegen. Ich hoffe, dass der neue Pflegedialog die Auswahl der benötigten Einstellung deutlich vereinfacht - das wird die Zeit zeigen.

Auf jeden Fall hiermit die Nachricht: DVB.NET 4.0 wird kommen!

Bis dann

Jochen

Es sind noch einige Punkte offen, die werde ich in Service Pack 3 angehen. Eine Version 4.0 steht leider immer noch in den Sternen.

Viel Spaß

Jochen

USB Geräte habe die Angewohnheit, bei vielen normalen Gelegenheiten die eindeutigen Namen (Moniker) und Gerätepfade zu ändern. Damit versagt in vielen Fällen der DVB.NET Grundalgorithmus, Geräte über den eindeutigen BDA Namen nachzuschlagen- bei PCI Geräten ist es besser, aber die Problematik ist grundsätzlich die selbe.

Seit einiger Zeit kann in einem BDA Geräteprofil die Einstellung IgnoreMoniker von der Voreinstellung false auf true gesetzt werden. Ist dies der Fall, so versucht DVB.NET erst gar nicht, einen eindeutigen Namen zu verwenden, sondern geht direkt auf die Anzeigenamen der Filter. Zusammen mit den in den anderen Artikeln beschriebenen Neuerung im Service Pack 2 greift diese Lösung in vielen Fällen. Zum einen sind Geräte mit gleichen Anzeigenamen zusätzlich durchnummeriert. Zum anderen erfolgt diese Nummerierung auf Basis der Gerätepfade, so dass insbesondere bei USB Geräten die Tuner und Capture Filter in der gleichen Reihenfolge angeordnet bleiben - der dritte Tuner Filter gehört zum dritten Capture Filter, man weiß halt nur nicht, zu welchem Gerät konkret. Dieses Verhalten muss zwar noch mit verschiedenen BDA Geräten verifiziert werden, scheint aber in der Tat DVB.NET an dieser Stelle zu helfen, mehrere gleichartige USB Geräte stabil zu verwalten.

So, das war erst einmal der letzte Artikel zu Thema - Rückfragen und Diskussionen bitte im Forum.

Ciao

Jochen

In vielen Fällen ist es bei mehreren gleichartigen Geräten im System so, dass diese die gleichen BDA Anzeigenamen verwenden und so in der Auswahl nicht unterschieden werden können - das gilt sowohl für PCI als auch für USB basierte Hardware. Erschwerend kommt hinzu, dass im Allgemeinen passende Pärchen von Tuner und Capture Filter ausgewählt werden müssen. Hat man zwei Karten, so gibt es zwei mögliche Kombinationen zur Auswahl. Bei drei sind es schon 6, bei vier 24 und so weiter. Die schlechte Nachricht vorweg: die Auswahl der richtigen Kombination bleibt weiterhin dem Anwender überlassen. Sorry!

Immerhin gibt es seit Service Pack 2 eine leicht veränderte Anzeige zur Auswahl der Filter: DVB.NET fasst nun Geräte mit identischem Namen zusammen und sortiert diese nach dem zugehörigen Gerätepfad des Windows Gerätes (Device) - zur Erinnerung: dieses wird nun immer zu jedem Filter ermittelt. Gemäß dieser Sortierung erfolgt eine Nummerierung der Art (1), (2), etc., die zur Ergänzung der Anzeigenamen verwendet wird. Ändern sich die Gerätepfade nicht, so bleibt diese permanent stabil und eine gleiche Nummer bezeichnet auch das gleiche Gerät.

Was ist denn dann, wenn sich die Nummer doch ändert, etwa durch eine Treiberinstallation oder bei USB Geräten durch einen Neustart des Rechners, eventuell sogar einfach nur durch Vertauschen der USB Ports? Nun, DVB.NET hat dafür nicht wirklich eine Lösung. Aber vielleicht ist das für den Normalbetrieb auch gar nicht notwendig. Wenn mehrere Profile entsprechend konfiguriert sind und die eindeutigen Namen ändern sich, dann kann DVB.NET immer noch eine Auflösung über den Anzeigenamen samt Nummer versuchen. Nun die gute Nachricht: zumindest für USB Geräte (und scheinbar auch für einige PCI Geräte) haben die Gerätepfad für zusammengehörige Filterpaare eine gewisse Symmetrie. Die Sortierung wird vielleicht die Anzeigenamen (1) und (2) vertauschen, dies aber simultan für Tuner und Capture Filter. Oder kurz ausgedrückt: selbst bei einer Vertauschung hat man immer noch korrekt konfigurierte Profile, nur dass diese nun evtl. andere Geräte ansprechen - da dieser aber identisch sind, ist dies im realen Leben möglicherweise gar kein Problem.

Nun gut, zwei weitere Wermutstropfen gibt es noch - einer in einem Folgeartikel, der andere hier: die Nummerierung beginnt, wenn mindestens zwei Geräte mit gleichen Anzeigenamen vorhanden sind. Der Nummernzusatz hängt von der Anzahl der gleichartigen Geräte ab und ist bei bis zu 9 Geräten (1) bis (9) und dann (01) bis zur Anzahl der Geräte. Das bedeutet, dass der Sprung von einem zu zwei Geräten (und umgekehrt) sowie von 9 zu 10 (und umgekehrt) eine Neukonfiguration des Geräteprofils erforderlich machen kann - ich würde es zumindest empfehlen. Bei Verwendung ständig wechselnder USB Konfigurationen kann dies lästig werden. Sollte das tatsächlich mal ein Problem werden, denke ich darüber nach. Die Wahrscheinlichkeit ist aber nicht wirklich gigantisch…

Tschüss

Jochen

Die Implementierung der BDA Anbindung in DVB.NET ist etwas eigenartig und kann einen Hinweis auf das geben, was ich in diesem Artikel kurz vorstellen möchte. Wenn der BDA Empfangsgraph aufgebaut wird, wird in diesem zuerst der im Geräteprofil konfigurierte Tuner Filter angelegt. Der Tuner wird allerdings nicht mit anderen Filtern verbunden. Anders als der Capture Filter, dessen Eingang zum Network Provider geht und an dessen Ausgang DVB.NET den (Transport Stream) Datenstrom abgreift. Der Tuner wird nun nur noch verwendet, um die Empfangsparamter festzulegen.

Ich war etwas überrascht, als ich ein Gerät in die Hand bekam, das tatsächlich nur einen Tuner Filter anbietet - so gesehen bei dem MSI DigiVox mini Deluxe DVB-T Stick. Schaut man sich die Implementierung an, so kann man zu der Ansicht kommen, dass tatsächlich einer der beiden Filter mehr oder weniger überflüssig ist - nur einer befindet sich im Datenfluss des DirectShow Graphen. Beginnend mit Service Pack 2 kommt DVB.NET zumindest mit der Situation klar, bei der es keinen Capture Filter gibt: hier wird nun der Tuner Filter zwischen Network Provider und Datenstromverbraucher geklemmt und parallel weiterhin zur Steuerung der Empfangsparameter verwendet.

Immer was Neues halt…

Jochen

In den vorherigen Versionen von DVB.NET erfolgte die Auswahl der BDA Filter ausschließlich über die Anzeigenamen, die bei der BDA Registrierung hinterlegt wurden. Nun hat es sich aber gezeigt, dass es Geräte gibt, die einen solchen Namen gar nicht zur Verfügung stellen - gesehen beim Cinergy T-Stick MKII.

Ab Service Pack 2 ermittelt DVB.NET zu jedem BDA Filter grundsätzlich das zugehörige Windows Gerät (Device). Ist dem Filter kein registrierter Anzeigename zugeordnet, so wird der des Gerätes ermittelt - diesen gibt es wohl immer. Nun können auch Geräte mit diesem besonderen Verhalten ganz normal mit DVB.NET genutzt werden.

So long

Jochen

Als DVB.NET vor langer Zeit um die Möglichkeit erweitert wurde, grundsätzlich beliebige BDA DVB Geräte zu nutzen, wurde zur Festlegung der zu verwendende Hardware bestimmt, dass eine Kombination von Tuner und Capture Filter ausgewählt werden musste. Ohne auf die volle Historie einzugehen, hier die aktuelle Implementierung in der Grundfassung - auf einige Feinheiten und -einstellungen gehe ich in den späteren Artikeln ein.

Dem Anwender werden die Filter jeweils einer Art als Liste angeboten. Diese Liste zeigt die Namen, wie sie in der BDA Registrierung hinterlegt wurden. Zusätzlich merkt sich DVB.NET bei einer Auswahl aber auch den eindeutigen Namen (BDA Moniker) - der Grund für dieses Verhalten wird später in dem Artikel deutlicher, in dem es um den Einsatz mehrerer gleichartiger Geräte in einem Rechner geht.

Wenn das Gerät später einmal benötigt wird, versucht DVB.NET dieses zuerst über den kryptischen (i.e. maschinen- aber weniger menschenlesbar) eindeutigen Namen zu ermitteln. Bei PCI Geräten ändert sich dieser im Allgemeinen erst, wenn eine neue Treiberversion installiert wird - dann auch nicht immer. DVB.NET erkennt diese Situation und fällt dann auf die Suche nach dem Anzeigenamen zurück. Dieser Mechanismus funktioniert eigentlich sehr gut, wenn man nur eine Karte einsetzt. Lediglich wenn eine neue Treiberversion auch einen neuen Anzeigenamen vergibt ist DVB.NET verloren - auch diese Situation habe ich schon erlebt. Hier hilft nur, im Geräteprofil die Auswahl des Gerätes zu erneuern.

Grundsätzlich empfehle ich, nach einer Aktualisierung der Gerätetreiber im Adminwerkzeug vorbeizuschauen und die Filter einmal neu auszuwählen - erst verwerfen und dann neu aus der Liste auswählen. Aber wie gesagt: eine vollständige Änderung ist selten und so oft gibt es ja auch keine neuen Treiberversionen.

So, das waren die Grundlagen. Jetzt geht es in den nächsten Kapiteln an die besonderen Spielchen der Hersteller - ich versuche, mich dabei immer auf ein Thema zu beschränken, also lieber einen Artikel mehr als zu viel Text in einem.

Jochen

Ich habe mir daher mal einige Unterlagen zusammen gesucht (vor allem über diesen Einstieg) sowie das alte Mindstorms SDK von Lego installiert. Da ich aber immer auch daran interessiert bin, die Dinge hinter der Fassade zu verstehen, habe ich auf Basis der LASM Dokumentation begonnen, einen Disassembler für Spybotics Programme zu schreiben. Dieser erlaubt es, das aktuelle Programm (die aktuelle Mission) im dem Spybotic anzuschauen (egal, ob eine der vorderfinierten Missionen, eine mit der beliegenden Software erstellen Mission oder ein völlig eigenständiges Programm, das man etwa mit BrickCC zusammengestellt hat). Das sieht dann etwa so aus (hier eigene Spielereien):

Das Programm ist alles andere als fertig und hängt sich am und an und vor allem beim Beenden auch mal auf (ich glaube aber, dass die Ursache dabei die COM Schnittstellenbibliothek ist, die mit dem SDK kommt). Aber wen’s interessiert, hier ein Setup für Windows (ich habe es unter Vista eingesetzt). Man braucht natürlich mindestens einen Spybotic am besten mit funktionierender Originalanwendung (inklusive dem seriellen Anschluss), die COM Schnittstellenbibliothek aus dem SDK (am besten einfach das ganze SDK installieren) und Microsoft .NET 4.0 (Client Profile). Die Installation enthält auch die Quelltexte auf Basis von Visual Studio 2010, alle Quellen sind (wie von dieser Seite vermutlich schon gewohnt) in C#. Benutzung selbstverständlich völlig ohne Gewähr…

Bin ja mal gespannt, ob noch jemand an so altem Kram interessiert ist…

Jochen

public static class Summer
{
public static long Sum( IEnumerable summer )
{
if (summer == null)
return 0;

return res;
}
}

Dieser Code wird von einem Testprogramm mit verschiedenen Parametern aufgerufen:

const int n = 10000000;

var asArray = all.ToArray();
var asList = all.ToList();
var asHash = new HashSet( all );

Dass die ermittelten Laufzeiten unterschiedlich sind (104 Millisekunden für das Feld, 123 für die Liste und 155 für den HashSet auf meinem x86 Vista) ist in Ordnung und ohne Relevanz. Was aber erst einmal extrem überrascht ist folgendes: diese Zeiten ergeben sich, wenn man im Testprogramm immer genau eine der Implementierungen verwendet. Werden alle drei hintereinander in die Methode der Bibliothek geschickt (etwa erst Feld, dann Liste, dann HashSet), so zeigt sich ein erheblicher Unterschied.

Wird das Feld als erstes verwendet, so ist die Laufzeit weiterhin 104ms. Wird allerdings eine beliebige andere Liste vorher aufgerufen, so landen wir plötzlich bei 170ms - das ist 63% mehr! Bei Liste und HashSet sind es immerhin noch 33% (123ms auf 175ms respektive 155ms auf 206ms). Wie kann so etwas sein? Es wird doch immer der selbe Code ausgeführt?

Die Antwort findet sich in diesem Quellcode von Microsoft. Im Endeffekt läuft es auf folgendes hinaus: wenn eine Methode einer Schnittstelle aufgerufen wird, so muss .NET herausfinden, welche Klassenmethode tatsächlich dazu gehört - dazu im Anhang ein kleiner Exkurs in die Legacy Welt von COM und MFC. Der JITter erzeugt nun für jede Methode jeder Schnittstelle ein spezielles Stück Code. Dieser Code ermittelt die Objektinstanz zur Klasse und darüber ein weiteres dynamisch erzeugtes Codefragment, das zur korrekten Methode in der Klasse verzweigt. Das Nachschlagen von Klasse zu letzterem Codefragment geschieht über eine Hashtable (mit 4096 Einträgen). Ist beim ersten Aufruf ein solcher Eintrag nicht vorhanden, so wird er automatisch erzeugt.

Da diese Nachschlageoperation selbst bei vorhandenem Eintrag in der Hashtable teuer ist, verwendet .NET einen kleinen Trick: der erste erzeugte Eintrag wird statisch geprüft. Ein direkter Vergleich auf die Klasse führt direkt zur Umlenkung. Daher der beobachtete Effekt, dass jeweils der erste Aufruf in Normalzeit abläuft und lediglich die Schnittstellen auf andere Klassen verzögert werden.

Leider ist das noch nicht die ganze Wahrheit, denn .NET verwendet eine Optimierung: wenn bei einem Aufruf nicht diese erste Schnittstelle verwendet wird, so wird ein Zähler verändert. Nach etwa 100 Fehlversuchen wird dann die Prüfung auf die erste Schnittstelle umgangen und direkt auf die Nachschlageoperation der Hashtabelle verwiesen. Würde man im Beispiel also etwa die Sequenz Feld, Liste, HashSet, Feld verwenden, so wäre bei der zweiten Nutzung des Feldes auch hier wieder die Verlangsamung zu beobachten. Wohlgemerkt: zwei identische Aufrufe unterscheiden sich in der Laufzeit um 63% - reproduzierbar!

Richtig kritisch würde es, wenn eine ständige Hash Kollision entstehen würde, da dann der Eintrag der Hashtabelle ständig neu ermittelt werden müßte. Bei 4096 Einträgen nicht wirklich wahrscheinlich, oder? Nun, der Effekt tritt natürlich nur in Szenarien auf, in denen die neben dem Aufruf der Schnittstellenmethoden (hier MoveNext und Current) sehr wenig anderes gemacht wird. In diesem Sinne ist das Beispiel natürlich gemein - aber sicher nicht exotisch! Ich würde sogar soweit gehen, dieses Feature als einen LINQ Killer zu bezeichnen. Gerade bei Verwendung von LINQ werden Schnittstellenmethoden in extremster Weise wiederverwendet und LINQ Operationen dadurch langsamer als nötig - vermutlich im Normalfall unmerklich. Ich habe mir jetzt nicht die Mühe gemacht alle Kommentare von Microsoft im obigen Source Code zu prüfen, aber es kann sein, dass diese Verwaltung mindestens Thread-übergreifen evtl. aber sogar für alle AppDomains in einem Prozess gemeinsam erfolgt. Hier könnte es zu unerwünschten Seiteneffekten durch völlig anderen Code kommen - etwa mehrere virtuelle Verzeichnisse in einem IIS Application Pool.

Soweit dazu

Jochen

Nun der versprochene Exkurs COM / MFC: programmiert man COM Objekte in C++ mit MFC / ATL, so können diese mehrere Schnittstellen unterstützen. Eine COM Schnittstelle wird dabei im Allgemeinen (Ausnahmen bestätigen die Regeln) als innere Klassen implementiert. Ein Aufruf auf eine Schnittstellenmethode erfolgt de facto mit einem für diese innere Klasse und damit Schnittstelle individuellen this Zeiger. Alle Schnittstellenmethoden wissen dies aber und korrigieren den Zeiger entsprechend - gemäß dem Offset der inneren Klasse in dem COM Objekt. Mit diesem veränderten this Zeiger kann dann transparent ein Aufruf einer Methode der eigentlichen Klasse erfolgen. Der Unterschied zu .NET ist allerdings, dass nun ein Zeiger auf eine Schnittstelle nicht mehr einfach mit einem Zeiger auf eine andere Klasse oder das COM Objekt verglichen werden kann (== aka ReferenceEquals) um festzustellen, dass tatsächlich mit einer identischen Objektinstanz gearbeitet wird. COM hat dazu eine einfache, aber nicht ganz billige Regel: zum Vergleich muss zwingend ein QueryInterface auf die IUnknown Schnittstelle herangezogen werden.

.NET hat das Problem anders gelöst und wohl die Prämisse gesetzt, dass der this Zeiger bei jedem Aufruf jeder Schnittstellenmethode identisch zur Objektreferenz sein muss. Die COM / MFC / ATL Codefragmente, die bei C++ der Compiler erzeugt, muss nun der JITter anlegen - mit den beschriebenen Nachteilen. Schön ist, dass man nun kein QueryInterface für ReferenceEquals / == braucht. Ich halte diesen Ansatz aber für extrem bedenklich und würde (wäre ich bei Microsoft für diesen .NET Teil zuständig, was ich glücklicherweise nicht bin) über einen BSTR artigen Ansatz nachdenken. Die Idee läßt sich wie folgt beschreiben: jede Schnittstelle zeigt auf eine eigene kleine Implementierung, bei der eine COM / MFC / ATL ähnliche Umsetzung erfolgt. Diese Umsetzung kann einmalig vom JITter für jede Schnittstelle jeder Klasse erstellt werden - wir sind dann weg von den Methodenaufrufen! Zu jeder Objektinstanz im Speicher wird vor den heutigen Objektdaten ein Zeiger auf die primäre Instanz (der Klasse) festgehalten - bei Verwendung der primären Klassenschnittstelle wäre dies dann genau der this Zeiger selbst. Ein ReferenceEquals müßte dann allerdings für beide Objekte eine zusätzlichen Speicherzugriff ausführen, bevor ein Vergleich stattfinden kann. Und jede Objektinstanz würde 4 / 8 Bytes größer. Schaue ich mir aber den heutigen Effekt und die Forcierung von LINQ an, scheint es mir durchaus wert, diese Richtung nicht von vorneherein auszuschliessen - mal unabhängig davon, dass ich natürlich nur die Spitze des Eisbergs sehe und es viele .NET Interna geben kann, die eine solche Implementierung grundsätzlich ausschließen.

Viel Spaß

Jochen

Jochen

Man kann es sich natürlich auch Online abschauen (na gut: eine Bedienungsanleitung gibt es nicht und ohne wird es schwer) und den Quellcode gibt es selbstverständlich auch. Meine Lerneffekte waren so in etwa:

* Darstellen der Bausteine auf Basis eines einzigen Controls über verschiedene Styles.
* Arbeiten mit ContentTemplates und dynamischen Elementen darin.
* Lokalisieren von Elementen über TransformToVisual / TransformBounds.
* Einsatz der Viewbox zur sauberen Skalierung von freien Zeichnungen (der Gattern) in die gewünschten Bereiche.
* Drucken und dabei Skalieren mit der Viewbox sowie das Kennenlernen einiger UpdateLayout Fallstricke.
* Speichern in und Laden aus Dateien im lokalen Dateisystem und mehr UpdateLayout Fallstricke.
* Speichern in und Laden aus dem IsolatedStorage sowie Zugriff auf diesen inkl. Löschen - ok, das ist nun wirklich nichts Wildes.
* Einsatz eines Canvas als Overlay zur Annotationen - hier die Verbindungen von Aus- und Eingängen.
* Ein bißchen über Styles und was sie nicht können.

Viel Spaß

Jochen

Um auszuschliessen, dass es an den Daten liegt, habe ich das IndexOf naiv über ToCharArray() und einen wirklich primitiven Suchlauf gemacht - einfacher geht es nicht: erstes Zeichen des Suchbegriffs suchen und schauen, ob die Folgezeichen stimmen und wenn nicht ein Zeichen weiter neu suchen etc. Schlechter kann die Silverlight Implementierung eigentlich nicht sein - ist sie aber: hier gibt es nun auch unter XP keine Verzögerung mehr!

Dies als kleine Warnung: selbst auf Microsoft Plattformen scheint Silverlight nicht so furchtbar plattformunabhängig zu sein und hier geht es um eine primitive Laufzeitmethode!

Jochen

PS: Habe ich wohl nicht ausreichend respektive falsch recherchiert, ist ja schon länger bekannt. Sorry!

Hier einfach so ein paar Aspekte des Clients in bunt gewürfelter Reihenfolge - Silverlight, VCR.NET, Technik, …

• * Ein definiertes Ziel war es, im Oberflächenbereich soviel wie möglich auf XAML zu setzen und so wenig wie möglich Code zu schreiben. Das ist nur zum Teil gelungen, da vor allem die Programmzeitschrift doch einiges an Logik erfordert.
• * Als nützlich hat sich die gemischte Nutzung von vordefinierten (App.xaml) und programmatischen (App.Resources) Ressourcen erwiesen. Es scheint allerdings etwas kniffeliger zu sein, letztere in der Startphase zur Nutzung in XAML zur Verfügung zu stellen
• * Bei den Einstellungen habe ich ein wenig mit den Formularmöglichkeiten herumgespielt, etwa mit der Validierungsinfrastruktur oder dem praktischen Label Control.
• * Grundsätzlich sollte alles für eine einfache Übersetzung in andere Sprachen (Lokalisierung) vorbereitet sein.
• * Auf Deployment Techniken wie Bibliotheken bin ich bewußt nicht eingegangen.
• * Einer der zwei wichtigen Aspekte der Studie ist die Programmzeitschrift mit ihren Filtermöglichkeiten. Hier gab es einige Ärgernisse von Silverlight vs. WPF zu ignorieren (in einer ComboBox kann man ohne weiteren Code nicht über Tasteneingaben auswählen) oder zu umgehen (die Gruppierung der Ergebnisliste nach Tag und Stunde - Gruppierungen kennt in Silverlight erst einmal nur das DataGrid). Ganz nett war es zu sehen, wie einfach man aus einem ItemsControl eine Art ListBox machen kann, die ein Auswahlfeedback bietet.
• * Die Liste der geplanten Aufzeichnungen ist eher langweilig, hier habe ich ein bißchen mit dem DataGrid experimentiert. Ganz interessant ist die Detailanzeige von Mehrkanalaufzeichnungen, die sich auf die Ausawhl einer Aufzeichnung öffnet. Hier sind man genau, welche anderen Aufzeichnungen verhindert oder parallel aufgezeichnet werden.
• * Meine erste Aktion war der Navigationsknopf zum Blättern, der optisch ein wenig (nicht mehr) hermachen sollte. Er blendet sich auch fast vollständig aus, wenn die Maus nicht gerade auf ihm steht.
• * Die Animation beim Blättern ist ein reiner Test - vermutlich in der Praxis eher nervig.
• * Es werden auch die laufenden Aufzeichnungen angezeigt. Hier war aber die Zeit zu Ende und außer genau der Anzeige kann man nicht viel machen.
• * Im XAML wird an vielen Stellen mit Konvertern (IValueConverter) gearbeitet, vor allem zur Anzeige von Uhrzeiten (VCR.NET verwendet grundsätzlich GMT / UTC und nicht die lokale Zeitzone) oder der Auswahl von Symbolen. Richtig eingesetzt sind Konverter trotz einfachster Codierung offenbar eine starke Waffe zur Unterstützung der Dynamik - man siehe auch diesen Artikel.
• * Die Trennung zwischen Layout und Inhalt ist sicher noch unzureichend. Zwar habe ich viel auf Styles gesetzt, aber enthalten diese dann doch zum Teil wieder Bezüge zu ihrer Umgebung - unschön, das geht sicher auch professioneller.
• * Beim Anbindung des SOAP Web Services vom VCR.NET hat es sich als nützlich erwiesen, dass alle generierten Klassen partial sind. So konnte etwa das EPGEvent so erweitert werden, dass neu hinzugefügte Eigenschaften direkt in XAML Bindings referenzierbar sind.

Ok, das war sicher nicht alles, muss aber für jetzt reichen!

Viel Spaß

Jochen

Links sieht man die normale Darstellung und rechts so, wie ich mir das vorstelle. Den gesamten Quellcode für das Beispiel habe ich hier bereitgestellt, hier nur kurz die wesentlichen Tricks (wenn es einfacher geht, wäre ich durchaus an einem Hinweis interessiert).

Die rechte ListBox verwendet ein ItemTemplate / DataTemplate, in dem eine dynamische Bindung des Styles an ein ContentControl vorgenommen wird.

<ListBox.ItemTemplate>
<DataTemplate>
<ContentControl Style="{Binding Converter={StaticResource style}}" />
</DataTemplate>
</ListBox.ItemTemplate>


Bei der statischen Ressource handelt es sich um einen IValueConverter, der nach einer Namenskonvention beliebigen Instanzen von .NET Objekten eine statische XAML Ressource zuordnet.

<app:StyleChooser x:Key="style" />

object IValueConverter.Convert( object value, Type targetType, object parameter, CultureInfo culture )
{
if (value == null)
return null;
else if (targetType == typeof( Style ))
return App.Current.Resources[value.GetType().Name + "ClassStyle"];
else
return null;
}


Nun muss nur noch für jede Klasse ein Style in der verwendete Namenskonvention bereitgestellt werden. Da hier ein ContentControl verwendet wird, hat man im ControlTemplate alle Möglichkeiten, die auch ein DataTemplate bietet.

<Style x:Key="MammalClassStyle" TargetType="ContentControl">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate>
<StackPanel Background="Gray" Orientation="Horizontal">
<TextBlock Text="Das ist ein Säugetier: " />
<TextBlock Text="{Binding}" />
</StackPanel>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>


Happy Coding

Jochen

Konkret geht es um die SQL-2003 Syntax und dabei um die Suchsprache oder noch konkreter das SELECT Statement. Ich habe mich dabei hieran gehalten und hoffe einmal, dass die Beschreibung ausreichend nahe an der Wahrheit ist - verglichen mit dem, was ich vom SQL Server und Oracle weiss, sieht es zumindest mal nicht schlecht aus. In einer ersten Stufe ist ein rein syntaktischer Parser entstanden, den ich gerade in den Abschlusstest nehme. Es gibt eine Reihe von Problemen verschiedenster Art, aber zumindest scheint es im Großen und Ganzen zu laufen.

Nun, falls jemanden dies an sich (oder die Parser Bibliothek darunter) interessieren sollte: ich habe die aktuelle Version mal mit einem kleinen Installationsprogramm versehen und zum Download bereitgestellt - ich gehe davon aus, dass es in den nächsten Wochen durch meine eigenen Tests zu Updates kommt und ich werde versuchen, dies in der Versionsnummer zu berücksichtigen. Wenn die Syntax ausreichend korrekt erkannt wird, werde ich mal nach der Semantik schauen (e.g. a || b geht nur, wenn a und b Zeichenketten oder Listen sind, nicht aber für Zahlen). Vor allem die Anbindung an ein Schema wird interessant.

Für das reine Schnuppern (Auslachen? Hm…) habe ich auch die Quellen Online bereitgestellt - identisch, wie sie auch lokal installiert würden.

Für die Erstellung der Bibliotheken wurde Visual Studio / C# 2010 verwendet, allerdings gebunden an das .NET Framework 3.5 SP1 - und nicht 4.0.

Viel Spaß

Jochen

Ich verwende in C# eine Methode der Art void Test(params sometype[] args). So in C++ Analogie (sehr weit hergeholt, da das … / varargs doch nur mit Hilfe weiterer Parameter funktioniert) sollte man erst einmal erwarten, dass args niemals null ist - höchstens mal leer. Das stimmt leider nicht: C# erlaubt es auch ein sometype[] Feld direkt zu übergeben - das params wird dann mehr oder weniger ignoriert. So ein Feld kann natürlich null sein - mit der Konsequenz, dass auch args null ist!

Also Vorsicht: statt args.Length zu prüfen lieber (args == null) ? 0 : args.Length verwenden.

Viel Spaß mit all den anderen Fallstricken

Jochen

Bei der Umstellung auf Visual Studio 2010 hatte ich dabei ein interessantes (ärgerliches?) Problem, dass ich bisher noch nicht verstanden (nachrecherchiert) habe: bei der Konvertierung der Setup (MSI) Projekte wurden für viele Komponenten neue Kennungen (ComponentId) vergeben. Diese sind bisher auch nach Neuübersetzen mit vorherigem Löschen der MSI immer gleich geblieben. Das hatte ich ausgenutzt, damit die Installationspakete sich gegenseitig erkennen und als Installationsvoraussetzung nutzen können. Durch die Änderung musste ich alle Pakete in den SP2 mit aufnehmen, auch VCR.NET und den Viewer, die sich gar nicht verändert haben.

Trotz Allem viel Spaß beim Testen

Jochen

Happy Coding

Jochen

Viel Spaß

Jochen

Aber hier ein kleiner Tipp: ich wollte mal in eine SDB von einem anderen Rechner schauen und habe versucht, diese in dem Tool zu öffnen. Dies wird aber verweigert, da es sich um eine Systemdatenbank handelt. Kein Problem: mit einem Hexeditor in der SDB nach einer Sequenz aus 16 (ist eine eindeutige Kennung) Hexwerten 11 suchen und einen davon verändern (ich habe den ersten auf 21 gesetzt). Ist zwar kein feiner Trick (vor allem, wenn man nicht genau weiß, was man da verändert), aber nun kann die Datenbank geladen und inspiziert werden.

Viel Glück

Jochen

Ich wollte gerade mal eben auf einem Rechner VirusScan 2009 auf 2010 erneuern. Ganz naiv wie schon oft gemacht: alte Version deinstalliert und neue Version installiert. Geht aber nicht mehr in dieser Form! Ohne auf Details einzugehen, was ist passiert: VirusScan ersetzt die COM Registrierung der Script Engines, u.a. JScript. Nach der Deinstallation der 2009er Version gab es daher kein JScript mehr auf dem Rechner. Das wird aber für die Installation 2010er Version zwingend benötigt. Trapped! Auch der Hinweis von McAfee, JScript 4.5 für XP nachzuinstallieren, ist inzwischen hinfällg, da dieser auf dem aktuellen XP SP3 Update Stand den Dienst verweigert, weil er sich selbst als zu alt erkennt. Nach COM Registrierung von JScript.dll ist erst mal alles wieder im Lot (die anderen Script Engines werden von der 2010er Version eh wieder ersetzt, habe mit erspart, alle heraus zu suchen), aber das muss man auch erst mal finden. Naja, da McAfee das Problem kennt bin ich mal gespannt, was nach der Deinstallation der 2010er Version los ist. Im Moment hat mich das aber unnötig Zeit gekostet und ich habe keine Lust, es auszuprobieren.

Tschüss

Jochen

Der DVB.NET TS Parser bietet im Moment leider nicht die Möglichkeit, dynamisch Teilströme an einen Client zu melden. Aber mit einem kleinen Trick geht es doch. Das Beispielprogramm aktiviert eine beliebige Quellgruppe (Transponder), die durch eine Quelle (Sender) als Repräsentant gekennzeichnet wird. Dann wird der Statistikmodus aktiviert, der dafür sorgt, dass für alle Datenströme Buch über die empfangenen Daten geführt wird. Wartet man nun etwas (so 30 Sekunden, damit auch TOT und TDT eingetroffen sind) und fragt diese Statistik dann ab, so erhält man im Allgemeinen alle Datenstromkennungen (PID) der Quellgruppe. Nun ist es ein Einfaches, Verbraucher an die einzelnen Ströme anzumelden und diese auszuwerten - das Beispiel ist allerdings extrem einfach gestrickt, reicht aber, um die meisten SI Tabellenströme von Nutzdaten zu trennen und bei PES Datenströmen die Breitstellung des PCR zu erkennen. Läßt man das Beispiel kurz laufen, kann man sich dann das Ergebnis der Analyse anschauen. Klar, dass da noch viel mehr drin wäre, aber das war hier erst einmal nicht das Thema.

Wie man am Beispiel sieht, bietet DVB.NET (aus gutem Grund) keinen direkten Zugriff auf die Interna des DVB Empfangs an. Mit ein bißchen .NET Reflection im Full Trust Modus ist das aber alles schnell gemacht. Mal schauen, ob zukünftige Versionen da einen einfacheren Zugang erlauben.

Auf diesem Wege auch einen guten Rutsch ins nächste Jahr

Jochen

Die erzeugt Ausgabedatei enthält unter anderem folgende Informationen:

• Untersuchte Quellgruppe (Transponder) und deren Anwahl
• Inhalt der Netzwerkinformationen
• Liste der Quellen (Sender) auf jeder Quellgruppe

Wie in letzter Zeit gelernt können diese Informationen sehr nützlich bei der Suche nach Fehlern beim Sendersuchlauf sein - seien es tatsächliche Fehler in DVB.NET oder Fehlkonfigurationen vor Ort.

Viel Spaß

Jochen

Kern ist die Klasse TTXParser, deren AddPayload Methode mit dem Rohdatenstrom (ES) beschickt wird. Sobald eine Seite (TTXPage) vollständig bereit steht, wird ein entsprechendes Ereignis ausgelöst (OnPage). Ergänzend bietet DVB.NET mit der Klasse PageManager die Möglichkeit, einmal empfangene Seiten vorzuhalten. Diese können dann gezielt angefordert werden (CurrentPage) und werden dann unmittelbar oder nach Empfang der ersten Version über ein Ereignis gemeldet (OnPageAvailable) - dito bei jeder folgenden Aktualisierung der Seite [unabhängig davon, ob sich der Inhalt verändert hat]. Sollten kein Rohdatenstrom vorliegen (so wie es beim DVB Empfang oft der Fall ist), kann dieser durch Kombination mit einer TTXStream Instanz aus einem PES erzeugt werden.

Im Zentrum der eigentlichen Darstellung stehen Instanzen der TTXPage Klasse. Diese verwaltet eine voranalyiserte Darstellung der Seite, die allerdings für die direkte Auswertung nicht zwingend geeignet ist. Hier sind noch Steuersequenzen für Zeichengröße, Zeichensatz, Vorder- und Hintergrundfarbe etc. eingebettet. Mit einem Aufruf von CreatePage erfolgt die Umsetzung in eine .NET Bitmap Instanz, die direkt zur Anzeige verwendet werden kann. Die Unterstützung des VideoText Standards ist zwar recht rudimentär (international Zeichensätze werden nicht korrekt dargestellt, was etwa ARTE oder BBC etwas komisch aussehen lässt), für die deutschen Sender reicht es aber. Ebenso vorhanden sind transparente Seiten etwa für Untertitel.

Ergänzend zur Bitmap und den Rohdaten bietet CreatePage die Option, eine Information über alle auf der Seite ausgegebenen Ziffern zu erfragen. Diese werden über eine Klasse DigitManager verwaltet. Mit der Methode GetTTXDigitAt kann zu einer relativen Position auf der Seite (in den Koordinaten 0.0 bis 1.0, wobei 0.0 / 0.0 wie gewohnt oben links ist) ermittelt werden, ob dort eine Ziffer ausgegeben wurde. Ist das der Fall, so wird auch der Rahmen des Zeichens in relativen Koordinaten gemeldet. Ergänzend prüft GetPageAt zu einer Position, ob dort eine dreistellige Seitennummer im Bereich 100 bis 899 (jeweils einschließlich) vorhanden ist - dazu wird natürlich GetTTXDigitAt eingesetzt. Bedingung ist eine Sequenz aus genau drei Ziffern gleicher Größe - Höhe und Breite.

Viel Spaß

Jochen

Viel Spaß

Jochen

Auch wenn das Buch in der Gesamtheit einen etwas gemischten Eindruck hinterläßt, halte ich es für die angesprochene Zielgruppe für unbedingt empfehlenswert. Die meisten Kapitel sind didaktisch gut aufgebaut, logisch und meiner Ansicht nach genau in der richtigen Tiefe. Es geht nicht in die absoluten Details (elendige Diskussionen aller Felder von Kernel Strukturen sind extremst selten), sondern vermittelt vielmehr Hintergründe, Zusammenhänge und zum Teil auch Designentscheidungen. Wer wirklich direkt anfangen will, einen Treiber zu schreiben, wird sicher mehr brauchen - aber das war auch nicht meine Erwartungshaltung. Bei mir hinterläßt es zumindest das Gefühl, einige Grundprinzipien verstanden zu haben - und es hat mich zu einigen Experimenten mit Vista rund um UAC und VSS motiviert, bei denen diese Prinzipen auch für den Endanwender fühlbar werden.

Allerdings gibt es auch einige (zwei oder so) Kapitel, die eher verwirrend waren - vielleicht, weil das nicht wirklich mein Thema war, vielleicht, weil der Umfang der zu vermittelnden Daten einfach den Rahmen sprengte. Die Netzwerkarchitektur scheint mir eher ein ‘alles mal erwähnen’ zu sein als sich an der angenehmen Tiefe des Rest zu orientieren - wie gesagt, kann auch an mir liegen.

Auch vielleicht nicht ganz ohne Schuld auf meiner Seite habe ich das Gefühl, dass zwischen den (zweifellos berechtigten) Querreferenzen nach vorne und hinten doch mal etwas auf der Strecke blieb. So meine ich das eine oder andere mal ein ‘wie bereits in Kapitel X ausführlich beschrieben’ bei Nachschlagen auf einen Absatz mit zwei Sätzen reduziert gesehen zu haben. Da ich aber keine Zeit hatte, alles mehrfach zu lesen und nachzuschlagen (immerhin 1150 Seiten), kann ich das nicht für alle Stellen oder gar für Vorwärtsreferenzen bestätigen.

Alles in Allem meine ich, das Buch ist mit der richtigen Erwartungshaltung unbedingt sein Geld wert (Tipp: mal bei Amazon UK statt hier nachzuschauen, das kann sich je nach Situation trotz Porto lohnen).

Nun versuche ich etwas braver mit meiner Zeit umzugehen und mal nach dem DVB.NET / VCR.NET 3.9 Service Pack 1 zu schauen.

Viel Spaß

Jochen

Eine der wohl üblichsten Verwendungsarten von in XAML definierten Ressourcen sind sicherlich Abbildungsvorschriften von Daten auf Oberflächenelementen (e.g. <DataTemplate x:Key=”ShortDescription”>) und Styles (e.g. <Style x:Key=”DescriptionHeader”>), ich fand es im Bereich der Oberflächengestaltung auch recht praktisch, beliebige Strukturen vordefinieren zu können (e.g. <StackPanel x:Key=”LongDescription”>).

Genauso nützlich ist es, globale Instanzen einmalig definieren zu können (e.g. <app:ProgramGuide x:Key=”TheGuide” />), wobei diese sich oft (wenn die Reihenfolge der Definition es erlaubt) auch gegenseitige referenzieren können (e.g. <app:Filter x:Key=”GuideFilter” /> und <app:ProgramGuideView x:Key=”GuideView” GuideFilter=”{StaticResource GuideFilter}” Source=”{Binding Source={StaticResource TheGuide}, Path=Events, IsAsync=true, Mode=OneTime}” />).

In der Beispielanwendung werden Ressourcen auch für Zeichenketten wie Formate (e.g <system:String x:Key=”DateTimeFormat”>dd.MM.yyyy HH:mm</system:String>) verwendet, wobei allerdings meiner persönlichen Ansicht nach hier die Grauzone zum Aspekt der Lokalisierung auf die gute alte WinForms Art (.resx) berührt wird. Auch wenn WPF anderen Ideen zur allgemeinen Lokalisierung mit sich bringt, könnte es für diese Fälle (Zeichenketten, die lokalisierbar sein sollten, aber nicht direkt in der Oberfläche erscheinen) eleganter sein, auf RESX und die StaticResource Markup Erweiterung zu setzen.

Als letztes finde ich im Rahmen der Beispielanwendung erwähnenswert, dass auch Felder als XAML Ressourcen angelegt werden können (e.g. <x:Array Type=”system:DateTime” x:Key=”TimeSelections”> und darin <system:DateTime>00:00</system:DateTime> et al).

Happy Coding

Jochen

Ich habe mich entschieden, die Art der Anzeige in einer eigene Klasse zu implementieren. Diese wird dann an die Liste via XAML angehängt (ItemsSource=”{Binding Source={StaticResource GuideView}}”) - die Anzeigeklasse ist wieder einmal eine globale Ressource. Interessant ist im Beispiel das Zusammenspiel mit der Filterbedingung.

Zur Auswahl von Teilen der Programmzeitschrift gibt es eine Filterklasse, in der die üblichen Parameter gesetzt werden können. Ich habe diese auf der untersten WPF Ebene implementiert, die sowohl dynamische Eigenschaften (DependencyProperty mit Bindungen) als auch Ereignisse (RoutedEvent) erlaubt: dem FrameworkElement. Eine Instanz der Klasse wird als globale Ressource angeboten. Dazu noch ein paar weitere Details, der Filter selbst ist trivial und nicht wirklich der Rede wert.

Die eindeutige Filterinstanz wird nun auf zweierlei Art verwendet. Zum Einen binden sich verschiedene Oberflächenelemente direkt an die relvanten Filtereigenschaften - etwa das Eingabefeld mit dem Freitextsuchfeld. Interessant ist dabei, dass bei den Bindungen (Text=”{Binding Source={StaticResource GuideFilter}, Path=TextFilter, Mode=OneWayToSource}”) alternierend OneWayToSource und TwoWay (SelectedItem=”{Binding Source={StaticResource GuideFilter}, Path=Time, Mode=TwoWay}”) verwendet wird: im Allgemeinen wäre OneWayToSource die korrekte Wahl, ich möchte aber einige (wenige) Auswahlelement direkt mit den Voreinstellungen belegen, die nur der Filter selbst kennen muss.

Zur Reaktion auf Änderungen der Filterbedingun bindet sich der CollectionSourceView an die Ereignisse, die bei Veränderungen von der Filterinstanz aufgerufen werden - die Verbindung erfolgt aus Basis der globalen Ressourcen (<app:ProgramGuideView x:Key=”GuideView” GuideFilter=”{StaticResource GuideFilter}” Source=”{Binding Source={StaticResource TheGuide}, Path=Events, IsAsync=true, Mode=OneTime}” />). Die Sicht auf die Programmzeitschrift aktualisiert sich dann selbst, gefolgt von der entsprechenden Aktualisierung in der Benutzeroberfläche. Tatsächlich habe ich es nicht so richtig hinbekommen, der Sicht zu sagen, sie solle sich einfach erneuern. Daher im Code der kleine Trick mit dem NullFilterEvent und dem m_Changing Flag, die dafür sorgen, dass die Filter Eigenschaft des Views verändert wird, ohne dass dabei eine mehrfache Auswertung stattfindt - was stark auf die Laufzeit geht.

Soweit dazu

Jochen

Ergänzend sieht man im Programmcode des Dialogs, wie diese Aktualisierung auch auf einen Rutsch dynamisch vorgenommen wird, ohne dass jedes Formularelement explizit angesprochen werden muss. Konkret bedeutet das, dass ein neuer Konfigurationseintrag letztlich nur in der XAML mit einem Formularelement eingetragen werden muss um gepflegt zu werden: es ist kein zusätzlicher Programmcode notwendig.

So wie es implementiert ist, funktioniert es allerdings nicht wirklich: an einigen Konfigurationseinträgen hängen Prüfungen (ValidationRule) und nur wenn alle Prüfungen Erfolg melden, kann das Formular gespeichert werden. Bei einer Gesamtprüfung werden aber alle erfolgreichen Eingaben bereits in die Konfiguration übertragen und sind damit zumindest für die weitere Nutzung der Anwendung verändert - auf Platte gespeichert werden kann allerdings nur, wenn alles korrekt eingegeben wurde. Ich habe dem zumindest optisch Rechnung getragen, indem die Abbrechen Schaltfläche deaktiviert wird. Ist aber nur halbherzig, da man den Dialog immer noch über das Kreuzchen rechts oben schliessen kann. Wieder für eine produktive Lösung undenkbar, aber das ist hier erst einmal irrelevant.

Eine zweite Anwendung von x:Static findet man in der Anwendung selbst. Hier wird eine Auflistung (TextFilterTypes[] FilterTypes) aller Alternativen einer .NET Enum angeboten, die in einer Auswahlliste angezeigt werden soll (ItemsSource=”{x:Static app:App.FilterTypes}”). Eine Erweiterung um eine Alternative erfordert erst einmal nur die Veränderung der Enum Definition und die Oberfläche folgt dieser sofort. Dass die Beispielanwendung diese Altenativen über WPF Ressourcen auf Texte abbildet ist für das Prinzp ohne Bedeutung - auch wenn das natürlich heißt, dass man doch zumindest einen weiteren Eintrag in den Ressourcen ergänzen muss.

Viel Spaß

Jochen

Wenn man eine Anwendung an eine Web Service bindet, so werden eine Reihe von Proxy Klassen im Projekt erzeugt (Unterverzeichnis Web References). Im Beispiel liefert die entscheidende Methode (GetEPGData) ein Feld mit EPGEvent Instanzen. Die Einträge der Programmzeitschrift sind allerdings zur direkten Darstellung wenig geeignet, enthalten sie doch den Startzeitpunkt in GMT / UTC Notation und statt des Endzeitpunktes die Dauer in Sekunden.

Glücklicherweise werden alle Proxy Klassen als partiellen Klassen (partial class) angelegt, so dass es ein Einfaches ist, diese mit geeigneten Eigenschaften und Methoden zu ergänzen. Im Beispiel wird dies hier gezeigt. Die Klasse EPGEvent bietet nun einen einfachen Zugriff auf Start und Ende in der lokalen Zeitzone und einige Hilfseigenschaften, die zur Variation der Darstellung benötigt werden (etwa meldet IsCurrent ob die Sendung jetzt gerade läuft). Zusätzlich wurden die Klassen zur Programmierung von Aufzeichnungen erweitert. Zu einem Auftrag (VCRJob) können nun einfach neue Aufzeichnungen hinzugefügt werden und eine Aufzeichnung (VCRSchedule) erlaubt eine Pflege der Aufzeichnungsparameter (FirstStart als GMT / UTC und Duration in Minuten) elegant in der lokalen Zeitzone über Start- und Endzeitpunkt.

Interessanter Weise macht der Code in dieser Datei auch einen erheblichen Anteil am Gesamtcode und der Kommunikation mit VCR.NET aus. Für das Laden der Programmzeitschrift wurde ein asynchroner Mechanismus gewählt, der ideal zu den asynchronen dynamischen Werten von WPF (Binding.IsAsync) passt - dazu in einem anderen Artikel. Beim Erzeugen der ProgramGuide Hilfsklasse wird VCR.NET asynchron kontaktiert, ein Abruf der Werte ist erst möglich, wenn eine Antwort bereit steht. Da die Instanz der Hilfsklasse als WPF Ressource angelegt wird (auch dazu an anderer Stelle mehr) wird dieser Vorgang sehr früh beim Starten der Anwendung angeworfen und kann parallel zum Aufbau des Hauptfensters abgearbeitet werden.

Auf technische Details der Implementierung will ich hier nicht eingehen - Thema ist ja WPF. Erwähnt werden sollte allerdings eine wesentliche Unschönheit in dem vorhandenen Code: wenn die SOAP URL des Servers nicht stimmt, so passiert erst einmal gar nichts. Hier muss der Anwender über die Konfiguration eine korrekte Adresse eintragen und die Anwendung neu starten. Für eine produktive Anwendung ein Unding, aber für das Ziel dieser Evaluation völlig ausreichend.

So long

Jochen

Wie dem auch sein: ich habe mal eine Version hochgeladen - dito der aktuelle Quelltext. In den nächsten Tagen wird es hier im BLog einige Kommentare dazu geben, wobei ich auch für mich nochmal durch das Gelernte gehen werden (kann also sein, dass sich Quellen und Anwendung dabei noch verändern). Ich werde versuchen, mich jeweils auf einzelne Themen zu beschränken und dabei auch erläutern, was wie und warum geht und was nicht (ja, irgendwie habe ich nicht wirklich alles ans Laufen bekommen). Vielleicht hilft das dem einen oder anderen WPF Einsteiger, auf die richtigen Ideen zu kommen - immer vor dem Hintergrund, dass ich selbst natürlich noch blutiger Laie bin.

Viel Spaß

Jochen

Ich werde jetzt erst mal eine Weile was anderes machen und vermutlich im Spätherbst schauen, dass die ‘echte’ 4.0 in die Gänge kommt. Was danach passiert, steht in den Sternen…

Jochen

Happy Coding

Jochen

Nehmen wir einmal eine solche Klasse:

class ChangableNumber
{
public int Number { get; set; }
public override int GetHashCode()
{
return Number.GetHashCode();
}
public override bool Equals( object obj )
{
ChangableNumber other = obj as ChangableNumber;
if (null == other) return false;
return (Number == other.Number);
}
}


Und bauen uns ein Dictionary mit einem Schlüssel, den wir verändern. Was erzeugt wohl das folgende Programm als Ausgabe:

ChangableNumber c1 = new ChangableNumber { Number = 1 };
Dictionary dict = new Dictionary();
dict[c1] = true;
Console.WriteLine( dict.ContainsKey( c1 ) );
c1.Number = 4;
Console.WriteLine( dict.ContainsKey( c1 ) );
c1.Number = 1;
Console.WriteLine( dict.ContainsKey( c1 ) );


Nun, erst mal wie erwartet: true (1 ist drin), false (4 natürlich nicht) und true (1 ist wieder drin). Was aber, wenn GetHashCode() zufälligerweise für den veränderten Wert den selben Schlüssel liefert (respektive dieser versehen mit dem Modulo des Dictonary den selben Wert hat)? Das ist einfach zu testen: der Inhalt von GetHashCode() wird durch return 1; ersetzt. Nun ist das Ergebnis true, true und wieder true. Wie kommt die 4 denn nun in das Dictionary?

Der Trick ist einfach: ein Dictionary nimmt den Wert von GetHashCode() und ermittelt daraus zum Beispiel durch ein Modulo (mit einer Primzahl, muss aber nicht) einen Indexwert. Für jeden Indexwert wird eine Liste von Schlüssel / Wert [interessiert hier nicht] Paaren verwaltet, i.e. eine Liste enthält alle Schlüssel, die aus Sicht des Dictionary den gleichen Hash haben.

Im ersten Beispiel waren diese (zufällig) unterschiedlich, so dass das Dictionary beim Anlegen eine Liste (sagen wir mal 1) mit einem Schlüssel / Wert Paar anlegte. Das Ändern in 4 führt dazu, dass bei der Prüfung mittels ContainsKey eine nicht vorhandene Liste (4 oder was auch immer) gesucht wird. Diese ist leer, also liefert ContainsKey false.

Im zweiten Beispiel wird nach der Änderung aber die (immer einzige) Liste (1) untersucht. Diese ist nun nicht leer, so dass alle Schlüssel mittels Equals verglichen werden. Natürlich passt unser Schlüssel nun immer, da er mit sich selbst verglichen wird (i.e. in diesem Beispiel kann man jeden beliebigen Wert zuweisen, das zweite ContainsKey ist immer true). Für das ursprüngliche Beispiel wäre übrigens -2147483647 (0×80000001) der zugehörige Killerwert - vermutlich der einzige.

Und das Fazit? Veränderliche Schlüssel für ein Dictionary sollten nur mit vorherigem Nachdenken verwendet werden.

Viel Glück dabei

Jochen

Startet man den Listener auf dem Haupthread der Anwendung, funktioniert alles wie gewünscht und der Listener erkennt automatisch das Ende der Anwendung. So weit so gut. Wenn man allerdings einen Thread verwendet, der explizit oder implizit beendet wird, so terminiert auch der Listener. In meinem Fall knallte es beim expliziten Beenden: ich hatte einen Thread, der einfach nur den Listener konfigurierte und startet und sich dann beendet - damit die Initialisierung der Anwendung (in diesem Fall der VCR.NET Windows Dienst) im Hauptstrang so schnell wie möglich durchläuft.

Mit ThreadPool.QueueUserWorkItem geht es dann, aber mit einer im Hintergrund drohenden Gefahr: der ThreadPool beendet die Aufgabe und verwendet den Thread dann später für andere Aufgaben weiter. Der Listener bleibt an diesen Thread gebunden, der überhaupt nichts mehr mit ihm zu tun hat. Und wenn der ThreadPool irgendwann mal einen Thread wegwirft? Den Fehler findet man vermutlich nie!

Ich habe mich daher entschieden, mich nicht auf die Willkür zu verlassen und halte den Thread, der den Listener hochfährt, bis zum Ende der Anwendung oben (über ein Manual/AutoResetEvent). Nur so habe ich ein gutes Gefühl, dass nicht doch plötzlich die Kommunikation des Clients zum ASP.NET zusammenbricht.

Zumindest sollte man das im Hinterkopf haben!

Jochen

Zu beachten ist allerdings, dass ein virtuelles Verzeichnis immer in einer eigenen .NET AppDomain läuft. Unser Ansatz besteht daher immer aus mindestens zwei AppDomains, was einige besondere Aspekte mit sich bringt. Ich stelle hier in Stichworten einmal die beim VCR.NET implementierte Lösung vor.

1. Der .NET Dienst wird natürlich in einer ersten AppDomain gestartet. Hier soll auch der Server leben.
2. Der Server wird als .NET Instanz einer MarshalByRefObject Klasse (Server) erzeugt.
3. Für das ASP.NET Hosting wird eine weitere MarshalByRefObject Klasse (Host) benötigt, die in dem virtuellen Verzeichnis erstellt wird.
4. Nach dem Starten des virtuellen Verzeichnisses erhält Host die Server Referenz aus der ersten AppDomain.
5. Alle Zugriffe aus dem virtuellen Verzeichnis erfolgen über dese Referenz und werden in der ersten AppDomain ausgeführt.
6. Damit die beiden (Server und Host) Inter-AppDomain Referenzen nicht durch die Remoting Lebenszeitkontrolle spontan gelöst werden, melden deren InitializeLifetimeService Methoden null.
7. Alle Klassen, die zwischen den AppDomains ausgetauscht werden sollen, müssen MarshalByRefObject oder [Serializable] sein. VCR.NET setzt auf serialisierbare Klassen, so dass zwar für die Serialisierung und Deserialisierung bezahlt werden muss, die Objekte dann aber ohne Kommunikationsverluste weiter verwendet werden können. Man beachte, dass hier die binäre Serialisierung zum Einsatz kommt - man siehe dazu einen früheren Eintrag in diesem BLog.

Zur Verwaltung der Konfiguration wird ein einziges Konfigurationsobjekt eingesetzt, über das alle Zugriff (auch schreibend) erfolgen. Dieses wird in der ersten AppDomain angelegt. Damit es nicht in alle Klassen durchgereicht werden muss (hier gibt es etwa Methoden wie Log(string message)), erhählt die Konfigurationsklasse (Config) ein statisches Feld Current, dass bei der Intialisierung des Windows Dienstes auf der ersten AppDomain belegt wird (Config.Current = new Config()). Zusätzlich bietet die Server Klasse eine Eigenschaft zum Zugriff auf Config.Current an. In Schritt 4. oben wird in der AppDomain des virtuellen Verzeichnisses eine Referenz des eindeutigen Konfigurationsobjektes in das statische Feld als Referenz übernommen (Config.Current = Server.CurrentConfiguration) - ein anderes statisches Feld, da statische Felder nur pro AppDomain eindeutig sind. So arbeiten beide AppDomains immer mit der selben Konfiguration - Config ist natürlich ein MarshalByRefObject, dessen InitializeLifetimeService null liefert.

Nun, für einige ist das vermutlich trivial, aber vielleicht hilft die Information hier dem einen oder anderen, einige Fallstricke zu vermeiden und etwas Zeit zu sparen.

Viel Glück

Jochen

Zukünftige VCR.NET Versionen (die nach der 3.9, so es sie denn geben sollte) werden möglicherweise veränderte SOAP Schnittstellen auf Basis von WCF (Windows Communication Framework) anbieten. Für die 3.9 wird es keine neuen Varianten der beiden primären Web Services geben, vielmehr wird VCR.NET 3.9 versuchen, auf Basis der neuen Infrastruktur die alten Schnittstellen unverändert anzubieten. Das geht soweit auch schon, hat aber einige Nachteile - die vermutlich aber kaum jemanden betreffen.

Zum einen können neue Funktionalitäten nicht genutzt werden, wenn diese über die Protokollstrukturen der alten Schnittstellen nicht verfügbar sind. Das ist eher unkritisch, hier ging es etwa um die präzisere Auswahl der Quellen (früher Sender genannt). Kritischer ist aber, dass VCR.NET einige Informationen intern nicht mehr pflegt und auf Anfrage daher auch nicht mehr zur Verfügung stellen kann. Hier ist vor allem die Senderbeschreibung zu erwähnen: DVB.NET stellt ab der Version 3.9 (auf der VCR.NET 3.9 basiert) zum Beispiel die Daten zu den Tonspuren nicht mehr zur Verfügung. Bei Anfrage an VCR.NET 3.9 über die alten Schnittstellen werden hier leere Listen geliefert. Tatsächlich benötigt der DVB.NET / VCR.NET Viewer als einer der VCR.NET SOAP Clients diese Information überhaupt nicht, anderen Clients wird es ähnlich gehen. Genauso ist es nicht exakt möglich, die Auswahl der Teildatenströme auf die vier Wahrheitswerte (Alle Sprachen, Dolby Digital, DVB Untertitel, Videotext) abzubilden, da die interne Verwaltung nun sehr viel feinere Variationen zulässt. Allerdings versucht VCR.NET sein Bestes, ein möglichst exaktes Abbild der tatsächlichen Konfiguration zu übermitteln.

In Einzelfällen ist zu klären, an welchen Stellen die modifizierten Informationen ein Problem darstellen. Im Wesentlichen bleibt aber die folgende Aussage: VCR.NET 3.9 wird voraussichtlich keine neuen SOAP Dienste oder Varianten der alten anbieten. Die vorhandenen Clients wie der Viewer oder das Kontrollzentrum werden die alten SOAP Schnittstellen benutzen - vielleicht wird es das eine oder andere Hintertürchen geben, um eine versionsunabhängige Version des Viewers zu erstellen - das Kontrollzentrum ist da eher harmlos.

Bis bald

Jochen

Hier werden automatische Felder (auto-implemented properties) benutzt, i.e. zu den deklarierten .NET Eigenschaften UniqueName und State gibt es für den Entwickler unsichtbar zugehörige .NET Felder der Klasse. Was aber, wenn die Serveranwendung tatsächlich aus mehreren AppDomains besteht, zwischen denen Instanzen der Klasse ebenso ausgetauscht werden sollen - typisch ist ein (ASP.NET) Hosting Szenario, wobei die eigentlichen Serveralgorithmen in einer AppDomain mit kontrolliertem Lebenszyklus (etwa einem Windows Dienst) implementiert sind und eine oder mehrere andere AppDomains die Kommunikation mit dem Client regeln und etwa dynamisch bei Veränderungen nachgeladen werden (etwa durch die ASP.NET Dateiüberwachung).

Die hier verwendete SOAP Serialisierung zum Client verwendet die XML Serialisierung. Diese berücksichtigt ausschließlich öffentliche (public) .NET Eigenschaften, das Ausschließen einzelner Eigenschaften geschieht wie im Beispiel durch das XmlIgnoreAttribute. Zwischen AppDomains wird allerdings die binäre Serialisierung verwenden (Kann man das wählen? Ich habe nichts dazu gefunden.), die sich an .NET Feldern und dem NonSerializedAttribute orientiert. Konkret heißt das im Beispiel, dass zwischen AppDomains beide Eigenschaften ausgetauscht werden.

Das kann natürlich so gewollt sein, keine Frage. Aber dann wäre im Beispiel der Context auch entweder serialisierbar oder ein MarshalByRefObject. Passiert es ungewollt, so kann das je nach Situation einen empfindlichen Einfluss auf die Laufzeiten haben, da mit kleinen Instanzen eventuell sehr große angehängte Objekte stillschweigend mit serialisiert werden oder unerwartete AppDomain kreuzende Aufrufe vorgenommen werden. Leider hat Microsoft aber wohl den einfachen Weg nicht implementiert, der für event Felder prima funktioniert:

[XmlIgnore][field:NonSerialized] public Context State { get; set; }


Daher ist es notwendig, auf die automatischen Eigenschaften zu verzichten und selbst ein Feld anzulegen. Nicht tragisch, aber auch nicht elegant.

[NonSerialized] private Context m_State;
[XmlIgnore] public Context State { get { return m_State; } set { m_State = value; } }


DVB.NET hat in der Klasse SourceSelection ein weiteres Problem: hier sollen Eigenschaften, die auf Objekte verweisen, als Zeichenkette serialisiert werden, wobei diese durch eindeutige Namen der Objekte zusammengesetzt werden. Dabei kommt man leider um ISerializable und Konsorten nicht herum, wenn man die binäre Serialisierung genauso nutzen möchte wie die XML Serialisierung - egal ob explizit oder wie beschrieben implizit durch AppDomain Grenzen bedingt.

Happy Coding

Jochen

Wer denn dann wirklich eine 2.6 betreibt und unbedingt auf die 3.9 will: erst einmal irgendeine Zwischenversion installieren, VCR.NET einmal durchstarten und dann die Zwischenversion wieder deinstallieren. Das Durchstarten übernimmt den ersten Konvertierungsschritt.

Sollte es tatsächlich jemanden betreffen und Mühe machen: sorry!

Für die meisten anderen Anwender einfach zum Lesen und sofortigen Vergessen

Jochen