Jedoch stieß ich in einem aktuellen Projekt auf ein sehr seltsames Problem:

Bei einigen Formularen (seltsamerweise nicht bei allen) wurde eine sehr teure SQL-Abfrage an das Datenbank-Backend gesendet während das Formular geladen wurde. Es war im Prinzip eine SQL-Abfrage, die sämtliche (und ich meine wirklich alle) Datenzeilen von der Datenbank lud, was offensichtlich keine besonders gute Idee ist. Aber wie geschrieben war das nicht für alle Formulare der Fall: Bei den anderen Formularen wurde erwartungsgemäß nur das aktuelle Datenobjekt (die aktuelle Zeile der Tabelle) geladen.

Natürlich kontaktierte ich zunächst den immer sehr schnellen und hilfreichen DevExpress-Support. Sie haben untersucht, was die Datenabfrage auslöst und festgestellt, dass die Eigenschaft XPCollection.Count von dem CurrencyManager nach dem Methodenaufruf Control.UpdateBindings angefordert wird. Da dies etwas innerhalb des .NET Frameworks ist, konnten sie daran leider nichts ändern.

Sie schlugen vor die XPCollection nicht zur Design-Zeit zu setzen. Dies hätte jedoch bedeutet, dass ich die Formulare nicht mehr mit dem Windows-Formular-Designer erstellen könnte. Das wäre ganz schlecht, da ich viele große Formular in diesem Projekt habe, die ich sicherlich nicht alle im Quelltext erstellen möchte.

Ich fand jedoch einen andere Weg – ich nenne das nicht eine Lösung, nur ein Work-Around –, um den Designer weiterhin verwenden zu können:

Hierzu habe ich einfach zwei Batch-Dateien (unter Verwendung des Kommandozeilen-Ersetzungstools namens FART (Englisch)) geschrieben: Eine, die ausgeführt wird bevor das Build beginnt und sicherstellt, dass keine XPCollection innerhalb der Methode InitializeComponent initialisiert wird (und dabei einfach die Quelltextzeilen auskommentiert), und eine zweite, die nach dem Build läuft und die Änderungen wieder rückgängig macht.

Hier ist der Inhalt der Pre-Build-Batch-Datei:

%1Tools\fart.exe -r -C "%1*.designer.cs" "this.xpKern = new DevExpress.Xpo.XPCollection(this.components);" "\x2f\x2fthis.xpKern = new DevExpress.Xpo.XPCollection(this.components);"
%1Tools\fart.exe -r -C "%1*.designer.cs" "((System.ComponentModel.ISupportInitialize)(this.xpKern)).BeginInit();" "\x2f\x2f((System.ComponentModel.ISupportInitialize)(this.xpKern)).BeginInit();"
%1Tools\fart.exe -r -C "%1*.designer.cs" "this.xpKern.ObjectType = typeof(Administration.Daten.Kern);" "\x2f\x2fthis.xpKern.ObjectType = typeof(Administration.Daten.Kern);"
%1Tools\fart.exe -r -C "%1*.designer.cs" "this.xpKern.Session = this.unitOfWork;" "\x2f\x2fthis.xpKern.Session = this.unitOfWork;"
%1Tools\fart.exe -r -C "%1*.designer.cs" "((System.ComponentModel.ISupportInitialize)(this.xpKern)).EndInit();" "\x2f\x2f((System.ComponentModel.ISupportInitialize)(this.xpKern)).EndInit();"

@exit 0

Und die Post-Build-Datei, welche die Änderungen wieder rückgängig macht:

%1Tools\fart.exe -r -C "%1*.designer.cs" "\x2f\x2fthis.xpKern = new DevExpress.Xpo.XPCollection(this.components);" "this.xpKern = new DevExpress.Xpo.XPCollection(this.components);"
%1Tools\fart.exe -r -C "%1*.designer.cs" "\x2f\x2f((System.ComponentModel.ISupportInitialize)(this.xpKern)).BeginInit();" "((System.ComponentModel.ISupportInitialize)(this.xpKern)).BeginInit();"
%1Tools\fart.exe -r -C "%1*.designer.cs" "\x2f\x2fthis.xpKern.ObjectType = typeof(Administration.Daten.Kern);" "this.xpKern.ObjectType = typeof(Administration.Daten.Kern);"
%1Tools\fart.exe -r -C "%1*.designer.cs" "\x2f\x2fthis.xpKern.Session = this.unitOfWork;" "this.xpKern.Session = this.unitOfWork;"
%1Tools\fart.exe -r -C "%1*.designer.cs" "\x2f\x2f((System.ComponentModel.ISupportInitialize)(this.xpKern)).EndInit();" "((System.ComponentModel.ISupportInitialize)(this.xpKern)).EndInit();"

