.Net Compact Framework: ImageButton ??

Nach langer Funkstille zum Thema Anwendungsentwicklung für Windows Mobile mit dem .Net Compact Framework (CF), möchte ich heute nochmals einen Zwischenbericht abgeben.

Mein Fazit bisher: das CF ist wirklich auf das Nötigste reduziert, fast schon um zu viele Dinge reduziert, wenn man von dem vollen Umfang des normalen Frameworks verwöhnt ist. Weniger Umfang hat wohl nur noch das .Net Micro Framework… Erste Erfahrungen durfte ich ja bereits mit dem OpenFileDialog sammeln, nun habe ich weitere Lücken gefunden, die ich gerade am Schließen bin. So ist es bspw. bei einem Button im CF nicht möglich ein Bild neben einem Label zu platzieren; das normale Framework bietet hier ein Image Property am Button an. Was also tun ? Richtig, neben der Entwicklung der Dialoge zur Erledigung einfachster Ordner- bzw. Dateiauswahloperationen habe ich begonnen eine eigene Controls-Library zu bauen. Diese beinhaltet bisher zwar nur eine Klasse „ImageButton“ (s. Bild), aber das kann ja noch wachsen.

ImageButton

ImageButton

Bzgl. der SimpleFileRequesterDialogs ist der Stand der, dass der Ordnerauswahldialog (DirectoryChooserDialog) funktioniert (s. Bild) und ich nun an dem OpenFileDialog arbeite. Aus dieser Arbeit heraus entstand auch die Notwendigkeit die eigene Controls-Library zu schreiben.

Verzeichnisauswahldialog

Verzeichnisauswahldialog

Alles in allem komme ich aus Zeitgründen nur langsam voran, aber es geht stetig weiter 😉

OpenFileDialog im .Net Compact Framework

Am Wochenende bin ich über eine Sache gestolpert, wo ich nicht so recht glauben wollte, dass das wahr sein könnte. Ich habe ja mehrfach berichtet, dass ich mich derzeit daran versuche eine Windows Mobile Applikation zu entwerfen. Mit genau diesem Thema habe ich mich auch am Wochenende befasst, als ich aber an die Stelle kam, an der es darum ging Sounds abzuspielen, bin ich über eine – meines Erachtens nach – Basisfunktionalität gestolpert: System.Windows.Forms.OpenFileDialog.

Angefangen hat die Geschichte mit der Implementierung der Sound-Funktionalität, wobei ich mich hierbei des Windows Media Players (wmp.dll) bediente und diese in den Code einband. Die Klasse für den Sound war an sich schnell umgesetzt – nur wie testen ? Also habe ich auf dem Einstellungen-Tabreiter einen „Sound auswählen“ Button hinzugefügt und wollte dann einen einfachen Dateiauswahl-Dialog öffnen. .Net bietet wie gesagt hier die Klasse OpenFileDialog an. Diese habe ich dann auch genutzt und die Anwendung im Debug gestartet. Im Emulator kam dann die Anwendung nach vorne und ich drückte auf den Button und was erschien ? Dieses „Ding“:

.Net CompactFramework OpenFileDialog

In der Combobox „Folder“ tauchen bspw. völlig unnütze Einträge auf, kurz gesagt ich war nicht in der Lage intuitiv und wie gewohnt durch die Ordnerstruktur zu navigieren und eine einfache Datei auszuwählen. Zuerst dachte ich, ich würde etwas falsch machen und habe mich dann im Internet auf die Suche nach einer Lösung begeben. Das erste worauf ich stieß waren Drittanbieter-Komponenten, die sie sich äußerst fürstlich entlohnen ließen. Langsam stieg in mir ein leiser Verdacht auf: sollte ich hier etwa auf die erste der von einem Kollegen viel beschworenen Lücken im Compact Framework gestoßen sein ??? In der Tat sah es nach einer weiteren viertel Stunde Suche äußerst düster aus. Entweder fand ich nur besagte Dritthersteller-Controls oder Dialoge mit Quelltext, die aber nicht sonderlich ansprechend oder funktional waren. Jeder kocht hier sein eigenes Süppchen und programmiert diese Funktionalität selbst aus. Das ist das Fazit meiner Recherche 🙁

Daher muss ich nun meinem Projekt „PhoneEventNotifier“ noch eine anderes Projekt vorschalten: „SimpleFileRequesterDialogs“, d.h. ich werde mich nun zuerst hinsetzen und folgende Dinge nachbauen:

  • Verzeichnisauswahldialog
  • Dateiauswahldialog (Öffnen, Speichern, Mehrfach-Selektion, …)

Dies werde ich als DLL erstellen und separat bereitstellen. Im Prinzip sind alle Funktionalitäten im Compact Framework vorhanden, es fehlt nur die Vereinigung dieser in Form eines Dialogs, der sich „wie gewohnt“ bedienen lässt. Danach geht dann die Arbeit am „PhoneEventNotifier“ weiter.

Sachdienliche Hinweise können in Form von Kommentaren hinterlassen werden 😉

Windows Mobile – PhoneEventNotifier Status

Die Entwicklung des PhoneEventNotifier schreitet voran 🙂 Folgende Fähigkeiten hat das Programm bis dato:

  • Registrierung am System Event PhoneMissedCall (und somit automatischer Start der Anwendung bei Auftreten des Events)
  • Anzeige der Rufnummer des zuletzt verpassten Anrufs

Als nächstes ist geplant:

  • dem Einstellungs-Tab Leben einzuhauchen
  • Auswahl und Abspielen von Sounds

Es wird also so langsam und es macht wirklich Spaß 😉

Hier noch die vorangegangen Artikel zu diesem Thema:

Entwickeln für Windows Mobile – Fortschrittsbericht

Nach einer kleineren Pause möchte ich heute kurz ein Update zum Stand der Entwicklung einer Windows Mobile Applikation geben. Nach längerem Zaudern habe ich mich dazu entschlossen die Applikation für Windows Mobile 5 und höher auszulegen, da dass Windows Mobile 5 SDk bereits anständige Benachrichtigungs-Mechanismen mitbringt. Diese lassen sich ganz einfach mittels der im WM 5 SDK enthaltenen Managed DLLs einbinden. Benötigt werden die Namespaces Microsoft.WindowsMobile sowie Microsoft.WindowsMobile.Status. Damit kann man dann schon eine ganze Menge machen, u.a. kann man sich so auf einen verpassten Anruf-Event registrieren (PhoneMissedCall).

Die Oberfläche ist soweit entworfen, die Registrierung der Events ist auch funktionsfähig. Erste Tests sind auch bereits erfolgreich verlaufen, so zeigte das Programm in seiner Logausgabe an: „verpasster Anruf: +49xxxxxxxxxxx“ (die Zahlen wurden bewusst durch x ersetzt). Hier noch zwei Screenshots der Anwendung im Emulator:

Ansonsten gab es doch einige Anlaufschwierigkeiten, so muss man leider sagen, dass man ab einem gewissen Grad nicht um Microsofts Visual Studio herumkommt, da hier die Integration von Deployment und Device Emulator einfach runder wirkt als mit SharpDevelop o.ä. Oder etwas anders formuliert: Microsoft hat seine SDK Installer Files derart mit Voraussetzungen gepflastert (Visual Studio, ActiveSync, …), dass man wohl erst die Chance hat die Installation durchzuführen, wenn man den Orca MSI Editor von Microsoft zum patchen dieser Installer Dateien nutzt. So wollte ich zum Beispiel auf meiner virtuellen Maschine nicht unbedingt ActiveSync installieren (man müllt ja nicht sein Produktiv-System zu 😉 ), also wurde ein Patch der „Windows Mobile 5.0 Pocket PC SDK.msi“ Installer Datei fällig, dass es ActiveSync nicht zwingend erfordert etc. Irgendwann hatte ich dann aber keine Lust mehr die Steine aus dem Weg zu räumen, die Microsoft bereit legt…

Dies nun nur als kleiner Appetit-Anreger und als Zeichen dafür, dass es voran geht. Sobald die erste lauffähige Version fertig wird, werde ich diese hier veröffentlichen.

Idee zur Windows Mobile Applikation

Es gibt Neuigkeiten an der Entwicklungsfront mit dem Compact Framework 2.0 SP 1 und SharpDevelop. Anfangs sträubte sich SharpDevelop noch etwas das Compact Framework zu erkennen, aus irgendeinem Grund hat es sich dann aber nach diversen Versuchen und Forenbesuchen anders entschieden. Genau sagen, woran es lag, kann ich nicht. Ich denke, dass es an der Installationsreihenfolge liegt.

Man sollte zuerst die CompactFramework Runtimes installieren, danach das Windows Mobile 6 SDK und im Anschluß die gewünschten SDKs für das jeweilige Framework.

Achtung: Wenn man sich auf die Suche nach dem CompactFramework SDK begibt, wird man viele Treffer finden. Es sei hier aber gesagt, dass man das CompactFramework SDK mit den „normalen“ SDKs bekommt. So wird bei der Installation des .Net 2.0 SDK auch das zugehörige CompactFramework SDK auf die Platte kopiert.

Die erste kleine Demo-Applikation (klassisch >Hello World< im Fenster) war in 2 Minuten mit .Net 2.0 geschrieben. Ältere Versionen von Windows Mobile müssen zuerst mit dem .Net Framework in der richtigen Version versorgt werden (Deployment über ActiveSync), Windows Mobile 6 bringt aber bereits alles mit.

Was ist nun die Idee für meine erste Anwendung unter Windows Mobile ? Sie nennt sich „PhoneEventNotifier“ und soll die akustische Signalisierung eines verpassten Ereignisses übernehmen. Der XDA comet signalisiert ein solches Ereignis über eine Status-LED oben am Gerät, diese blinkt dann rot. Dies soll nun noch durch eine Software unterstützt werden, die einen einstellbaren Ton in einem einstellbaren Intervall wiedergibt. So machte das nämlich mein Motorola V3i (habe ich übrigens verkauft mittlerweile) – auch wenn ansonsten recht wenig innovativ war – meiner Meinung nach. An diese Art der Benachrichtigung hatte ich mich im Laufe der zwei Jahre, in denen ich das V3i hatte, gewöhnt und vermisse diese Funktionalität nun etwas bei meinem comet.

Wie soll die Software nun aussehen ? Nun, sie soll im natürlich Hintergrund laufen und mittels eines Timers gesteuert werden. Es soll natürlich immer nur auf ein einziges verpasstes Ereignis reagiert werden, nicht dass sich verpasste Ereignisse kumulieren und das Gerät zig-Mal in verschiedenen Intervallen akustische Signale ausgibt. Ebenso soll eine Zeitspanne einstellbar sein, in der das Gerät keine Signale ausgeben soll (quiet period), bspw. nachts. Die Einstellungen sollen ganz unspektakulär in einem kleinen Fenster (Tab) im Programm vorgenommen werden können.

Ansonsten reift die Idee und ich hoffe, dass ich bald erste Ergebnisse respektive Screenshots liefern kann (Hauptproblem ist wie immer die Zeit für so etwas zu erübrigen 🙁 ). Ich halte die geneigten Leser natürlich auf dem Laufenden 😉