Grundlagen der Windows - Programmierung
1. Programmablauf |
|
|
1.1 Zustandsgesteuerter Ablauf |
|
Herkömmliche Programme arbeiten meist zustandsgesteuert, d.h. die Funktionen werden sequentiell abgearbeitet, daß Programm wechselt aufgrund einer Benutzereingabe in den nachfolgenden Zustand. |
|
|
Vorteile:
Nachteile:
|
|
1.2 Ereignisgesteuerter Ablauf |
|
Ein fortschrittlicherer Programmierstil als der
zustandsgesteuerte ist der ereignisgesteuerte. Seit dem Siegeszug von
Microsoft Windows (R) werden die meisten Programme ereignisgesteuert
programmiert (nicht nur Windows - Software, diese ist nämlich nur
ereignisgesteuert realisierbar). Vorteile:
Nachteile:
|
2. Multitasking |
|
Als Multitasking wird jener Mechanismus bezeichnet, der es dem Betriebssystem ermöglicht, mehreren Programmen gleichzeitig Ressourcen zur Verfügung zu stellen. Dies kann beispielsweise durch ein Zeitscheibenverfahren realisiert werden, bei dem das Betriebssystem abwechselnd Zeit für die zu bearbeitenden Prozessen zur Verfügung stellt, oder durch echte Parallelität. |
|
2.1 Preemtives Multitasking |
|
Beim preemtiven Multitasking übernimmt das Betriebssystem die Kontrolle über die Programme. Es friert die laufenden Prozesse eín, um auf andere Prozesse umzuschalten. Der laufende Prozess wird nicht beendet, es werden lediglich seine Aktivitäten unterbrochen. Das Programm selbst muß sich nicht darum kümmern, wann und wo diese Unterbrechungen vorgenommen werden. Windows NT (R) verwendet preemtives Multitasking |
|
2.2 Nonpreemtives Multitasking |
|
Beim nonpreemptiven Multitasking (auch meldungsgetriebenes Multitasking genannt), daß von Windows 3.x (R) sowie Windows 95 (R) verwendet wird, muß sich der Prozeß selbst darum kümmern, daß andere Prozesse zum Zuge kommen. Deshalb waren unter Windows 3.x nur jene Programme multitaskingfähig, die eigens dafür programmierte Routinen verwendeten. Ein Programm, daß im MS-DOS (R) - Fenster abläuft, wird unter Windows 3.x nicht unterbrochen, stürzt es ab, steht das gesamte System. Anders unter Windows NT (R), hier hat das Betriebssystem jederzeit die Möglichkeit, den Prozess zu unterbrechen, abgestürzte Programme bringen nicht mehr das gesamte System zum Absturz (außer einige Grafikanwendungen aus Kanada, stimmts, Elias? :-)). Die Anwendung muß die Kontrolle dem Betriebssystem 'zurückgeben', damit dieses auf andere Prozesse umschalten kann. Dies geschieht durch den Aufruf einer passenden Betriebssystem - Funktion. Bei Windows - Programmen wird diese periodische Rückgabe der Steuerung an das Betriebsystem durch eine sogenannte Meldungs-Schleife realisiert. Programme mit zustandsgesteuertem Ablauf (siehe 1.1) sínd für nonpreemtives Multitasking nur schlecht geeignet, da in bestimmten Zuständen (der genaue zeitpunkt muß oft willkürlich gewählt werden) die Kontrolle an das Betriebssystem zurückggegeben werden muß. |
|
2.3 Programm - Instanzen |
|
Alle Windows - Programme sind mehrfach ausführbar. Wird ein schon aktives Programm ein weiteres Mal gestartet, wird, sofern man dies nicht explizit verhindert, eine weitere Instanz der Applikation geöffnet. Das Proramm läuft dann in zwei unabhängigen Fenstern, eine Instanz weiß von der Existenz der anderen Instanz nichts. Jede Instanz verfügt über ihren eigenen Daten- (Speicher-) bereich, die Ressourcen werden jedoch nur beim Aufruf der ersten Instanz in den Hautspeicher gelden. Greifen daß Programm auf externe Dateien zu, kann es zu Prolemen kommen. |
3. Nachrichten |
|
|
3.1 Nachrichten (Meldungen, Messages) |
|
Windows arbeitet meldungsbasiert, d.h. alle relevanten Ereignisse (z.B.: Maus-Klick, Tastendruck, Ablauf eines Zeit - Intervalls) erzeugen Meldungen, die danach in sogenannten Nachrichten - Schleifen verarbeitet werden. Nachrichten - Charakteristik:
Jede Meldung liefert zusätzliche Informationen (z.B.: WM_KEYDOWN liefert zusätzlich: welche Taste gedrückt? Welche Zusatztasten (Alt, Strg, ) gedrückt?). Diese Informationen werden in zwei Parametern geliefert, die Bedeutung dieser Parameter ist meldungsabhängig.
PUSH - Modell:Übergabe erfolgt bei GetMessage, die Applikation ist aktiv. Die Meldung wird in einer MSG - Struktur übergeben. PULL - Modell:Aufruf einer Fensterfunktion durch Windows, die Applikation ist passiv. Die Meldung wird in Form einzelner Parameter übergeben. |
3.2 Nachrichten-Konzept von Windows |
|
Die Folgende Grafik zeigt den Meldungsfluß zwischen Windows und den Einzelnen Applikationen. |
3.3 WinMain |
|
Die Funktion WinMain entspricht der Funktion main() in einen normalen C-Programm, sie wird von Windows beim Programmstart aufgerufen. Fix vorgegebener Funktions-Kopf: |
int PASCAL WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmd, int nShow); (2) (3) (4) (5) (6) |
|
liefert im Fehlerfall einen Wert ungleich 0 |
Die Funktion WinMain erfüllt eine Reihe von wichtigen Routine-Aufgaben: Registrieren der Hauptfenster-KlasseWird
das Programm zum ersten Mal aufgerufen, wird eine Fensterklasse erzeugt,
dieser Vorgang ist bei weiteen Programminstanzen nicht mehr notwendig. (siehe
2.3 Instanzen) Erzeugen des HauptfenstersIst eine entsprechende Klasse registriert, wird das Hauptfenster erzeugt. Dieser Vorgang ist bei jeder Programm - Instanz notwendig, er legt die restlichen Fenstereigenschaften fest (z.B.: Fensterstil) Anzeigen des HauptfenstersDurch Aufruf der Funktion ShowWindow (die den Parameter nShow übernimmt) und einem anschließendem UpdateWindow wird das Fenster angezeigt. Initialisieren der MeldungsschleifeDie Funktion GetMessage liefert anliegende Nachrichten aus der Meldungsschleife. |
3.4 Die Fensterfunktion |
|
Die Fensterfunktion wird von Windows aufgerufen (PUSH - Modell), sie ist für die Meldungsauswertung zuständig. Fix vorgegebener Funktions-Kopf: |
LONG FAR PASCAL _export WndProc(HWND hWnd, UINT msg, WPARAM wP, LPARAM lP); |
HWND hWnd |
Fenster-Bezug |
Die Fensterfunktion sollte nicht alle Meldungen selbst behandeln, sondern nur einige, wichtige. Andere Meldungsbearbeitungsfunktionen (ein wahres Unwort) können deshalb ausgelagert werden, oder, wenn keine spezielle Behandlung erwünscht ist, an die Default-Fensterfunktion DefWindowProc weitergeleitet werden. Beispiel für ausgelagerte Meldungsbearbeitung: |
void WndProcWMCOMMAND(HWND hWnd, WPARAM wParam) void WndProcWMPAINT(HWND hWnd, WPARAM wParam) LONG WndProcWMCLOSE (HWND hWnd, UINT msg, WPARAM wP, LPARAM lP) LONG FAR PASCAL _export WndProc(HWND hWnd, UINT msg, WPARAM wP, LPARAM lP) return ret; |
|
3.5 Abhandlung bei 'Anwendung beenden' |
|
Anhand des Beispiels 'Anwendung beenden' soll gezeigt werden, wie das Programm auf die Benutzeraufforderung reagiert, sich zu beenden. |
| void WndProcWMCOMMAND(HWND hWnd, WPARAM wParam) LONG WndProcWMCLOSE (HWND hWnd, UINT msg, WPARAM wP, LPARAM lP) LONG FAR PASCAL _export WndProc(HWND hWnd, UINT msg, WPARAM wP, LPARAM lP) return ret; |
Erläuterung:
|
|
3.6 Nachrichten versenden |
|
Jede Windows - Applikation kann Nachrichten an beliebige Fenster verschicken. Man unterscheidet nach dem Verhalten nachdem die Nachricht verschickt wurde, zwei Übermittlungsmethoden: Synchrone Übertragung:
Asynchrone Übertragung:
|
4. Ausgabe (GDI, DC) |
|
|
4.1 GDI - Graphics Device Interface |
|
Das GDI stelt eine Bibliothek von Routinen dar und wird sowohl von Windows selbst als auch von allen Applikationen zur geräteunabhäängigen Grafik- und Textausgabe verwendet. Es bildet die logische Schnittstelle zwischen den Programmen und den Hardware - Treibern der Geräte. Es werden 4 logische Einheiten unterstützt:
Jedes Fenster entspricht einer eigenen Zeichenoberfläche mit eigenenem Koordinatensystem, automatisches Clipping verhinder versehentliches Überschreiben anderer Fenster |
4.2 Einheitenkontext (Device Context) |
|
Der Einheitenkontext oder Device Context (DC) stellt die Verbindung zu einer bestimmten Einheit (Zeichenoberflöche) her. Er sorgt für die Zugriffserlaubnis, bei Hardcopy-Geräten (Drucker, Plotter,) durch 'Spooling', bei Bildschirmen durch 'Clipping'.
|
prinzipieller Ablauf |
nach WM_PAINT |
sonst |
DC anfordern |
BeginPaint |
GetDC |
Ausgaben durchführen |
TextOut |
TextOut |
DC zurückgeeben |
EndPaint |
ReleaseDC |
Andern der Werkzeuge im DC:Beispiel: anderer Stift (Pen)
|
4.3 'bleibende Ausgaben' |
|
Da aufgrund normaler Benutzeraktivitäten das Programmfenster im Anzeigebereich jederzeit überschrieben werden kann (sei es durch andere Programmfenster, den Bildschirmschoner, ), muß das Programm jederzeit in der Lage sein, sein Fenster neu darzustellen. Wird ein Fenster ganz oder zumindest teilweise zerstört, sendet Windows die Meldung WM_PAINT an das entsprechende Programmfenster. Durch das Abfangen der Meldung in der Meldungsbehandlungsfunktion WndProc kann auf WM_PAINT reagiert werden, indem das Fenster neu gezeichnet wird. zu diesem Zweck müssen jedoch alle Informationen bekannt sein, die zum Neuzeichnen des Fensters nötig sind. Beispiel: Anzeigen der aktuellen Mausposition
Richtige Methode für 'bleibende' Anzeige:
InvalidateRectDiese Funktion 'zerstört' die aktuelle Ausgabe, indem es Windows anweist, das Fenster neu zu zeichen. Beispiel für Programm mit bleibener AusgabeErklärung:
|
5. Resourcen |
|
|
5.1 Resourcen |
|
Resourcen sind read-only Dateien, die hauptsächlich für die Gestaltung der Benutzeroberfläche verwendet werden. Diese Daten werden unabhängig vom Programm erstellt und verwaltet und später zum Objektcode des Programms gelinkt. Eine eventuelle Anderung der resourcen (z.B.: hinzufügen eines Menüpunktes, ) kann daher ohne änderung des eigendlichen Quellcodes geschehen, es werden lediglich die Resourcen - Files geändert. Arten von Resourcen:
|
6. Dialoge |
|
|
6.1 Standard-Dialoge |
|
Standard - Dialoge sind seit Windows 3.1 verfügbar und erleichtern Routineaufgaben wie zum Beispiel das Öffnen von Dateien. Weiters tragen sie zur Verbesserung der Bedienbarkeit von Windows - Programmen bei, da wichtige, oft genutzte Dialoge ein einheitliches Erscheinungsbild haben und somit intuitiv bedienbar sind. |
Standard - Dialoge:
|
|
Natürlich kann mit Hilfe eines Dialog - Editors auch ein benutzerdefinierter Dialog erstellt werden. Dieser kann mit einer Vielfalt von Kontrollelementen bestückt werden, die wichtigsten davon sind:
|
|
6.2 Modaler Dialog |
|
Ein modaler Dialog muß vor dem Weiterarbeiten mit der Applikation geschlossen werden. Das Elternfenster wird vollkommen daktiviert, die Steuerung wird an die Funktion DialogBox übergeben, die eine eigene Meldungsschleife enthält. Die Rückkehr zum Elternfenster erfolgt mit dem Aufruf der Funktion EndDialog Applikationsmodaler DialogDie Applikation, die den Dialog aufgerufen hat, wird deaktiviert, das Wechseln zu anderen Applikationen ist ohne weiters möglich. Systemmodaler DialogDas gesamte System (Windows) ist lahmgelegt, lediglich die Dialogbox bleibt bedienbar. (Verwendug bei Systemfehlern, z.B.: Allgemeine Schutzverletzung) |
|
6.3 Nichtmodaler Dialog |
|
Beim nichtmodalen Dialog kann der User zwischen Dialog und em Rest der Applikation wechseln. Ein nicht-modaler Dialog wird in C mittels der Funktion CreateDialog erstellt, die Kontrolle bleibt jedoch beim Hauptfenster. Da es keine eigene Meldungsschleife gibt, muß die Meldungsschleife in WinMain modifiziert werden. |
Haupt | Fügen Sie Referat | Kontakt | Impressum | Nutzungsbedingungen