@exit 0

Das @exit 0 am Ende dieser ist wichtig, da ansonsten ein Code 2 zurückgegeben wird (warum auch immer) und das Visual-Studio-Build-System sich bei jedem Build darüber beschwert.

Nun müssen Sie nur doch diese Batch-Dateien in den Visual-Studio-Buildereignissen mit

$(ProjectDir)Tools\PreBuild.bat $(ProjectDir)

beziehungsweise

$(ProjectDir)Tools\PostBuild.bat $(ProjectDir)

aufrufen.

Ich weiß, dass dies keine besonders gute “Lösung” ist, aber das war die einzige Idee, die ich hatte, dass ich weiterhin den Formular-Designer verwenden kann und trotzdem diese teuren SQL-Anfragen vermeide.

Hatten Sie bereits einmal dieses Problem und vielleicht sogar eine bessere Lösung dafür? Ich freue mich über jeden anderen Vorschlag zu diesem Thema!

Dort werde ich eine Session über “Intel AppUp – Deine HTML5-/.NET-App im App-Store” anbieten:

Möchte man als Entwickler sein Produkt an die Frau oder den Mann bringen, so ist jeder neue Vertriebsweg willkommen. Einer davon ist der von Intel betriebene App-Store AppUp, der auf vielen heute verkauften Notebooks (z. B. von notebooksbilliger.de) bereits vorinstalliert ist. In dieser Session zeigt Andreas Breitschopp wie eine vorhandene HTML5- oder .NET-App fit für AppUp gemacht wird. Gerne dürfen die Teilnehmer auch eigene Produkte mitbringen, die dann gemeinsam zur Veröffentlichung auf AppUp vorbereitet werden.

Natürlich gibt es bei der Konferenz auch andere interessante Themen und die Teilnahme ist kostenlos.

Daher würde ich mich freuen auch Sie dort zu treffen!

Das funktioniert stets problemlos, wenn die Client-Anwendung das erste Mal startete und die Objekte des Windows-Dienste aufrief. Aber nachdem die Client-Anwendung einige Minuten später neu gestartet wurde (ohne den Dienst neu zu starten), kam es zu einer RemotingException mit dieser seltsamen Fehlermeldung:

Fehler beim Schreiben auf einen IPC-Port. Die Pipe wird gerade geschlossen.

Es hat eine ganze Weile gedauert bis ich das Problem gefunden habe:
Da es für meinen Dienst sehr wichtig ist wirklich nur eine Instanz des Remote-Objektes für die gesamte Lebensdauer des Dienstes zu haben, verwendete ich RemotingServices.Marshal, um ein zuvor instanziiertes Objekt zu registrieren. Jedoch wusste ich nicht, dass bei der Registrierung mit dieser Methode die Objekte standardmäßig nur eine sehr kurze Zeit (eine Minute) gültig bleiben.

Um das zu korrigieren, muss die Methode MarshalByRefObject.InitializeLifetimeService innerhalb des Remote-Server-Objektes wie folgt überschrieben werden:

public override Object InitializeLifetimeService()
{
	ILease lease = (ILease)base.InitializeLifetimeService();
	if (lease.CurrentState == LeaseState.Initial)
	{
		lease.InitialLeaseTime = TimeSpan.FromDays(365);
		lease.SponsorshipTimeout = TimeSpan.FromDays(365);
		lease.RenewOnCallTime = TimeSpan.FromDays(365);
	}
	return lease;
}

Und hier dasselbe für Entwickler mit VB .NET:

Public Overrides Function InitializeLifetimeService() As Object
	Dim lease As ILease = CType(MyBase.InitializeLifetimeService(), ILease)
	If lease.CurrentState = LeaseState.Initial Then
		lease.InitialLeaseTime = TimeSpan.FromDays(365)
		lease.SponsorshipTimeout = TimeSpan.FromDays(365)
		lease.RenewOnCallTime = TimeSpan.FromDays(365)
	End If
	Return lease
