Sonstiges

Es gibt Dinge die sind so unglaublich, dass man sie wirklich nicht glauben kann...

Ich habe in VB 2005 eine Anwendung entwickelt (eigentlich bin ich noch dabei...) und habe ein weiteres Formular hinzugefügt. Dieses Formular enthält 2 Textboxen und 2 Buttons (Abbrechen und OK). Jetzt soll der Button OK aber erst enabled sein, wenn in beiden Textboxen was drin steht und in der zweiten Textbox der Text genau 10 Zeichen lang ist. Soweit eigentlich recht einfach.  Das Formular wird über ShowDialog() aufgerufen (bei Show() passiert aber genau das gleiche).

Ich starte meine Anwendung, öffne das Formular und tippe etwas in die erste Textbox. Und beim ersten Buchstaben erhalte ich eine "LoaderLock wurde erkannt"-Fehlermeldung. Da soll ich verwalteten Code wärend der Sperre für das Betriebsystemladeprogramm gestartet haben... Was? Ich prüfe doch nur die Länge des Texts.

Selber etwas rumprobiert und nix gefunden. Und dann im Internet gesucht. Die Lösung des Problems ist so absurd, dass man da nie drauf kommt. Es liegt an iTunes. Dem von Apple. Genau. Dem Musikprogramm. Und zwar (bei mir) in der Version 7.1.1.5. Wenn iTunes geladen ist (egal ob Musik läuft oder nicht), dann kommt dieser Fehler.  Und wenn man iTunes beendet, dann kommt der Fehler nicht mehr. Jetzt liegts wahrscheinlich nicht direkt an iTunes, sondern an irgendeiner Windows-Merkwürdigkeit...

Mit einer neuern Version von iTunes (7.2) soll der Fehler nicht mehr auftreten. Aber das muss ich erst noch testen.

Dictionaries sind toll. Man kann damit die Bedeutung von Wörtern aus anderen Sprachen herausfinden. Aber natürlich sind diese Wörterbücher hier garnicht gemeint. Es geht um die in VB 2005 enthaltenen Generics. Diese haben das Ziel, gleiche Elemente in Listen zusammenzufassen (ähnlich Collections), bieten aber gegenüber Collections, Arrays oder selber geschriebenen Listen einiges an Komfort und Sicherheit. Es gibt mehrere Arten von Generics, darunter das Dictionary. In diesem Dictionary wird mit jedem Wert ein Schlüssel verknüpft (Key->Value - Paare). Der Wert kann dabei jeder beliebige Datentyp und natürlich auch ein Objekt sein. Erstellt wird das ganze über:

dim myDic as As New System.Collections.Generic.Dictionary(Of String, CBeispiel)

Der Schlüssel ist damit ein String (er könnte auch eine Zahl oder ein anderer Datentyp sein) und die Werte sind vom Typ CBeispiel, welches eine Beispiel-Klasse sein soll (der Inhalt der Klasse ist egal). Werte hinzufügen ist ganz einfach:

myDic.add ("Schluessel1", beispiel1)

beispiel1 muss natürlich ein Objekt der Klasse CBeispiel sein. Auch das Abrufen ist sehr einfach:

beispiel1 = myDic.Item ("Schluessel1")

Sehr schön gelöst ist das durchlaufen aller Werte in einer Schleife. Mit Foreach kann man hier sehr einfach alle Elemente durchlaufen und bearbeiten:

For Each kvp As KeyValuePair(Of String, CBeispiel) In myDic
kvp.Value ' enthält den Wert
kvp.Key ' enthält den Schlüssel
Next kvp

Dabei wird das gesamte Dictionary hintereinander durchlaufen.

So weit so gut und schön. Aber was passiert, wenn man nicht auf einmal das gesamte Dictionary durchlaufen will. Sondern z.B. durch einen Timer gesteuert immer das nächste Element haben möchte. Dann ist For Each nicht das richtige. Allerdings kann man sich die For Each zugrunde liegende Struktur zunutze machen. Diese heißt Enumerator und ist auch ohne For Each einsetzbar. Zuerst muss ein entsprechender Enumerator erstellt werden:

Dim myEnumerator As System.Collections.Generic.Dictionary(Of String, CBeispiel).Enumerator
myEnumerator = myDic.GetEnumerator

Damit wird der Enumerator erstellt und er ist jetzt mit dem Dictionary myDic "verbunden". Mit myEnumerator.MoveNext kann ich zum nächsten Eintrag im Dictionary gehen und mit myEnumerator.Current() kann ich auf den aktuellen Wert zugreifen. Dabei gibts aber noch ein paar Stolperfallen:

• Die Reihenfolge, in der die Elemente kommen, ist nicht festgelegt.


• Nach der Erstellung des Enumerators ist seine Position vor dem ersten Element. Man muss also zuerst MoveNext aufrufen, bevor man mit Current() auf den ersten Eintrag zugreifen kann.


• Wenn das Ende des Dictionaries erreicht ist, dann geht es nicht von Vorne wieder los. Man muss diesen Fall selber prüfen.

Die Prüfung, ob MoveNext noch ein nächste Element gefunden hat, ist glücklicherweise sehr einfach. Wenn keine weiteren Elemente vorhanden sind, dann gibt MoveNext nämlich false zurück.
If myEnumerator.MoveNext Then

Mit diesen paar Zeilen Code kann man sehr schön selber durch das Dictionary wandern und ist nicht auf For Each angewiesen (was aber oft seine Berechtigung hat).

Ich hab jetzt schon seit einigen Tagen mit einem ASP.NET 2.0 Projekt zu tun. Ursprünglich ging es nur darum, die Datenbank von MS SQL-Server 2005 auf MS SQL-Server 2000 zu portieren, was nicht so ganz ohne Tücken ist. Und dann kamen noch hier und dort weitere Kleinigkeiten, die zu ändern sind. Ist ne ganze Menge Arbeit und nicht immer einfach.

Was mich mittlerweile wirklich nervt, ist das Visual Studio keine Beziehung zwischen der Entwurfsansicht und dem Quellcode herstellt. Oder zumindest (wenn denn eine Beziehung vorhanden ist), diese nicht nutzt. Mal angenommen ich ändere im Quellcode eine Webseite (abcd.aspx) etwas und gehe dann in die Entwurfsansicht, um mir die Änderung anzusehen. Das funktioniert natürlich. Wenn ich jetzt aber wieder zurück in den Quellcode der Webseite gehe, dann ist der Cursor immer am Anfang der Seite. Immer. Und ich muss dann erst wieder den ganze Quellcode durchscrollen, um an die gewünschte Stelle zu kommen.

Warum kann Visual Studio sich nicht merken, an welcher Stelle ich zuletzt im Quellcode war? Kann doch nicht so schwer sein, oder?

Oder noch besser wäre folgendes: Wenn ich in der Entwurfsansicht ein Objekt anklicke und dann in den Quellcode wechsle, dann springt der Cursor automatisch an die Stelle, wo der Code des Objekts beginnt. Das würde die Arbeit echt erleichtern, weil es das ständige Quellcode-Durchsuchen erspart.

Wahrscheinlich möchte Microsoft, dass man möglichst garnicht im Quellcode arbeitet und alles nur in der Entwurfsansicht macht. Aber manche Sachen gehen halt im Quellcode einfach schneller.

Manche Probleme können einen schon Nerven kosten. Und manche Programme auch. Eins davon ist sicherlich MS Access. Ich betreue schon seit einiger Zeit einen Kunden, der ein Access-Programm hat. Das ursprüngliche Programm stammt gar nicht von mir. Ich habe es aber immer mal wieder etwas aufgebohrt und erweitert. Also hier mal eine Eingebemöglichkeit mehr, dort noch eine Option ...

Und je mehr Dinge kamen, umso mehr und öfter gibt es Probleme. Das letzte Problem war folgendes: Ab und zu bekam ich eine email vom Kunden mit der Access-Datei und der Fehlermeldung: Der Speicher ist voll.

Was sollte eigentlich passieren: Man gibt in einer Kunden-Eingabe-Maske (Formular) einen neuen Kunden an. Diese Daten werden in einer Tabelle Kunde gespeicht und jetzt werden verschiedene Abfragen darübergejagt. Anschließend kommt in einem weiteren Formular das Ergebnis für den zuletzt eingetragenen Kunden.

Und was ist tatsächlich passiert: Nach der Kundeneingabe wurden die Daten auch in die Tabelle Kunde geschrieben, aber bei der Anzeige des Ergebnisses wurden die Daten eines anderen Kunden (der irgendwann vorher eingegeben wurde) angezeigt. Wenn man sich die Abfragen anschaute, schienen die Daten des letzten Kunden einfach nicht vorhanden zu sein.

Das ist sehr merkwürdig. Hat Access hier tatsächlich mit einigen Zeilen in der Tabelle schon Probleme (es waren etwa 65 Kunden vorhanden). Ist hier wirklich schon der "Speicher voll"?