End Function

OK, 365 Tage sind vielleicht etwas übertrieben, aber so können Sie sicher sein, dass Ihre Remote-Objekte so schnell nicht verfallen werden.

Haben Sie diese Problem selbst auch schon einmal gehabt?

Das Ergebnis war jedoch folgende Fehlermeldung, sobald ich versuchte eine meiner abgeleiteten Formularklassen in dem Formular-Designer des Visual Studios zu öffnen:

Der Designer kann keine Instanz des Typs <Typname> erstellen, da dieser als abstrakt deklariert ist.

Daraufhin suchte ich eine Lösung im Internet und es scheint als wäre ich nicht der Einzige, der die Idee hatte einige Formularklassen von einer abstrakten Basisklasse abzuleiten. Um das Problem zu lösen, erstellte ich eine Dummy-Implementierung von meiner abstrakten Basisklasse und leitete die Formularklassen von dieser Dummy-Implementierung ab. Dadurch konnten die Formularklassen wieder im Visual Studio Formular-Designer angezeigt werden.

In C# sehen die Klassen nun so aus:

public abstract partial class BaseForm : Form
{
  // Methoden der abstrakten Basisklasse...
}

#if DEBUG
public class BaseFormImpl : BaseForm
{
  // Dummy-Implementierung der abstrakten BaseForm-Klasse.
}
#endif

#if DEBUG
public partial class RealForm : BaseFormImpl
#else
public partial class RealForm : BaseForm
#endif
{
  // Eins der Formular, das das Basis-Formular erweitert.
}

Und für Entwickler mit VB .NET sieht es so aus:

Public MustInherit Partial Class BaseForm
  Inherits Form
  ' Methoden der abstrakten Basisklasse...
End Class

#if DEBUG
Public Class BaseFormImpl
  Inherits BaseForm
  ' Dummy-Implementierung der abstrakten BaseForm-Klasse.
End Class
#endif

Public Partial Class RealForm
#if DEBUG
  Inherits BaseFormImpl
#else
  Inherits BaseForm
#endif
  ' Eins der Formular, das das Basis-Formular erweitert.
End Class

Nun sind Ihnen sicherlich die Compiler-Anweisungen aufgefallen: Natürlich wären diese nicht erforderlich, damit die Formulare wieder korrekt im Formular-Designer funktionieren. Jedoch mag ich keinen unnötigen Quelltext im veröffentlichten Produkt (und diese Dummy-Implementierung der abstrakten BaseForm-Klasse ist wirklich nutzlos). Daher habe ich diese bedingten Compiler-Anweisungen verwendet, um sicherzustellen, dass diese Dummy-Klasse wirklich nur im Debug-Modus verwendet wird.

Sind Sie selbst auch bereits einmal auf dieses Problem gestoßen?

Neben dem Parsen und Auswerten von Formeln mit allen gängigen mathematischen Funktionen (wie Sinus, Cosinus, Logarithmus, …) sollte es auch möglich sein Variablen in den Formeln zu verwenden.

Die beste Lösung, die ich fand, ist diese hier:
http://www.lundin.info/mathparser.asp (Englisch)

Die Verwendung ist sehr einfach; hier ein Beispiel-Code in C#:

// Parser instanziieren
ExpressionParser parser = new ExpressionParser();

// Erstellen einer Hashtable für die Werte
Hashtable h = new Hashtable();

// Variablen und Werte zur Hashtable hinzufügen
h.Add("x", 1.ToString());
h.Add("y", 2.ToString());

// Parsen und Ergebnis holen
double result = parser.Parse("xcos(y)", h);

Und für diejenigen, die Visual Basic .NET bevorzugen:

' Parser instanziieren
Dim parser As New ExpressionParser()

' Erstellen einer Hashtable für die Werte
Dim h As New Hashtable()

' Variablen und Werte zur Hashtable hinzufügen
h.Add("x", 1.ToString())
h.Add("y", 2.ToString())

' Parsen und Ergebnis holen
Dim result As Double
result = parser.Parse("xcos(y)", h)

Es ist wichtig, dass die Werte dabei stets als String zur Hashtable der Variablen hinzugefügt werden. Der Grund dafür ist, dass diese intern einfach in die Formel eingefügt werden, bevor diese geparst wird – entsprechend müssen sie natürlich vom Typ String sein.

Die kostenlose Bibliothek is Open-Source und unter der LGPL lizensiert. Dadurch kann sie auch in kommerziellen Projekten eingesetzt werden, solange sie dynamisch als externe Bibliothek eingebunden wird.

Zunächst ein Quelltextausschnitt, danach erkläre ich, was es damit aufsich hat:

const double frequency	= 1000;
const double amplitude	= 20000;
const long sampleRate	= 44100;
const int durationSec	= 5;

long sampleCount = sampleRate * durationSec;

double timeStep = 1.0 / (double)sampleRate;

double time = 0;
int[] values = new int[sampleCount];
for (long i = 0; i < sampleCount; i++) {
	values[i] = (int)(amplitude * Math.Sin(2 * Math.PI * frequency * time));
	time = time + timeStep;
}

Gut, nun also ein paar Erklärungen:

• Zeilen 1-4: Einige Konstanten, die geändert werden können, um z. B. die Frequenz anzupassen.
  Hinweis: Die Frequenz kann maximal die Hälfte der Abtastrate betragen.
• Zeile 6: Berechnung der Anzahl an Abtastpunkten.
• Zeile 8: Berechnung der Zeit zwischen zwei Abtastpunkten.
• Zeilen 10-11: Ein paar Variablen-Initialisierungen.
• Zeilen 12-15: Hier wird schlussendlich der Wert für jeden Abtastpunkt berechnet.

Und nun noch der entsprechende Quelltext für Visual Basic .NET:

const frequency as double		= 1000
const amplitude as double		= 20000
const sampleRate As Long		= 44100
const durationSec As Integer	= 5

Dim sampleCount As Long
sampleCount = sampleRate * durationSec

Dim timeStep As Double
timeStep = 1.0 / sampleRate

Dim time As Double = 0
Dim values(0 To sampleCount - 1) As Integer
For i As Long = 0 To sampleCount - 1
	values(i) = amplitude * Math.Sin(2 * Math.PI * frequency * time)
	time = time + timeStep
Next i

Um das Ganze abzuspielen, kann man nun entweden einen API-Aufruf wie PlaySound (von winmm.dll) oder die Lösung dieses super Artikels (Englisch) verwenden.

Haben Sie auch bereits einmal einen Sinus in .NET generieren müssen?

Die erste zu treffende Entscheidung ist die Programmiersprache, welche Sie für die Entwiclung der Internet-Explorer-Toolbar verwenden möchten. Bei meinen Recherchen im Internet fand ich Beispiele für C++, Visual Basic 6 und .NET. Es scheint einige Visual-Style-Probleme zu geben, wodurch die Toolbar bei System mit Windows Vista und Windows 7 nicht sonderlich gut aussieht, wenn C++ verwendet wird. Und nachdem ich wirklich keine Lust hatte noch in Visual Basic 6 zu entwickeln, entschied ich mich für .NET. Der einzige Nachteil dieser Entscheidung war, dass der Benutzer das .NET Framework 2.0 (oder neuer) auf seinem System installiert haben muss. Damit kann ich jedoch leben, da es bereits sehr verbreitet ist.

Aufgrund dessen, dass fast alle meine Produkte in .NET entwickelt sind, hatte ich bereits Visual Studio 2008 auf meinem Computer installiert. Falls Sie das nicht haben, benötigen Sie zumindest die Express Edition (Version 2005 sollte auch ausreichen) für die nächsten Schritte. Ich entschied die Toolbar in C# zu entwickeln, aber mit Visual Basic .NET ginge das selbstverständlich auch.

Als ein guter Ausgangspunkt fand ich diesen (Englisch) und diesen (Englisch) Artikel auf der Code-Project-Webseite. Falls Sie mehr über die COM-Komponente wissen möchten, können Sie auch das C++-Tutorial (Englisch) lesen, aber das ist nicht unbedingt erforderlich. Unter Verwendung der Beispiel-Quelltexte dieser beiden Artikel, sollten Sie eine funktionierende Toolbar erhalten – zumindest auf einem Windows-XP-System. Jedoch stieß ich auf einige Probleme, die behoben werden mussten und die ich daher im Folgenden näher beschreiben werde:

Sicherstellen, dass die Toolbar auf sämtlichen Betriebssystemen korrekt angezeigt wird