Nach einigem Suchen, was denn vielleicht mit der Abfrage nicht stimmen könnte - also ein Fehler bei irgendeiner Berechnung, der dazu führt, dass die Kundendaten nicht berechnet werden - wurde ich schließlich fündig. Aber an anderer Stelle als erwartet. Die Daten des zuletzt eingegebenen Kunden waren tatsächlich in den Abfragen vorhanden. Nur nicht an letzter Stelle. Access hat sie (warum auch immer) irgendwo in der Mitte der Abfrage eingeordnet.

Jetzt viel die Lösung des Problems leicht. Ich muss einfach der Abfrage explizit sagen, dass sie sich nach den Kunden-Nummern aufsteigend sortieren muss. Dann ist der letzte Kunde auch wieder am Ende und alles funktioniert wieder.

Nachdem bei mir mal wieder Visual Studio rumgesponnen hat und der Inhalt einer Datei einfach weg war, habe ich mich entschlossen eine Versionsverwaltung zu installieren.

Was ist eine Versionsverwaltung? Das ist ein extra Programm, welches den Quellcode (eigentlich beliebigen Text) und Änderungen daran verwaltet. So kann man sehr einfach nachvollziehen, was wann geändert worden ist. Und man kann die Änderungen wieder rückggängig machen.

Nach etwas suchen viel meine Wahl auf Subversion (manch andere Alternativen sind einfach zu teuer). Es gibt eine ganz nette Anleitung von Jan-Cornelius Molnar. Eigentlich sind die Schritte recht gut beschrieben, nur der erste Test schlug bei mir fehl. Der Grund war schnell gefunden: Der Subversion-Server lief noch garnicht.

Sinnvollerweise soll der Server als Windows-Dienst laufen, was ab Version 1.4 auch möglich ist. Eine (leider englische) Anleitung dazu gibts hier. Danach mußte ich noch feststellen, dass in seinem Beispiel die URL zum Repository falsch ist. Sie muss folgendermaßen lauten (wie gesagt, in seinem Beispiel):
svn://localhost/SVN/repos/

Alternativ kann das ganze auch lokal über file angesprochen werden:
file:///c:/SVN/repos/

Eine weitere Sach, die noch zu beachten ist. Bei der Konfiguration von AnkhSVN können ja mit Strg+T die Vorlagen für Tortoise ausgewählt werden. Dazu in der Konfiguration auf bei dem entsprechenden Eintrag auf den Button mit den drei Punkten klicken und dann Strg+T drücken. Jetzt Tortoise... auswählen und den Pfad von "Program Files" auf "Programme" ändern, wenn ein deutsches Windows benutzt wird!

Einen Sound mit Visual Basic 2005 anzuspielen ist ganz ganz einfach:

My.Computer.Audio.Play("c:windowsmediachimes.wav")

Das wars schon.

Dieser Artikel beschreibt die Möglichkeiten mit Windows Mobile Datensätze abzufragen. Dabei werden die Ergebnisse der Abfrage in einem ResultSet zurückgegeben und die Frage der Anzeige der Ergebnisse behandelt. Dieser Artikel ist eine Fortsetzung von Datenbankzugriff mit Windows Mobile. Es gibt auch einen Artikel, der sich mit dem Bearbeiten von Datensätzen beschäftigt.

"Datensätze abfragen mit Windows Mobile" vollständig lesen »

Wenn man eine ListBox über die DataSource-Eigenschaft füllt, dann kann man über die Eigenschaft ValueMember eine Art Index festlegen. Sinnvoll ist das natürlich, wenn man auf die Daten einer Datenbank zugreift und in der ListBox die Inhalte einer Spalte anzeigen möchte, aber als Wert für jeden Inhalt braucht man noch den Primärschlüssel. Nur was macht man, wenn man die ListBox nicht über die DataSource-Eigenschaft füllt, sondern (z.B. aufgrund vorheriger Berechnungen oder Bearbeitungen) die Elemente per Items.Add einfügt. In diesem Fall steht ValueMember nicht zur Verfügung, aber man möchte trotzdem zu jedem Element dem zugehörigen Primärschlüssel speichern. (Gleiches gilt auch für die ComboBox.)

In diesem Fall muss man ein klein wenig Hand anlegen, um diese Funktionalität selber zu erstellen. Der Vorteil ist, dass die Methode Items.Add einer ListBox nicht einen String erwartet (was aber oft gemacht wird und auch ohne Fehler geht), sondern ein Objekt. Also schreiben wir uns einfach eine eigene Klasse, die wir der ListBox übergeben. In dieser Klasse speichern wir unseren anzuzeigenden Text und noch einen Index.