Mit dem Demo-Quelltext der oben erwähnten Artikel habe ich die Toolbar ziemlich schnell auf meinem Windows-XP-Testrechner zum Laufen bekommen. Naiverweise ging ich davon aus, dass die Toolbar, die auf Windows XP mit Internet Explorer 8 korrekt funktioniert, auch auf Windows Vista und Windows 7 mit derselben Internet-Explorer-Version funktionieren würde. Aber tatsächlich musste ich lernen, dass dies absolut nicht der Fall ist! Sie wurde entweder überhaupt nicht dargestellt oder soweit auf der rechten Seite, dass man sie nur mit einer horizontalen Auflösung von mindestens 2.000 Pixel sehen konnte. Somit musste ich nach einer Lösung suchen, jedoch die meisten Quelltextänderungen führten nur dazu, dass die Toolbar entweder auf dem einen oder dem anderen Betriebssystem beziehungsweise der einen oder anderen Browserversion funktionierte. Nach einigen Stunden frustrierendem Testen, habe ich die GetBandInfo-Funktion der BandObjectsLib-Klasse wie folgt geändert. Obwohl ich nach wie vor nicht ganz sicher bin weswegen, so funktioniert es nun auf allen Betriebssysteme problemlos:

public virtual void GetBandInfo(UInt32 dwBandID, UInt32 dwViewMode, ref DESKBANDINFO dbi)
{
    if ((dbi.dwMask & DBIM.MINSIZE) != 0)
    {
        dbi.ptMinSize.X = this.MinimumSize.Width;
        dbi.ptMinSize.Y = this.MinimumSize.Height;
    }

    if ((dbi.dwMask & DBIM.MAXSIZE) != 0)
    {
        dbi.ptMaxSize.X = this.MaximumSize.Width;
        dbi.ptMaxSize.Y = this.MaximumSize.Height;
    }

    if ((dbi.dwMask & DBIM.ACTUAL) != 0)
    {
        dbi.ptActual.X = this.Size.Width;
        dbi.ptActual.Y = this.Size.Height;
    }

    if ((dbi.dwMask & DBIM.BKCOLOR) != 0)
    {
        dbi.dwMask &= ~DBIM.BKCOLOR;
    }

    dbi.dwModeFlags = DBIMF.BREAK;
}

Hübschere Darstellung auf Windows XP und neuer

Wenn Sie den folgenden Ereignis-Handler in der BandObjectsLib-Klasse nicht hinzufügen, wird Ihre Toolbar zwar dennoch funktionieren, aber einfach nicht sonderlich schön auf Windows XP und neuer aussehen. Die if-Anweisung in der Ereignisfunktion stellt dabei sicher, dass die Toolbar auch auf älteren Betriebssystemen wie Windows 98, 2000 und ME nach wie vor funktioniert. Ansonsten würde es zu einer Ausnahme auf diesen Betriebssystemen kommen. Hier ist der Quelltext, den ich verwendet habe, um es auf sämtliche Betriebssystem korrekt zum Laufen zu bringen:

[DllImport("uxtheme", ExactSpelling = true)]
public extern static Int32 DrawThemeParentBackground(IntPtr hWnd, IntPtr hdc,
                                                     ref Rectangle pRect);

protected override void OnPaintBackground(PaintEventArgs e)
{
    if (System.Environment.OSVersion.Platform >= PlatformID.Win32NT &&
           (Environment.OSVersion.Version.Major == 5 &&
            Environment.OSVersion.Version.Minor >= 1 ||
            Environment.OSVersion.Version.Major >= 6) &&
           this.BackColor == Color.Transparent)
    {
        // Only if operating system is Windows XP or higher
        IntPtr hdc = e.Graphics.GetHdc();
        Rectangle rec = new Rectangle(e.ClipRectangle.Left,
            e.ClipRectangle.Top, e.ClipRectangle.Width, e.ClipRectangle.Height);
        DrawThemeParentBackground(this.Handle, hdc, ref rec);
        e.Graphics.ReleaseHdc(hdc);
    }
    else
    {
        base.OnPaintBackground(e);
    }
}

Keine Serialisierung erlaubt

Bei der Entwicklung einer Firefox-Toolbar können Sie den Mozilla-Preferences-Dienst verwenden, um benutzerdefinierte Werte direkt innerhalb Firefox abzuspeichern und zu laden. Da es im Internet Explorer kein Gegenstück dazu gibt und ich XML-Serialisierung in vielen anderen .NET-Produkten verwende, wollte ich diese in dem Toolbar-Projekt ebenfalls verwenden. Auf den ersten Blick funktionierte das auch einwandfrei, aber wenn im Internet Explorer 8 der Protected Mode aktiviert ist (und das ist er standardmäßig, zumindest seit Windows Vista), bekommt der Benutzer ein hässliches Warnungsfenster jedes Mal angezeigt, wenn die Toolbar initialisiert wird. Den Grund dafür werde ich nun nicht im Detail erläutern; verwenden Sie einfach keine Serialisierung in Internet-Explorer-Toolbars. Sie können benutzerdefinierte Werte entweder ohne Serialisierung im Dateisystem unterhalb des lokalen Anwendungsdatenverzeichnisses abspeichern oder einfach die Registry verwenden.

Automatisches Online-Update

Wie in der Firefox-Version, wollte ich auch, dass die Internet-Explorer-Toolbar eine automatische Update-Funktion beinhaltet. Da es jedoch kein Update-System für Toolbars wie im Firefox gibt, musste ich ein eigenes implementieren. Dies ist jedoch relativ einfach, zumal man – wie auch in anderen .NET-Anwendungen – einfach die WebClient-Klasse verwenden kann, um zunächst eine HTTP-Anfrage zu machen, ob ein Update verfügbar ist, und um danach die Update-Datei herunterzuladen, falls erforderlich. Auf der Serverseite nutze ich eine kleines PHP-Skript, das sich um die Update-Anfrage kümmert. Die Update-Datei, die heruntergeladen wird, ist die normale Setup-Datei, welche einfach sämtliche Dateien mit neuen überschreibt. Das Einzige, auf was Sie achten müssen, ist die Art und Weise, wie Sie die ausführbare Setup-Datei nach dem Download aufrufen, da ansonsten ein Dialog der Benutzerkontensteuerung (UAC) angezeigt wird. Ich habe folgende Prozedur geschrieben, die Sie verwenden können, um eine Datei aus der Toolbar heraus auszuführen, ohne dass irgendeine Warnung dem Benutzer angezeigt wird:

private void startProcess(string fileName, string arguments)
{
    System.Diagnostics.ProcessStartInfo startInfo =
        new System.Diagnostics.ProcessStartInfo();
    startInfo.UseShellExecute = true;
    startInfo.WorkingDirectory = Environment.CurrentDirectory;
    startInfo.FileName = fileName;
    if (Environment.OSVersion.Platform >= PlatformID.Win32NT &&
            Environment.OSVersion.Version.Major >= 6)
        // Only if operating system is Windows Vista or higher
        startInfo.Verb = "runas";
    else
        startInfo.Verb = "open";
    startInfo.Arguments = arguments;
    startInfo.ErrorDialog = true;
    try
    {
        System.Diagnostics.Process process = System.Diagnostics.Process.Start(startInfo);
        process.WaitForExit();

        MessageBox.Show(objToolbarData["msg.restartBrowserText"],
                        objToolbarData["msg.restartBrowserTitle"],
                        MessageBoxButtons.OK, MessageBoxIcon.Information);
    }
    catch (Exception ex)
    {
        if (debugMode) MessageBox.Show(ex.ToString());
    }
}

Deinstallationsschaltfläche innerhalb der Toolbar

Das war das Einzige, was im Internet Explorer einfacher zu implementieren war als im Firefox; es muss lediglich das Deinstallationsprogramm (wieder mit der startProcess-Prozedur von oben) des Installationssystems (siehe nächster Post###) ausgeführt werden, um die Toolbar wieder zu deinstallieren. Nach einem Browser-Neustart wird sie dann nicht mehr angezeigt (wie auch beim Firefox).

Geschafft; die Internet-Explorer-Version von unserer Toolbar ist nun auch fertig! Sie wird mit Internet Explorer 6 oder neuer auf Windows 98 oder neuer mit installiertem .NET Framework 2.0 funktionieren.

Im nächsten Artikel werde ich erklären, wie die Toolbars installiert werden.

Inhalt der Artikelserie “Entwicklung einer Browser-Toolbar”:

• Einführung
• Mozilla Firefox
• Microsoft Internet Explorer
• Installationssystem
• Zusammenfassung