"ListBox mit eigenem Index" vollständig lesen »

In diesem Artikel werde ich die Bearbeitung (d.h. das Ändern, Löschen und Anlegen) von Datensätzen in Windows Mobile behandeln. Dieser Artikel ist die Fortsetzung von Datenbankzugriff mit Windows Mobile. Es gibt auch noch einen Artikel, der sich nicht mit dem Ändern, sondern mit dem Abfragen von Daten beschäftigt.

Wer vom vorherigen Artikel noch die beiden Varianten der Benutzung des Command-Objekts kennt: in diesem Artikel wird nur Variante 2, also das Ausführen von SQL-Befehlen behandelt. Auf die einzelnen SQL-Befehle werde ich auch nicht im Detail eingehen.

"Datensätze bearbeiten mit Windows Mobile" vollständig lesen »

Nachdem ich mich in vorherigen Artikeln grundlegend mit Datenbanken unter Windows Mobile und mit der Erstellung solch einer Datenbank beschäftigt habe, soll es jetzt um den praktischen Datenbankzugriff gehen. Grundlagen im Design von relationalen Datenbank und in SQL werden dabei erstmal vorrausgesetzt.

"Datenbankzugriff mit Windows Mobile" vollständig lesen »

Nachdem schon einige grundlegende Gedanken zu Datenbanken unter Windows Mobile geäußert wurden, soll es natürlich auch praktische Anleitung geben. Bevor es aber an die Abfrage der Datenbank geht, muss diese erstmal erstellt werden. Wie das geht, soll dieser Beitrag klären.

Benötigt werden dafür Visual Studio 2005 und das Windows Mobile 5 Pocket PC SDK. Ersteres muss man kaufen, letzteres kann man bei Microsoft kostenlos herunterladen. Aber ohne Visual Studio bringt das SDK halt nichts.

Die Erstellung und Verbindung zur Datenbank erfolgt im ServerExplorer. Dieser wird normalerweise links angezeigt (er teilt sich den Platz mit der Toolbox). Sollte er dort nicht angezeigt werden, dann kann man ihn im Menü Ansicht einblenden (oder man drückt Strg+Alt+S).

"Datenbank für Windows Mobile erstellen" vollständig lesen »

Um in einem Label in Visual Basic einen Zeilenumbruch zu setzen, muss man eine der beiden Konstaten vbNewLine oder vbCrLf nutzen. Das ganze sieht im Code dann so aus:Label1.Caption = "Zeile 1" & vbNewLine & "Zeile2"oderLabel1.Caption = "Zeile 1" & vbCrLf & "Zeile2"

Datenbanken auf einem PocketPC? Bei der geringen Hardware-Leistung? Geht das überhaupt? Macht das Sinn?

Will man hierauf eine klare Antwort geben, dann muss diese wohl Jein heißen. Ein großes Datenbanksystem (z.B. MySQL) auf ein PocketPC benutzen zu wollen, wird scheitern. Dazu sind die Geräte nicht leistungsfähig genug. An eine Datenbank auf dem PocketPC werden aber auch andere Ansprüche gestellt, als dies bei einem großen Datenbanksystem der Fall ist. Und wenn man diese Unterschiede beachtet, dann macht eine Datenbank auf einem PocketPC wieder Sinn und ist auch möglich.

Dieser Artikel soll eine Einführung in die Datenbank-Programierung unter Windows Mobile geben. Es werden noch mehr Artikel über das Thema folgen.
"Datenbank mit Windows Mobile" vollständig lesen »

Genau wie bei den "großen" Windows-Versionen, gibt es auch bei Windows Mobile eine Registry. Die Registry ist eine Datei, in der ganz viele System- und Programm-Einstellungen drin stehen. Auch für eigene Programme kann man dies nutzen, um dort Einstellungen abzulegen. Wie das geht, wird hier beschrieben. "Registry bei Windows Mobile" vollständig lesen »

Da hatte ich also meine erste Windows Mobile 5 Anwendung fertig und als Freeware ins Netz gestellt. Schon kurze Zeit später tauchten die ersten Probleme auf. Die meisten hingen damit zusammen, dass einige Windows Mobile 5 - Geräte eine andere Bildschirmauflösung verwenden. Mein Gerät hat ein Display mit 240x320 Zeichen. Es gibt aber noch 3 andere Möglichkeiten, also insgesamt 4 "Displays bei Windows Mobile 5 - Geräten" vollständig lesen »