Visual Basic

Inhaltsverzeichnis:

Einleitung
Windows ist das Zauberwort der neunziger Jahre. Visual Basic ist der Schl├╝ssel zu Windows, denn Visual Basic erm├Âglicht das Erstellen von richtigen Programmen ohne spezielle Vorkenntnisse. Kann man Basic, so beherrscht man Windows. Auf diese Kurzformel l├Ąsst sich das Geheimnis von Visual Basic bringen. Visual Basic ist die erste speziell f├╝r die Windows - Programmierung konzipierte Programmier - bzw. Hochsprache. Visual Basic ist in mehreren Beziehungen revolution├Ąr. Fr├╝her musste man nicht nur gute Kenntnisse in C und Windows selbst haben, reichen heute Grundkenntnisse in Basic, um in k├╝rzester Zeit funktionsf├Ąhige Windows - Programme herzustellen. Visual Basic kombiniert die Einfachheit der Programmiersprache mit einem sehr leistungsf├Ąhigen und komfortablen Entwicklungssystem. Visual Basic ist sehr erweiterbar. ├ťber den Aufruf von sogenannten Bibliotheksfunktionen (siehe Kapitel: API - Routinen) bzw. ├╝ber Steuerelemente k├Ânnen die M├Âglichkeiten der Sprache sehr erweitert werden.

Visual Basic erlaubt das Erstellen von komplexen Benutzeroberfl├Ąchen in k├╝rzester Zeit. Visual Basic Programme unterscheiden sich ├Ąu├čerlich nicht von kommerziellen Programmen. Visual Basic ist allerdings nicht die universelle Programmiersprache f├╝r Windows. Es ist vielmehr eine Sprache, die viele Vorteile, aber auch einige M├Ąngel aufweist. Der wohl wichtigste Vorteil von Visual Basic ist, dass grundlegende Basic - Kenntnisse ausreichen, um voll funktionsf├Ąhige Programme entwickeln zu k├Ânnen.

Auch das zur Zeit recht popul├Ąre Schlagwort "objektorientiert" wir des ├Âfteren in Verbindung mit Visual Basic gebracht. Visual Basic behandelt jedes Kontrollelement in einem Applikationsfenster als ein Objekt, das eine bestimmte Anzahl von Eigenschaften besitzt. Dazu geh├Âren die Eigenschaften, die das Aussehen bestimmten genauso wie die M├Âglichkeiten, auf verschiedene Situationen (Mausklick, Tastendruck, ...) reagieren zu k├Ânnen.

Manch einer kann dem Ganzen nicht so recht trauen. Die Einfachheit, die Effizienz usw. Allerdings legt Visual Basic dem Programmierer etliche Beschr├Ąnkungen auf. Als Beispiel m├Âchte ich hier gro├če Datenmengen nehmen. Visual Basic richtet sich aber nicht nach der professionellen Programmierung (sie ist zwar mit etwas Beihilfe von C/C++ o.├Ą. m├Âglich), sondern eher nach einfacheren Programmen, in denen weder sehr komplexe Datenstrukturen vorkommen, noch die Ausf├╝hrungsgeschwindigkeit ein Problem darstellt).

Visual Basic kann durchaus mit "Hypercard" (Apple Macintosh) oder mit dem "Interface - Builder" (NeXT - Computer) verglichen werden. So wie diese Programme das Programmierkonzept von den genannten Rechnern ver├Ąndert haben, wird auch Visual Basic die Programmierart ver├Ąndern: Einfach und trotzdem leistungsf├Ąhig. Man wird nie C/C++ innerhalb von Visual Basic ├╝berbieten k├Ânnen, da dieses mehr auf Systemebene arbeitet. Trotzdem ist Visual Basic gerade f├╝r den Gelegenheits - Programmierer wie z.B.: mich ideal, da es doch viele M├Âglichkeiten besitzt und (im Verglich zu "st├Ąrkeren" Programmiersprachen wesentlich billiger ist. Dies sind wohl auch die M├Âglichkeiten, warum Visual Basic zum Thema meiner Fachbereichsarbeit geworden ist.

Unterteilung:
Im ersten Teil befindet sich der theoretische Teil, der die Voraussetzungen zur API Programmierung darstellt.
Der zweite Teil ist ein Programm zur API - Programmierung.
Im Anhang befindet sich ein Glossar

Auf der beiliegenden CD befindet sich sowohl das Programm als auch die gesamte Fachbereichsarbeit inkl. aller Bilder und Vorgaben

Bedanken m├Âchte ich mich noch bei Herr Prof. Walter Rigger f├╝r die Betreuung meiner Fachbereichsarbeit.
Grundlegendes
Was hei├čt Programmieren:
Programmieren bedeutet, dem Computer Anweisungen zu geben, die dieser auszuf├╝hren hat. Da es sich bei einem Computer, genauer gesagt bei einem Prozessor, der die eigentliche Programmausf├╝hrung ├╝bernimmt, um einen elektronischen Baustein handelt, gilt es ein grunds├Ątzliches Kommunikationsproblem zu ├╝berwinden. Dieses Kommunikationsproblem besteht darin, dass der Prozessor nur Befehle und Daten in bin├Ąrer Form, das hei├čt in Form von Dualzahlen versteht. Ein typische Befehl an den Prozessor k├Ânnte daher folgendes Aussehen haben:
1 0 1 1 0 1 0 1 1 1 0 0 1 0 1 0
Da dieser Befehl direkt vom Prozessor ausgef├╝hrt werden kann, wird er als Maschinenbefehl bezeichnet. Alle Maschinenbefehle eines Prozessors werden unter dem Begriff Befehlssatz zusammengefa├čt. Die Gesamtheit aller Befehle hei├čt: Maschinensprache. Eine einzelne Ziffer einer Dualzahl wird ├╝brigens als Bit bezeichnet. Ein Bit kann nur zwei Zust├Ąnde annehmen (0 ↔ 1, falsch ↔ wahr, aus ↔ ein) und ist damit die denkbar kleinste Informationseinheit. Die Tatsache, dass jede der beiden abgebildeten Dualzahlen genau 8 Bits umfa├čt, ist kein Zufall, denn in der Informationsverarbeitung werden 8 Bits aus praktischen Erw├Ągungen zu einem Byte zusammengefa├čt. Auch ein Byte ist eine sehr kleine Einheit, man findet daher in der Praxis die Einheiten Kbyte (1 Kbyte = 1024 Bytes), Mbyte (1Mbyte = 1024 * 1024 Byte = 1024 Kbyte) oder auch Gbyte (1 Gbyte = 1024 * 1024 * 1024 Byte = 1024 Mbyte).

Verst├Ąndlicherweise ist die Eingabe von Befehlen und Daten in Form von Dualzahlen sehr umst├Ąndlich. Schon sehr bald nach Einf├╝hrung der ersten Rechenmaschine in den Vierziger Jahren, musste ein Kompromi├č gefunden werden. Dieser Kompromi├č hei├čt Programmiersprache. Obwohl die erste Programmiersprache, es war FORTRAN, bereits Anfang der F├╝nfziger Jahre entwickelt wurde, hat sich an diesem Prinzip grunds├Ątzlich nichts ge├Ąndert. Inzwischen gibt es f├╝r den PC mehrere Dutzend Programmiersprachen. Sie werden auch als Hochsprachen bezeichnet, um sie von der Maschinensprache abzugrenzen. Alle Hochsprachen haben eines gemeinsam: sie ├╝bersetzen die Befehle eines Programms in die "Muttersprache" des Prozessors, die Maschinensprache. Auch f├╝r die Windows - Programmierung hat dieser Ablauf G├╝ltigkeit. Allerdings sind Windows - Programme teilweise so komplex, dass der Zusammenhang zwischen den Befehlen der Programmiersprache und den ├╝bersetzten Maschinenbefehlen in der Praxis keine Bedeutung hat. Die meisten Windows - Programme werden in der Sprache C erstellt. Doch auch in Visual Basic lassen sich sehr leistungsf├Ąhige Programme entwickeln.
Was ist Visual Basic:
Visual Basic ist eine einfach zu erlernende Programmiersprache, die es dem Anwender bzw. dem Programmierer erm├Âglicht, eigene Programme f├╝r Microsoft Windows™ zu erstellen. Visual Basic benutzt hierzu eine grafische Oberfl├Ąche, die aus verschiedenen Teilbereichen zusammengesetzt ist. Mehr dazu sp├Ąter. Sie wurde von Microsoft entwickelt und mittlerweile gibt es schon die Versionsnummer 5.0. In meinen Beispielen arbeite ich mit Version 4.0, da Version 5.0 noch sehr neu ist und noch ein paar M├Ąngel aufweist. Au├čerdem ist es g├╝nstig, die Version 4.0 zu verwenden, da es von dieser Version sowohl eine 16bit (Windows 3.x) als auch eine 32bit (Windows ┬┤95/NT) Version gibt. Da Visual Basic einfach zu erlernen ist, hat es auch seine Grenzen, die allerdings f├╝r den normalen Programmierer, wie zum Beispiel f├╝r mich in weiter Ferne liegen. Die Befehle von Visual Basic sind nicht Case - Sensitive, d.h. es ist egal, ob bestimmte Befehle gro├č oder klein geschrieben werden. Au├čerdem werden Befehle, die Visual Basic erkennt, immer mit blau geschrieben, um eine bessere ├ťbersicht zu gewinnen. Ein weiterer Vorteil von Visual Basic ist, dass es den Zugriff auf die API’s erlaubt. Diese werden weiter hinten noch erl├Ąutert. Ein weiterer Nachteil von Visual Basic ist, dass die kompilierte (fertige) Anwendung im Gegensatz zu komplexeren Programmiersprachen wie z.B.: C/C++ oder Delphi (siehe Vergleiche) relativ langsam ist. Da sich dies allerdings erst bei komplexeren Programmen bemerkbar macht und da bisher erst wenige meiner Programme ├╝ber die Gr├Â├če eines Megabytes gingen, ist dieser Aspekt f├╝r mich uninteressant.

Ein Grund daf├╝r, warum Visual Basic so bekannt geworden ist, liegt sicher im Preis. Im Gegensatz zu Visual Basic kosten "richtige" Programmiersprache wie z.B.: C/C++ oder Java ein Vielfaches von Visual Basic. Vielleicht ist Visual Basic nicht gerade die komplexeste Programmiersprache, daf├╝r ist sie aber ebenso einfach zu erlernen.

Diese FBA soll einen kleinen ├ťberblick ├╝ber die M├Âglichkeiten von Visual Basic geben und zeigen, was mit einfachsten Mitteln alles m├Âglich ist.
Innerhalb von Fenstern[1]
Zu Beginn muss gesagt werden, dass sich Visual Basic und Windows sehr gleichen. Visual Basic bietet ein sehr einfach zu benutzendes Interface (eine einfach zu benutzende Oberfl├Ąche). Ein Fenster hat eine gro├če Menge an Eigenschaften, die ├╝ber das Eigenschaftsfenster einfach ver├Ąndert werden k├Ânnen. Das API - Interface ist um einiges komplexer.
Was ist ein Fenster:
Fenster k├Ânnen sowohl Formen, einzelne graphische Teile der Windows - Oberfl├Ąche, Bildlaufleisten als auch Icons sein. Sogar der Windows - Hintergrund ist ein Fenster.
Wann ist ein Fenster kein Fenster
Mit der Version 2.0 von Visual Basic kamen neue Arten von Steuerelementen, die Graphische Steuerelemente genannt wurden. Diese haben etwas gemeinsam: Sie sind keine Fenster, obwohl sie vielleicht so aussehen oder sich so verhalten. Ein graphisches Steuerelement ist ein innerhalb von Visual Basic definiertes Element. Graphische Steuerelemente unterst├╝tzen nicht viele der M├Âglichkeiten eines Fensters. Als Beispiel m├Âchte ich das Label - Steuerelement (ein einzelnes Feld, in dem Text angezeigt werden kann) auff├╝hren. Es beschreibt nur einen einfachen Textblock und, wie viele andere dieser Steuerelemente auch, kann es zum Beispiel den Fokus nicht erhalten (d.h. es kann nicht aktiviert werden, es hat immer den gleichen Status; besitzt ein Textfeld den Fokus, so k├Ânnen in dieses Daten eingegeben werden) und somit auch keine Tastatureingabe erkennen und auswerten (im Gegensatz zum Text - Control). Der eigentliche Schwachpunkt aber ist, dass sie keinen Window - Handle (eine Zahl, die ein Fenster eindeutig identifiziert) besitzen. Sie k├Ânnen daher auch nicht von API - Funktionen angesprochen werden, die einen solchen Handle ben├Âtigen.
System - Objekte:
Die Systemobjekte in Visual Basic (Zwischenablage - , Screen - , und Drucker - Objekte) haben ebenfalls keine Ansprechm├Âglichkeit betrachtet man sie von der Fenster - Seite (sie sind ebenfalls keine Fenster). Diese Systemressourcen werden direkt von Windows - APIs angesprochen.



Programmerstellung mit Visual Basic
Interpreter und Compiler:
Jeder Computer bzw. Prozessor besitzt einen Sprach - bzw. Befehlsvorrat, der ihn bef├Ąhigt bestimmte Aufgaben wie etwa die Addition zweier Zahlen auszuf├╝hren. Um die Befehle der Hochsprache (ab hier wird sie nur noch Programmiersprache) genannt in Befehle des Prozessors zu verwandeln, bedarf es eines Dolmetschers, der die Befehle "├╝bersetzt". Der ├ťbersetzungsvorgang kann vor der eigentlichen Programmausf├╝hrung geschehen und wird in der Informatik als kompilieren (engl. To compile) bezeichnet. Das Programm, das diese Arbeit erledigt, hei├čt Compiler. Im Gegensatz dazu kann das Programm nat├╝rlich auch erst w├Ąhrend der Programmlaufzeit in die dem Computer verst├Ąndliche Sprache ├╝bersetzt werden. In diesem Fall spricht man von einem Interpreter. W├Ąhrend Sprachen wie PASCAL oder auch C reine Compiler - Sprachen darstellen, also vor dem eigentlichem Programmstart erst einmal kompiliert werden m├╝ssen, ist Visual Basic eine Interpreter - Sprache, d.h. das Programm wird - ├Ąhnlich einem Simultan - Dolmetscher im Fernsehen - St├╝ck f├╝r St├╝ck unmittelbar zur Laufzeit ├╝bersetzt. Dieses Verfahren erspart zwar dem Programmierer die Wartezeit, bis sein Quell - Code (Programm) in die Maschinensprache des Computers umgesetzt wurde, hat daf├╝r aber einen gewaltigen Nachteil: das Umsetzen des Programms in Maschinensprache beansprucht Rechnerleistung und somit Zeit, die zur Verlangsamung der Programmausf├╝hrung f├╝hrt (oft bis zu einem Faktor 10). Aus diesen Gr├╝nden hat Microsoft seinem Sch├╝tzling Visual Basic auch einen Compiler mit auf den Weg gegeben, der daf├╝r sorgt, dass die mit dieser Sprache erstellten Windows - Applikationen auch mit maximaler Geschwindigkeit ausgef├╝hrt werden k├Ânnen. Der Compiler setzt dabei alle innerhalb der Projektverwaltung aufgelisteten Formulare und Module zu einem direkt ausf├╝hrbaren Programm um. Nur die Dateiendung wird von *.vbp in *.exe umbenannt, die ja bekanntlich ein direkt ausf├╝hrbares Programm kennzeichnet. Von nun an kann das Programm direkt von der Windows - Oberfl├Ąche heraus gestartet werden. Visual Basic selbst (hier in Funktion des Interpreter - Programmes) wird nicht mehr zur Programmausf├╝hrung ben├Âtigt. Lediglich eine Datei namens VB40016.DLL f├╝r 16 - bit Programme bzw. VB40032.DLL f├╝r 32 - bit Programme, die man ├╝brigens - ohne dass Lizenzgeb├╝hren anfallen - mit eigenen Programmen weitergeben darf, muss w├Ąhrend der Programmausf├╝hrung vorhanden sein.

Diese Datei, eine dynamische Link - Library (.DLL), enth├Ąlt wichtige Programmfunktionen, die zwar zur Programmlaufzeit ben├Âtigt werden, jedoch nicht direkt in die ausf├╝hrbare EXE - Datei aufgenommen wurden. Der Vorteil einer solchen DLL besteht darin, dass mehrere (mit Visual Basic kompilierten) Programme auf eine DLL zur├╝ckgreifen k├Ânnen. Sie muss also nur einmal auf der Festplatte (im Speicher des Computers) vorhanden sein. W├╝rde man die in der DLL enthaltenen Funktionen in jede mit Visual Basic erstellte Applikation direkt aufnehmen, w├╝rden sich deren Umf├Ąnge erheblich vergr├Â├čern.
DDE und OLE[2]
Der Dynamische Datenaustausch:
Man versteht unter dynamischem Datenaustausch das Kommunizieren zweier Windows - Anwendungen, die gegenseitig Windows - Daten austauschen. Diese M├Âglichkeit wird ebenfalls von Visual Basic - Anwendungen unterst├╝tzt.

Es gibt zwei M├Âglichkeiten, den dynamischen Datenaustausch zu realisieren: Eine starre Verbindung, die w├Ąhrend der Entwicklungszeit hergestellt wird und eine flexible, die erst w├Ąhrend der Laufzeit entsteht. Auch ├╝ber die Zwischenablage lassen sich Daten zwischen einzelnen Anwendungen austauschen, jedoch nicht in dem Umfang und der Flexibilit├Ąt, wie dies mit dem dynamischen Datenaustausch m├Âglich ist.
Wieso ben├Âtigt man den dynamischen Datenaustausch:
Zu Beginn muss gesagt werden, dass auch die M├Âglichkeiten des dynamischen Datenaustausches begrenzt sind. Allerdings k├Ânnte man ohne ihn auch keine Bilder in Schriftdokumente einbinden, keine Daten in einer Excel - Tabelle darstellen und keine T├Âne in verschiedene Dokumente einbauen. Der dynamische Datenaustausch stellt eine Art Verbindung zwischen den einzelnen DDE - unterst├╝tzenden Programmen dar. Jeder hat wohl schon einmal ein Bild in ein Textdokument eingebaut und hat dadurch seine Arbeit "versch├Ânert". Genau diese Verbindung zwischen dem Programm, das das Bild erzeugt hat und dem Programm, mit dem das Textdokument verwaltet wird ist das Ergebnis eines Datenaustausches.
Begriffserl├Ąuterungen:
Client und Server: Das Anwendungsprogramm, welches die Kommunikation beginnt und Daten anfordert, hei├čt Server. In Visual Basic umgesetzt, bedeutet dies, dass Textfelder, Bilder und Bezeichnungsfelder als Client dienen, w├Ąhrend Formen (also Fenster) die Aufgabe des Servers ├╝bernehmen.
Name des Anwendungsprogramms: Jede Anwendung, die als Server dienen soll, ben├Âtigt einen speziellen DDE - Namen - mit diesem wird die Anwendung angesprochen - der aber meist der eigentlichen Anwendungsbezeichnung sehr ├Ąhnlich ist (Word f├╝r Windows: WinWord, Excel: Excel).
In Visual Basic ist der DDE - Name der Name, der ausf├╝hrbaren EXE - Datei, falls bereits eine erstellt wurde, ansonsten der Hauptname der Projektdatei.
Aktive und passive Verbindung: Eine aktive Verbindung besteht dann, wenn Client und Server in st├Ąndiger Verbindung stehen, d.h. die Daten werden st├Ąndig aktualisiert. Im Gegensatz dazu tauscht eine passive Verbindung Daten nur dann aus, wenn der Client diese anfordert.
Hierzu ein Beispiel:
Passive Verbindung: Microsoft WinWord fordert ein Bild von Microsoft Paint an, d.h. die beiden Anwendungen werden verkn├╝pft. Dieses Bild wird nun ein einziges Mal an WinWord ├╝bergeben. ├ändert sich das Bild in Paint, so hat dies keinen Einflu├č auf WinWord und umgekehrt. Die Verbindung wird hiermit gel├Âscht.
Aktive Verbindung: Auch hier ├╝bergibt Paint WinWord ein Bild. Wird dieses nun allerdings in Paint ver├Ąndert, so erh├Ąlt auch WinWord das ver├Ąnderte Bild, d.h. ein neues Bild wird im Dokument dargestellt. Allerdings funktioniert dieser Vorgang nur bei wenigen Programmen, da viele nur ein passive Verbindung zulassen.
Object Linking (Objekt einbinden): Das Objekt einer anderen Anwendung wird in der Rahmenanwendung nur eingebunden, d.h. angezeigt. Eine Bearbeitung ist hier nicht m├Âglich.
Object Embedding (Objekt verkn├╝pfen): Eine Objekt - Verkn├╝pfung geht ├╝ber die Einbindung hinaus. Das Objekt wird hier nicht nur angezeigt, sondern es kann auch bearbeitet werden. Dazu wird das OLE - Programm (Server) aufgerufen.
OLE - Programm: Eine OLE - Programm ist dasjenige Programm, welches die Daten liefert (Server). Beispielsweise liefert Word f├╝r Windows ein Textdokument oder Excel eine Kalkulationstabelle als Daten bzw. Objekt, die dann von der Rahmenanwendung (Client) ├╝bernommen werden.
Rahmenanwendung: Eine Rahmenanwendung ist das Programm, welches Objekte von einem OLE - Programm (Server) ├╝bernimmt, damit diese angezeigt oder bearbeitet werden k├Ânnen.
OLE - Objekt: OLE - Objekte sind die Daten, die in die Rahmenanwendung zur Anzeige bzw. Bearbeitung ├╝bergeben werden.
OLE - Server / OLE - Client: Ein OLE - Server ist die Anwendung, die Daten bzw. Objekte zur Verf├╝gung stellt, welche im OLE - Client eingebettet bzw. mit ihm verkn├╝pft werden. Wird z.B.: in einer Visual Basic - Anwendung eine Excel Tabelle eingebunden bzw. bearbeitet, so ist Excel der OLE - Server und Visual Basic der OLE - Client.
Klasse: Die Klasse eines Objekts legt die Anwendung fest, welche das Objekt erzeugt. Klassen sind z.B.: MsGraph, MsDraw, Word - Dokument oder Excel - Worksheet. Die Klasse ist die formale Definition eines Objekts. Sie ist die Vorlage, nach der zur Laufzeit eine Instanz eines Objekts erzeugt wird. Die Klasse definiert die Eigenschaften des Objekts und die Methoden, die zur Steuerung des Objektverhaltens verwendet werden.
Klassenmodul: Das Klassenmodul ist ein Modul, das die Definition einer Klasse (ihre Eigenschaften - und Methoden - Definitionen) enth├Ąlt.
Klassenbibliothek: Die Klassenbibliothek ist eine Datei oder ein Teil einer Datei die Standardbeschreibungen von offengelegten Objekten, Eigenschaften und Methoden im Rahmen der OLE - Automatisierung enth├Ąlt. Objektbibliotheksdateien (.OLB) enthalten Klassenbibliotheken.
Objekt: Objekt ist ein allgemeiner Begriff f├╝r Formen und Steuerelemente. Aber auch die Zwischenablage (Clipboard), der Drucker (Printer), der Bildschirm (Screen) sowie die Fehlersucheinrichtung (Debug) z├Ąhlen zu den Objekten von Visual Basic. Jedem Objekt werden zur Entwicklungs - oder zur Laufzeit bestimmte Eigenschaften (Properties) zugewiesen, die z.B.: die Abmessungen oder die Farben des Objekts festlegen.
Objektbibliothek: Die Objektbibliothek ist eine Datei mit der Erweiterung .OLB, die Informationen zu OLE - Automatisierungs - Controllern (wie Visual Basic) ├╝ber verf├╝gbare OLE - Automatisierungsobjekte bereitstellt. Der Objektkatalog ist ein Dialogfeld und kann verwendet werden, um den Inhalt einer Objektbibliothek zu untersuchen und Informationen zu den verf├╝gbaren Objekten zu erhalten.

Der dynamische Datenaustausch zur Entwicklungszeit:
Die erste M├Âglichkeit einen dynamischen Datenaustausch herzustellen, ist die nachstehend beschriebene starre Methode. Hierbei wird bereits w├Ąhrend der Entwicklungszeit eines Visual Basic - Projektes eine aktive Verbindung zum anderen Anwenderprogramm hergestellt, die sp├Ąter w├Ąhrend der Ausf├╝hrung in der gleichen Weise wiederaufgenommen wird. Da diese Art der Kommunikation ausschlie├člich ├╝ber Visual Basic - Men├╝befehle abgewickelt wird, ist die zwar einfach zu handhaben aber wenig flexibel und ben├Âtigt auch keinen Programmcode. Die Verbindung kann au├čerdem nur bei Programmbeendigung abgebrochen werden. Dar├╝ber hinaus ist diese Methode auch nur f├╝r solche Anwenderprogramme geeignet, die ├╝ber ein Men├╝ Bearbeiten/Verkn├╝pfen und Einf├╝gen (oder ├Ąhnliches) verf├╝gen.
Der dynamische Datenaustausch zur Laufzeit:
Nachfolgend ist die zweite flexible Methode beschrieben, einen dynamischen Datenaustausch herzustellen. Diese ist wesentlich flexibler als die oben beschriebene und eignet sich auch f├╝r Anwendungen, die nicht ├╝ber den vorher genannten Men├╝punkt verf├╝gen. Der Datenaustausch wird hier w├Ąhrend der Programmausf├╝hrung ├╝ber Visual Basic - Eigenschaften, - Ereignisse und - Methoden gesteuert, f├╝r die der Anwender wiederum Code schreiben kann.
Handles[3]
Fenster, Ger├Ąte, Programminstanzen, Bitmaps und Mauszeiger stellen wohl die wichtigsten Objekte in einer Windows - Umgebung dar. Sie k├Ânnen auf verschiedene Arten angesprochen werden. Das bedeutet auch, dass es einen Weg geben muss, diese identifizieren zu k├Ânnen, um sie dann als Parameter an Funktionen weitergeben zu k├Ânnen. Windows identifiziert jedes dieser Objekte mit einer 32bit langen geraden Zahl (Integer), die auch als Handle bekannt ist. Jedes Handle hat als Typenidentifzierer (Identifier) ein kleines h am Anfang. Als Beispiel m├Âchte ich einen einfachen Fall aufzeigen, die API - Funktion SetFocus.

An die SetFocus - Funktion wird ein Parameter ├╝bergeben, der das Fenster eindeutig identifiziert. Diese Funktion lautet vollst├Ąndig also SetFocus(hWnd).

Menu
hMenu
Men├╝leiste oder Pop - Up Men├╝
Module
hModule
Zeigt auf ein Codemodul wie z.B. eine DLL oder ein Anwendungsmodul
Palette
hPalette
Farbtabelle
Region
hRgn
Ein Gebiet eines Fensters
Windows
HWnd
Ein Fenster

Neben diesen gibt es auch noch weitere, die allerdings weniger h├Ąufig gebraucht werden. Objekte, die von der Windows API benutzt werden, sollten nicht mit Visual Basic Objekten vermischt werden, da diese mit dem Visual Basic Befehl GetObject herausgefunden werden. Diese Objekte werden von OLE (Object Linking and Embedding) oder Visual Basic selbst ver├Ąndert und sind nicht im Kern der Windows - API vorhanden.
Die Windows - API - Routinen[4]
Was bedeutet API:
API bedeutet Advanced Programmer’s Interface (engl.: die Oberfl├Ąche des fortgeschrittenen Programmierers), also eine erweiterte Programmierschnittstelle zu anderen Anwendungen bzw. Dateien.
Wozu ben├Âtigt man API - Funktionen:
API - Funktionen stellen einen wichtigen Bereich in der (Visual - Basic) Programmierung dar. Sie sind sozusagen die Schnittstelle zu wichtigen System - Funktionen. Mit ihrer Hilfe k├Ânnen die M├Âglichkeiten von Visual Basic erheblich gesteigert werden. Visual Basic zielt haupts├Ąchlich darauf ab, die Systemstabilit├Ąt zu gew├Ąhrleisten. Dazu muss allerdings auch die Zahl der verf├╝gbaren Funktionen erheblich eingeschr├Ąnkt werden. Allerdings sind ein Gro├čteil der wichtigen Funktionen nun ├╝ber die API - Schnittstelle bzw. die API - Funktionen erreichbar. Man kann demzufolge sagen, dass die API - Routinen eine Schnittstelle zwischen den wirklich abgesicherten Visual Basic Funktionen und den absturzgef├Ąhrdeten Windows - Routinen sind. Diese API - Routinen k├Ânnen von Visual Basic zwar nicht direkt angesprochen werden - sie m├╝ssen zuvor deklariert werden - sind sp├Ąter aber voll funktionsf├Ąhig. Der einzige Nachteil dieser Funktionen gegen├╝ber den Visual Basic - Funktionen ist der, dass alle Sicherheitsmechanismen bei dem Aufruf einer API von Visual Basic au├čer Kraft gesetzt sind, da diese bekanntlich nicht zu Visual Basic sondern zu Windows selbst geh├Âren.
Allgemeine Informationen:
Eine besondere Variante, die Leistungsf├Ąhigkeit von Visual Basic erheblich zu steigern, liegt im Einsatz von dynamischen Verbindungsbibliotheken, den sogenannten DLLs (Dynamic Link Library).
Auch die Windows API Funktionen sind in diesen Dateien enthalten. Visual Basic selbst kann keine DLLs mit exportierten Funktionen erzeugen. H├Âhere Programmiersprachen wie z.B.: Delphi oder C/C++ k├Ânnen Funktionen aus DLLs direkt exportieren.
Sicherheitsaspekte beim Gebrauch von API - Routinen:
Die Sicherheits - und ├ťberpr├╝fungsm├Âglichkeiten von Visual Basic sind beim Aufruf von DLL - Routinen au├čer Kraft gesetzt. Deshalb ist es notwendig, dass vor jedem Aufruf eines DLL beinhaltenden Programmes die Quelldatei gespeichert wird, um etwaigem Datenverlust vorzubeugen.
Die Deklaration von DLL - Routinen:[5]
An dieser Stelle soll zuerst die Schnittstelle von Visual Basic erkl├Ąrt werden, die den Zugriff auf DLL - Routinen erm├Âglicht. Jede DLL - Routine muss vor Ihrem Einsatz zun├Ąchst deklariert werden. Neben dem Prozedurnamen muss sowohl die dynamische Verbindungsbibliothek (DLL) als auch die Parameterliste genannt werden. Mit der Anweisung Declare kennzeichnen Sie eine Prozedur als extern (au├čenst├Ąndig, nicht direkt in Visual Basic implementiert). Der DLL - Name muss angegeben werden, da die DLL dynamisch zur Laufzeit an ein Programm gebunden ist (sie wird erst w├Ąhrend der Ausf├╝hrung des Programms ben├Âtigt, nicht gleich beim Aufruf). Die DLL muss sich entweder im Programm - oder Windows - Systemverzeichnis befinden. Ist dies nicht der Fall, muss explizit der Suchpfad mit angegeben werden. Es sollten jeweils nur Deklarationen in ein Programm aufgenommen werden, die unbedingt ben├Âtigt werden.

Die allgemeine Syntax lautet:

DECLARE FUNCTION LIB "BIBLIOTHEK.DLL" [ALIAS "ORIGINALNAME"] ([[BYVAL|BYREF] VARIABLENNAME [AS VARIABLENTYP] [,[BYVAL|BYREF] VARIABLENNAME ...][....]])
BZW.
DECLARE SUB LIB "BIBLIOTHEK.DLL" [ALIAS "ORIGINALNAME"] ([[BYVAL|BYREF] VARIABLENNAME [AS VARIABLENTYP] [,[BYVAL|BYREF] VARIABLENNAME ...][....]])

Der Abschnitt Lib LibName in der Declare - Anweisung teilt Visual Basic mit, wo die Dynamic - Link Library gespeichert ist. Betriebssystem - DLLs sind entweder "User", "GDI" oder "Kernel" oder eine der anderen System - DLLs wie "MMSystem". Bei anderen DLLs ist LibName ein Dateiname, der auch eine Pfadangabe enthalten kann.

Mit der Alias - Klausel kann eine Prozedur deklariert und damit einhergehend umbenannt werden. Diese Umbenennung ist dann sinnvoll, wenn ein Name einer DLL - Prozedur in Visual Basic nicht g├╝ltig ist oder aber bereits definiert ist. Wird eine Routine innerhalb DLL lediglich unter einer Ordnungszahl verwaltet, muss die Prozedur wie unten beschrieben deklariert werden.

DECLARE PROZEDURNAME LIB "BIBLIOTHEK.DLL" ALIAS "#ZAHL" .......

Die Ordnungsnummer wird im Zeichenkettenformat angegeben und mit einem Doppelkreuz eingeleitet. Die Parameterliste ist optional, lediglich die runden Klammern sind in jedem Fall mit anzuf├╝hren. Die Parameterliste kann einen oder mehrere Parameter enthalten. Jeder Parameter muss mit einem Datentyp versehen werden. Folgende Besonderheiten sind bei der ├ťbergabe von Werten an DLL - Routinen zu ber├╝cksichtigen.
Wert oder Referenz├╝bergabe von Argumenten:
Standardm├Ą├čig ├╝bergibt Visual Basic alle Argumente als Referenz. d.h. Visual Basic ├╝bergibt die 32 - Bit - Adresse, an der der Wert gespeichert ist, und nicht den eigentlichen Wert des Arguments. Das Schl├╝sselwort ByRef muss zwar nicht angegeben werden, man kann es aber zur Dokumentation im Code verwenden, damit offensichtlich ist, wie Daten ├╝bergeben werden.

Viele DLL - Prozeduren erwarten, dass ein Argument als Wert ├╝bergeben wird, d.h. sie erwarten den eigentlichen Wert und nicht die Speicheradresse des Wertes. Wenn ein Argument als Referenz an eine Prozedur ├╝bergeben wird, die eine ├ťbergabe des Wertes erwartet, erh├Ąlt die Prozedur falsche Daten und kann nicht korrekt ausgef├╝hrt werden.

Ein Argument kann als Wert ├╝bergeben werden, indem vor der Argumentdeklaration in der Declare - Anweisung das Schl├╝sselwort ByVal eingef├╝gt wird. Dies gew├Ąhrleistet, dass das Argument bei jedem Prozeduraufruf als Wert ├╝bergeben wird.
Konvertieren von C - Deklarationen nach Visual Basic:
Die Prozeduren in DLLs werden meistens in der Syntax der Programmiersprache C dokumentiert. Um sie von Visual Basic aus aufzurufen, m├╝ssen sie in g├╝ltige Declare - Anweisungen ├╝bersetzt und ordnungsgem├Ą├č aufgerufen werden. Die folgende Tabelle enth├Ąlt eine Liste der wichtigsten C - Deklarationen und der jeweiligen Entsprechung in Visual Basic.
Zeichenketten├╝bergabe:
Zeichenketten, die an DLL - Routinen ├╝bergeben werden, enden im Regelfall mit Chr$(0) (ASCII - String). Das Nullzeichen wird automatisch an eine Zeichenkette, die an eine DLL Routine ├╝bergeben wird, angeh├Ąngt, wenn sie innerhalb der Parameterliste mit dem Schl├╝ssel ByVal deklariert ist. Zeichenketten werden an DLL - Routinen immer als Referenz ├╝bergeben. DLL - Routinen liefern in der Regel nur Zeichenketten mit maximal 255 Zeichen zur├╝ck. Die L├Ąnge einer Zeichenkette kann in der DLL nicht ge├Ąndert werden, sofern die Routine nicht speziell f├╝r Visual Basic geschrieben wurde. Eine Zeichenkette, die ein Ergebnis zur├╝ckliefert, muss daher in der Regel zun├Ąchst auf 255 Zeichen initialisiert werden. Dies kann mit dem Befehl Variable1$ = Space$(255). Funktionen, die in einem Parameter eine Zeichenkette mit dem Wert Null erwarten, k├Ânnen die Visual Basic Konstante VbNullString erhalten. Zeichenketten fester L├Ąnge k├Ânnen an DLL - Funktionen nicht ├╝bergeben werden. Gibt eine DLL - Funktion eine Zeichenkette zur├╝ck, so ist diese ebenfalls mit Chr$(0) abgeschlossen. Left$(R├╝ckgabewert$, InStr(R├╝ckgabewert$, Chr$(0)) - 1) liefert dann einen String in der richtigen L├Ąnge.

Hierzu ein Beispiel: Mit Hilfe einer API - Routine wird versucht, das Systemverzeichnis des Betriebsystemes Windows95 zu eruieren. Angenommen es lautet "C:\WINDOWS\SYSTEM". Diese Variable ben├Âtigt mindestens eine L├Ąnge von 17 Zeichen. Wird das Feld, also die Variable, in die der Wert geschrieben wird nur mit 15 Zeichen initialisiert, so werden die letzten zwei Zeichen in den Speicher geschrieben. Anstelle der ansonsten reservierten 255 Zeichen (Visual Basic liefert keinen String zur├╝ck, der l├Ąnger ist als 255 Zeichen) sind nun nur 15 Zeichen im Speicher frei. Angenommen, im Speicher w├╝rde hinter unserer Variable gleich anschlie├čend eine wichtige Windows - Systemdatei stehen, so w├╝rde es zu einem Datenverlust kommen, da die ersten beiden Zeichen der Variable die ersten Zeichen der Systemdatei ├╝berschreiben w├╝rden. Unter Umst├Ąnden k├Ânnte es auch zu einem Systemabsturz kommen, wenn auf die wichtige Datei unmittelbar danach zugegriffen wird, da sie 2 Byte an Fehlinformationen enth├Ąlt. Um dies zu verdeutlichen habe ich eine Zeichnung angefertigt.

Hier wurde die Systemdatei Kernel.dll mit der Variable, die die gew├╝nschten Informationen enth├Ąlt ├╝berschrieben. Es w├Ąre aber ebenso m├Âglich, dass unsere Variable von einer anderen Datei ├╝berschrieben werden w├╝rde, was wiederum einen Datenverlust, nur diesmal bei unserem Programm, zur Folge h├Ątte.
Normalerweise nimmt eine Variable, die mit 255 Zeichen initialisiert wurde, immer 255 Zeichen Platz ein. Es w├Ąren also im Normalfall 17 Zeichen und 208 Leerzeichen (208 + 17 = 255).
Ung├╝ltige Namen:
Mitunter hat eine DLL - Prozedur einen Namen, der kein g├╝ltiger Bezeichner ist. Der Name kann ein ung├╝ltiges Zeichen (beispielsweise einen Bindestrich) enthalten oder mit einem reservierten Wort von Visual Basic (beispielsweise GetObject) ├╝bereinstimmen. In diesem Fall muss das Schl├╝sselwort Alias verwendet werden.

Einige Prozeduren in den DLLs der Betriebsumgebung beginnen beispielsweise mit einem Unterstrich. Zwar k├Ânnen Sie Unterstriche in Visual Basic - Bezeichnern verwenden, doch darf der Unterstrich nicht das erste Zeichen sein. Um solche Prozeduren verwenden zu k├Ânnen, muss die Prozedur mit Alias deklariert werden:

DECLARE FUNCTION LOPEN LIB "KERNEL" ALIAS "_LOPEN" (BYVAL FN AS STRING, BYVAL F AS INTEGER) AS INTEGER

In diesem Beispiel ist LOpen der Name der Prozedur, wie er in der Visual Basic - Prozedur verwendet wird. Der Name _lopen ist der Name, der in der DLL erkannt wird.
Der Alias - Abschnitt, kann verwendet werden, wenn immer es angebracht ist. Die folgende Declare - Anweisung ersetzt beispielsweise einen langen Namen (GetWindowsDirectory) durch einen k├╝rzeren Namen (WinDir):

DECLARE FUNCTION WINDIR LIB "KERNEL" ALIAS "GETWINDOWSDIRECTORY" (BYVAL LPBUFFER AS STRING, BYVAL NSIZE AS INTEGER) AS INTEGER

Nun kann die Funktion mit einem k├╝rzeren Namen aufgerufen werden:

DIM WINPATH AS STRING
WINPATH = STRING(145, CHR(0))
WINPATH = LEFT(WINPATH, WINDIR(WINPATH, LEN(WINPATH))) 
├ťbergeben von Zeichenfolgen:
Visual Basic verwendet einen String - Datentyp, der als BSTR bezeichnet wird und einen Datentyp darstellt, der durch die OLE - Automatisierung definiert wird. Ein BSTR - Wert verh├Ąlt sich wie ein Zeiger auf das erste Datenbyte. BSTR - Werte verweisen auf Zeichenfolgen, die durch ein Null - Zeichen (ANSI - Wert Null) begrenzt sind. Den Daten ist ein Header vorangestellt, der von Visual Basic verwendete Informationen enth├Ąlt. Der BSTR - Wert ignoriert diesen Header und verweist auf das erste Datenbyte in der Zeichenfolge.

Die folgende Funktion w├╝rde Daten in eine Variable schreiben. Ist diese Variable aber nicht lange genug (z.B.: weniger als zehn Zeichen, obwohl 17 ben├Âtigt w├╝rden), so w├╝rde die API - Funktion ├╝ber den reservierten Speicher hinausschreiben, ein anderer Inhalt w├╝rde ├╝berschrieben werden und ein Datenverlust w├Ąre die Folge.

DECLARE FUNCTION GETWINDOWSDIRECTORY LIB "KERNEL" (BYVAL LPBUFFER AS STRING, BYVAL NSIZE AS INTEGER) AS INTEGER

Eine sichere L├Âsung zum Aufrufen der Prozedur ist das Erstellen eines R├╝ckgabearguments, das mindestens 255 Zeichen lang ist, durch Auff├╝llen des Arguments mit Zeichen — in diesem Fall mit Null - Zeichen (Bin├Ąrwert Null):
PATH = STRING(255, 0)
RETURNLENGTH = GETWINDOWSDIRECTORY(PATH, LEN(PATH))
PATH = LEFT(PATH, RETURNLENGTH)
16/32 bit - Anwendungen:
Sehr wichtig bei der Betrachtung von 16 - Bit - und 32 - Bit - Versionen von Visual Basic 4.0 sind Fragen im Zusammenhang mit ANSI und UNICODE. Wenn DLLs geschrieben werden, verwenden ANSI - Zeichenfolgen ein Byte pro Zeichen und UNICODE - Zeichenfolgen zwei Byte pro Zeichen.

Die 16 - Bit - Version von Visual Basic verwendet entweder ANSI - oder DBCS - Zeichenfolgen. Die 32 - Bit - Version von Visual Basic verwendet UNICODE - Zeichenfolgen. Deshalb sollte eine Reihe von Dingen ber├╝cksichtigt werden, wenn DLLs f├╝r die Verwendung mit Visual Basic 4.0 geschrieben werden.

    Wenn eine 1 - Byte - Variable ben├Âtigt wird, kann 'String * 1' in der 16 - Bit - Version von Visual Basic verwendet werden. In der 32 - Bit - Version von Visual Basic nimmt 'String * 1' jedoch tats├Ąchlich zwei Bytes im Speicher ein. Darum wurde der Datentyp Byte eingef├╝hrt. Dieser Datentyp nimmt 1 - Byte im Speicher ein, unabh├Ąngig davon, ob er in der 16 - Bit - oder in der 32 - Bit - Version von Visual Basic verwendet wird. In Win32 (32bit Bsp.: Win95, WINNT) wird bei Namen von DLL - Prozeduren zwischen Gro├č - und Kleinschreibung unterschieden. In Win16 (16bit Bsp.: Windows 3.11) ist dies nicht der Fall. GetSystemMetrics und GETSYSTEMMETRICS sind daher unterschiedliche Funktionen. Dennoch ist in diesem Fall nur der erste Name korrekt, so wie er in USER32.DLL existiert. Wenn also die normale DECLARE - Anweisung f├╝r diese Funktion:

DECLARE FUNCTION GETSYSTEMMETRICS LIB "USER32" (BYVAL N AS INTEGER) AS INTEGER
auch an anderer Stelle im Projekt existiert (z.B. wenn die FESTSTELL - TASTE bei der Eingabe des Funktionsnamens zuf├Ąllig gedr├╝ckt wird), z.B. als

DECLARE FUNCTION GETSYSTEMMETRICS LIB "USER32" (BYVAL N AS INTEGER) AS INTEGER
wird auch die vorherige Definition dementsprechend ge├Ąndert.

In Win16 gibt es diesen Unterschied nicht, da bei Funktionsnamen nicht zwischen Gro├č - und Kleinschreibung unterschieden wird. In Win32 w├╝rde jedoch ein Laufzeitfehler auftreten, da GETSYSTEMMETRICS nicht in der DLL existiert. Dieses Problem kann dadurch umgangen werden, indem der Alias - Abschnitt wie folgt verwendet wird:
DECLARE FUNCTION GETSYSTEMMETRICS LIB "USER32" ALIAS GETSYSTEMMETRICS (BYVAL N AS INTEGER) AS INTEGER
So wird sichergestellt, dass der im Alias verwendete Name nicht von einer Umwandlung (falls sie vorkommt) betroffen ist. Unabh├Ąngig davon, wie der Name in anderen Teilen des Codes verwendet wird, bezieht sich die Deklaration somit weiterhin auf den korrekten Prozedurnamen in der DLL.
Bedingte Kompilierung:
Die Befehle, die zur bedingten Kompilierung notwendig sind, gleichen den normalen Visual Basic Befehlen (If, ElseIf, Else, End If). Der einzig gro├če Unterschied besteht darin, dass diese Befehle nur einmal ausgef├╝hrt werden, und zwar dann, wenn das Programm kompiliert wird. Um dies zu verdeutlichen muss ich an dieser Stelle ein Beispiel aufzeigen: Es ist m├Âglich, dass ein Programm sowohl unter Windows 3.11 (o.├Ą.) als auch unter Windows95 ausgef├╝hrt werden soll. Nun lauten aber die Aufrufe f├╝r die Win16 API anders als f├╝r die Win32 API. Hier schaltet sich nun die bedingte Kompilierung ein. Falls die Win32 API ben├Âtigt wird, werden die Anweisungen f├╝r diese geladen und die Anweisungen f├╝r die Win16 API ├╝bersprungen und umgekehrt.
Geschwindigkeit vs. Sicherheit bei der Nutzung von API - Routinen - Zusammenfassung[6]
Es gibt eigentlich zwei ├╝berzeugende Gr├╝nde, um die Windows - API mit Visual Basic zu benutzen: gesteigerte M├Âglichkeiten und verbesserte Performance. Die gesteigerten M├Âglichkeiten kommen daher, da Visual Basic nur ein stark gek├╝rztes Set der Windows - M├Âglichkeiten unterst├╝tzt. Eben dieses Subset, also eine kleinere Einteilung bewirkt, dass die Programmierung mit Visual Basic sehr sicher ist - mindestens um vieles sicherer als eine andere Programmierumgebung. Kurz gesagt: Visual Basic verbessert die Sicherheit, indem es die verf├╝gbaren Funktionen limitiert.

Sobald man nun beginnt, mit der Windows32 API zu arbeiten, ├Ąndert sich dies wieder: Die Sicherheit wird au├čer Acht gelassen, die Kapazit├Ąt kommt voll zum Vorschein. Mit verschiedenen Tools wie z.B. denen der Firma Desaware (als Beispiel m├Âchte ich an dieser Stelle die Desaware SpyWorks vermerken) kann ein Visual Basic Programmierer fast an die M├Âglichkeiten eines C/C++ Programmierers hinkommen. Zus├Ątzlich zu dem Umfang der API - Routinen kommt auch noch eine verbesserte Geschwindigkeit, da die meisten API - Routinen auf Geschwindigkeit hin optimiert wurden. Au├čerdem kann eine API - Funktion die Arbeit verschiedener Visual Basic Kommandos ├╝bernehmen, was sich wiederum positiv auf die Geschwindigkeit auswirkt. Als Beispiel hierf├╝r m├Âchte ich nur die Graphikfunktionen nennen. Zusammenfassend kann gesagt werden, dass es m├Âglich ist, den Kampf Geschwindigkeit gegen Sicherheit zu kontrollieren. Man muss nur aufpassen, welche Funktionen man f├╝r welche Aufgaben ben├Âtigt.
Vergleich:
Visual Basic Code:
Vorteile
Nachteile
H├Âchste Sicherheit
Niedrigere Performance (langsamer)
Einfach zu testen und Fehler sind leicht zu beheben
Ben├Âtigt oft mehr Programmieraufwand als die Nutzung von Custom Controls
Plattformunabh├Ąngig

Win32 API Code:
Vorteile
Nachteile
H├Âchste Flexibilit├Ąt
Ben├Âtigt sowohl Win32 als auch Win16 Code
Getestet und dokumentiert
Ben├Âtigt gute Kenntnisse
Bietet h├Âhere Performance


Custom - Controls (Benutzerdefinierte Steuerelemente) und OLE - Server:
Vorteile
Nachteile
Einfach zu ben├╝tzen
Ben├Âtigt die Auslieferung von zus├Ątzlichen Software - Komponenten
M├Âglicherweise hervorragende Performance


BeispielProgramm: Computer Informationen: Programmiert von Thomas Linder - 8c - 1998
├ťber dieses Programm:
Die Idee dieses Programms hatte ich bereits vor langer Zeit. Ich wollte ein Programm entwerfen, das etwas leistet und das man herzeigen kann. Normalerweise habe ich als Sch├╝ler nicht soviel Zeit, um ein wirklich anspruchsvolles Programm zu entwerfen. Diese Fachbereichsarbeit gab mir die Gelegenheit dazu, ein Programm aus zwei Gr├╝nden zu entwerfen. Der erste Grund ist, wie bereits erw├Ąhnt, dass ich schon immer einmal ein leistungsf├Ąhiges Programm entwerfen wollte. Der zweite Grund ist, dass ich dies dann machen kann, wenn es mir wirklich etwas n├╝tzt.
Aufgrund dieser Fachbereichsarbeit kann ich nun diese beiden Faktoren verkn├╝pfen.
Nat├╝rlich kann sich dieses Programm nicht mit den Programmen von professionellen Programmierern messen. Es ist auch erst das zweite Projekt in dieser Gr├Â├čenordnung. Das Ziel dieses Programmes ist es, ein gutes Beispiel daf├╝r zu sein, was mit einfachen Mitteln alles m├Âglich ist. Zu Beginn sollte dieses Programm einfach die M├Âglichkeiten darstellen, was alles m├Âglich ist. Ich dachte zuerst nicht daran, ein vollst├Ąndiges Programm zu entwickeln. Im Laufe der Zeit allerdings, kam immer mehr der Wunsch nach einer "richtigen" Oberfl├Ąche. Da zuerst die Laufwerksinformationen entwickelt wurden, war zun├Ąchst dies mein Hauptfenster. Als ich dann allerdings nicht mehr wu├čte, wie ich die verschiedenen Schaltfl├Ąchen anordnen sollte, wurde mir klar, dass eine gr├Â├čere Oberfl├Ąche her musste. Ein einfaches Fenster, das sich zu Beginn ├Âffnet und mir zehn verschiedene Schaltfl├Ąchen zeigte, war mir zu primitiv und unsch├Ân. Also beschlo├č ich, einen Explorer bzw. Dateimanager - Ersatz zu machen. Obwohl auch meine Version viele Funktionen f├╝r verschiedene Dateitypen beinhaltet, ist es kein vollwertiger Ersatz. Die Programmierung schritt fort, und kurze Zeit sp├Ąter hatte ich die Systemspeicherinformationen, die Prozessorinformationen und Betriebssysteminformationen. Als Schlu├čpunkt suchte ich noch einige spielerische aber dennoch n├╝tzliche API - Funktionen, die mir ich unter die Rubrik "Verschiedene API - Funktionen" steckte. Vielleicht sind diese im Augenblick nicht n├╝tzlich, aber es ist einfacher an sie zu gelangen als sich in der Systemsteuerung von Windows95 herumzuqu├Ąlen.
Information bez├╝glich Sourcecode:
Da ich nicht den ganzen Sourcecode abdrucken kann, der gute 34 Seiten umfa├čt (+20 Seiten Programmformatierung), habe ich eine CD beigelegt, die sowohl diese Arbeit als auch den vollst├Ąndigen Code des Programmes enth├Ąlt. Ich habe mich dazu entschlossen, nur die wichtigsten Stellen abzudrucken. Damit sind die Stellen gemeint, die f├╝r die API - Routinen wirklich wichtig sind. Da ich nur wenige, daf├╝r teilweise recht komplizierte API - Routinen verwende, habe ich mich ebenfalls entschlossen alle davon mit dem richtigen Aufruf darzustellen. Diese stellvertretend f├╝r die gewaltige Menge an API - Aufrufen. Alle Aufrufe der restlichen Routinen, funktionieren mehr oder weniger nach demselben Prinzip.

Vor dem Programmcode befindet sich eine kurze Beschreibung der Form, die klarmachen soll, was diese Form darstellen bzw. auswerten soll und um was es sich in dem jeweiligen Teilbereich des Programmes handelt.

Der eigentliche Programmcode wird in Blau dargestellt. Nach jedem Programmblock folgt eine kurze Erkl├Ąrung, die die wichtigsten Schritte verdeutlicht.
Der Sourcecode:
Generelle Informationen:
In diesem Programm kommen sehr viele benutzerdefinierte Datentypen vor. Diese werden, zusammen mit den API - Aufrufen in dem Modul Modul1.bas definiert.
Die Hauptform:
Diese Form ist eigentlich nicht sehr wichtig, denn sie ist nur die Sprungform zu den wichtigen Teilen.

Allerdings enth├Ąlt sie eine API - Routine. Bei Doppelklick auf eine Datei mit Endung "wav" innerhalb des Dateifensters, wird diese Sounddatei (wav = Sounddatei) automatisch abgespielt. Die der dazu geh├Ârende Code:

Dim PathuDatei As String
If Len(Dir1.Path) > 3 Then 'markierte Datei an Variable PathuDatei ├╝bergeben
 PathuDatei = Dir1.Path + "\" + File1.filename
Else
 PathuDatei = Dir1.Path + File1.filename
End If
endung = Trim$(Right$(PathuDatei, 3))
Select Case endung
...
Case "wav"
 xxx& = sndPlaySound(PathuDatei, 1) 'API - Aufruf, um Sound Datei abzuspielen
...
Case Else
...
End Select

Hier wird zuerst der Variable "PathuDatei" der Datentyp String zugewiesen. Der Variable PathuDatei wird darauf der Name und der Ort der Datei, auf die doppelgeklickt wurde, ├╝bergeben (Bsp.: "C:\WINDOWS\MEDIA\Der Microsoft Sound.wav". Hierauf werden die letzten drei Zeichen genommen (sie sind die endung), welche dann in der Variable "endung" gespeichert werden. Nun folgt eine Select Case - Anweisung, die je nach "endung" eine bestimmte Prozedur vollzieht. In diesem Fall geschieht dies, wenn die Endung auf "wav" lautet. Ist dies der Fall, so wird eine API - Routine aufgerufen, die den Namen sndPlaySound tr├Ągt. Ihr werden zwei Parameter ├╝bergeben. Einer ├╝bergibt die Datei und wo diese gespeichert ist, der andere bezeichnet die Art, wie die Datei abgespielt wird. Dies ist die einzige API - Routine, die in dieser Form vorkommt.
Die Form ProzInfo:
Auch hier kommt nur eine API - Routine zum Einsatz. Diese liefert allerdings mehr als eine Information. Sie w├╝rde noch mehrere Informationen liefern, allerdings sind diese in diesem Programm nicht wichtig. Ben├Âtigt werden nur zwei Informationen: Die Anzahl der Prozessoren und den Typ der/des Prozessoren/Prozessors. Diese Informationen werden in einer benutzerdefinierten Variable namens "SysInfo" gespeichert. Hier der Code:
'DEKLARATION DER VARIABLEN
DIM SYSINFO AS SYSTEM_INFO 'BENUTZERDEFINIERTER DATENTYP
DIM M AS STRING
GETSYSTEMINFO SYSINFO 'API - AUFRUF
M$ = "PROZESSORTYP: "
'PROZESSORTYP
SELECT CASE SYSINFO.DWPROCESSORTYPE
CASE PROCESSOR_INTEL_386
 M$ = M$ + "INTEL 386"
CASE PROCESSOR_INTEL_486
 M$ = M$ + "INTEL 486"
CASE PROCESSOR_INTEL_PENTIUM
 M$ = M$ + "INTEL PENTIUM"
CASE PROCESSOR_MIPS_R4000
 M$ = M$ + "MIPS R4000"
CASE PROCESSOR_ALPHA_21064
 M$ = M$ + "ALPHA WORKSTATION"
...
M$ = M$ + VBCRLF
M$ = M$ + "ANZAHL DER PROZESSOREN: "
'ANZAHL DER INSTALLIERTEN PROZESSOREN
ANZ& = SYSINFO.DWNUMBERORFPROCESSORS
M$ = M$ + STR$(ANZ&)

Zu Beginn werden die verschiedenen Variablen initialisiert. "SysInfo" wird als benutzerdefinierte Variable SYSTEM_INFO und "m" als Zeichenkette initialisiert. Die API - Routine wird mit der Anweisung GetSystemInfo aufgerufen. Die verschiedenen Werte werden an die Variable SysInfo ├╝bergeben. In der Variable m steht, was sp├Ąter im Bezeichnungsfeld in der Form ausgegeben werden soll. Zuerst das Wort Prozessortyp, dann der dazugeh├Ârige Wert, eine Zeilenschaltung und dann die Zeichenfolge "Anzahl der Prozessoren" und deren Wert.

Der Prozessortyp ist in einer Untervariable der Variable SysInfo gespeichert. Diese Untervariable lautet "dwProcessorType". Die gesamte Variable lautet demzufolge "SysInfo.dwProcessorType". Die zweite Untervariable betrifft die Anzahl der Prozessoren und lautet "dwNumberOrfProcessors". Die zusammengesetzte lautet demzufolge "SysInfo.dwNumberOrfProcessors".

In dem Modul Modul.bas befinden sich die Konstanten, die ben├Âtigt werden, um den Prozessortyp zu bestimmen, da die Variable dwProcessorType nur einen Hexadezimalwert liefert. Der richtige Prozessor wird durch eine Case - Anweisung ausgew├Ąhlt.
Die Form OSInfo:
Diese Form stellt Informationen, die das Betriebssystem betreffen, dar. Auch hier wird wieder ein benutzerdefinierter Datentyp verwendet.

DIM VI AS OSVERSIONINFO 'BENUTZERDEFINIERTER DATENTYP
DIM MAJORVERSION AS STRING 'HAUPT VERSION
DIM MINORVERSION AS STRING 'UNTER VERSION
GETVERSIONEX VI 'API - AUFRUF: SPEICHERT INFORMATIONEN IN DER VARIABLE VI
SELECT CASE VI.DWMAJORVERSION
...
VERSIO$ = MA$ + "." + MI$ + "." + M$
...
INFO$ = VI.SZCSDVERSION
...
LABEL1.CAPTION = "MAJOR VERSION: " + MAJORVERSION + VBCRLF
LABEL1.CAPTION = LABEL1.CAPTION + "MINOR VERSION: " + MINORVERSION + VBCRLF
LABEL1.CAPTION = LABEL1.CAPTION + "BUILD: " + STR$(VI.DWBUILDNUMBER) + VBCRLF
LABEL1.CAPTION = LABEL1.CAPTION + "PLATFORM ID: " + STR$(VI.DWPLATFORMID) + VBCRLF
LABEL1.CAPTION = LABEL1.CAPTION + "VERSION: " + VERSIO$ + VBCRLF
LABEL1.CAPTION = LABEL1.CAPTION + "ZUSATZINFORMATIONEN " + INFO$ + VBCRLF
...

Hier wird die Variable "Vi" als benutzerdefinierter Datentyp dimensioniert. Au├čerdem werden zwei weitere Variablen ben├Âtigt: Die Hauptversion und die Unterversion des Betriebssystem. Existiert kein zweites Betriebssystems, so soll eine Meldung im Bezeichnungsfeld auf der Form stehen. Die hier ben├Âtigte API - Routine lautet mit vollem Aufruf: "GetVersionEx Vi". Durch diesen werden s├Ąmtliche Werte in der Variable Vi gespeichert.

Die Versionsnummer setzt sich aus mehreren Komponenten zusammen. Der Nummer der Hauptbetriebsystems, der Nummer des Unterbetriebsystems und aus der Build Number, die ebenfalls ein Teilbereich der Variable Vi ist.

Eventuelle Zusatzinformationen werden noch in der Variable "szCSDVersion" gespeichert und schlu├čendlich wird die Information in das Bezeichnungsfeld der Form "OsInfo" eingetragen.
Die Form RamInfo:
Diese Form ist zwar etwas komplizierter aufgebaut, ist allerdings dasselbe wie die vorhergehenden Formen. Sie beinhaltet wiederum eine einzelne API - Routine, die s├Ąmtliche Werte in einer Variable abspeichert. Diese werden dann jeweils durch 1024 dividiert, um die n├Ąchst - gr├Â├čeren Einheiten zu erhalten (Kbyte, Mbyte, ...).
DIM MEMINFO AS MEMORYSTATUS
GLOBALMEMORYSTATUS MEMINFO
USED& = MEMINFO.DWMEMORYLOAD
'PHYSIKALISCHER SPEICHER (WIRKLICH)
PHYSICAL& = MEMINFO.DWTOTALPHYS / 1024
AVAIL& = MEMINFO.DWAVAILPHYS / 1024
PIP& = 100 * AVAIL& / PHYSICAL&
'PAGE FILE - SPEICHER
PAGEFILE& = MEMINFO.DWTOTALPAGEFILE / 1024
AVAILPAGE& = MEMINFO.DWAVAILPAGEFILE / 1024
PFIP& = 100 * AVAILPAGE& / PAGEFILE&
'VIRTUELLER SPEICHER
VIRTUAL& = MEMINFO.DWTOTALVIRTUAL / 1024
AVAILVIRTUAL& = MEMINFO.DWAVAILVIRTUAL / 1024
VIP& = 100 * AVAILVIRTUAL& / VIRTUAL&

Die Variable memInfo wird hier, wie bei den anderen Formen, als ein benutzerdefinierter Datentyp dimensioniert. Nun wird der API Aufruf mit "GlobalMemoryStatus memInfo" vollzogen. Die Variable beinhaltet nun die verschiedenen Werte f├╝r den physikalischen Speicher, den Page File - Speicher und den Virtuellen Speicher in Byte. Sie beinhaltet sowohl den zur Zeit benutzten als auch den zur Zeit freien Systemspeicher. Nun werden die einzelnen Angaben der Reihe nach in Kbyte und in Prozent umgewandelt, um besser lesbare Werte zu erhalten. Zum Schlu├č werden diese wieder in drei verschiedene Bezeichnungsfelder eingetragen.
Die Form SysInfo:
Diese Form stellt verschiedene M├Âglichkeiten zur Auswahl, wie Windows beendet werden soll. Dies sind genau die Funktionen, die man beim Abschalten des Computers erh├Ąlt. Diese Funktionen sind ebenfalls API - Routinen. Genauer gesagt sie sind eine einzelne API - Routine, der als Parameter ├╝bergeben werden muss, wie Windows beendet werden soll. Dieses Problem wurde mit vier Optionskn├Âpfen gel├Âst (Windows beenden, Windows neu starten, MS - DOS - Modus, Neu Anmelden). Au├čerdem enth├Ąlt die Form zwei Schaltfl├Ąchen, durch die die Auswahl best├Ątigt oder abgebrochen werden soll (OK, Abbrechen).

IF OPTION1.VALUE = TRUE THEN R& = EXITWINDOWSEX(1, 0)
IF OPTION2.VALUE = TRUE THEN R& = EXITWINDOWSEX(2, 0)
IF OPTION3.VALUE = TRUE THEN R& = EXITWINDOWSEX(8, 0)
IF OPTION4.VALUE = TRUE THEN R& = EXITWINDOWSEX(0, 0)

Dies ist der ganze Code, der f├╝r diese vier M├Âglichkeiten ben├Âtigt wird. Die API - Routine lautet "ExitWindowsEx". Ihr wird ein Parameter ├╝bergeben, der bestimmt, auf welche Art dies geschieht. Der zweite Parameter ist nicht wichtig. Er wird daher auf 0 (Null) gesetzt. Um unterscheiden zu k├Ânnen, welches Optionsfeld aktiviert wurde, wird die If - Bedingung verwendet.
Die Form SmallDriveDir
Diese Form beinhaltet eigentlich keinen richtigen API - Aufruf. Dennoch ist sie wichtig, um eine Datei auszuw├Ąhlen, die dann einer anderen Form als globale Variable ├╝bergeben wird. Mit Hilfe einer API werden dann aus dieser Datei verschiedene Informationen genommen, die z.B.: bestimmen, ob es eine 32bit - EXE(cute) - Datei ist. Sie ist demzufolge nur ein kleiner Baustein, der in meinem Programm genutzt wird und beinhaltet keine API - Routinen.
Die Form GenInfo:
Diese Datei beinhaltet verschiedene API - Routinen, die den Benutzernamen bzw. den Namen des Computers ermitteln, die Multimedia - Ausr├╝stung (Soundkarte) ermitteln, den Batteriestatus ermitteln (nur bei einem Notebook interessant), die Systempfade f├╝r das Windows - Systemverzeichnis bzw. das tempor├Ąre Verzeichnis ermitteln und auch die Sprungplattform zur Form SmallDriveDir ist (32bit - Programme). Diese Form ist sehr komplex und unterschiedet sich von den bisherigen Formen dadurch, dass nicht nur eine einzelne API - Routine, sondern gleich mehrere Funktionen vorkommen.
Hier ein paar Bruchst├╝cke aus dem Code dieser Form:

PRIVATE SUB FORM_LOAD()
X = VBCRLF
' WERTE IN BEZEICHNNGSFELDER EINTRAGEN
LABEL1.CAPTION = "COMPUTERNAME:" + X
LABEL1.CAPTION = LABEL1.CAPTION + "BENUTZERNAME:" + X
LABEL5.CAPTION = ""
'VERSCHIEDENE PROZEDUREN AUSF├╝HREN
GENINFOSZEIGEN
GETAKKUINF
GETSYSTEMDIRS
GETMMINFO
END SUB

Wird diese Form geladen, so werden als erstes die Beschriftungen in die Bezeichnungsfelder eingetragen. Danach werden verschiedene Prozeduren ausgef├╝hrt, von denen jede f├╝r einen bestimmten Teil der API - Routinen zust├Ąndig ist (GenInfosZeigen: Computer - und Benutzername; GetAkkuInf: Ladezustand des Akkus anzeigen; GetSystemDirs: Systemverzeichnisse ermitteln; GetMMInfo: Multimedia - Informationen ermitteln).
Zuerst zur Prozedur GenInfosZeigen:

AUSGABE = SPACE$(255)
LENGTH = LEN(AUSGABE)
VERWERFEN% = GETCOMPUTERNAME(AUSGABE, LENGTH)
AUSGABE = LEFT$(AUSGABE, LENGTH)
LABEL2.CAPTION = AUSGABE + X
AUSGABE = SPACE$(255)
LENGTH = LEN(AUSGABE)
A% = GETUSERNAME(AUSGABE, LENGTH)
LABEL2.CAPTION = LABEL2.CAPTION + LEFT$(AUSGABE, LENGTH)

Hier wird zuerst die Variable Ausgabe auf 255 Zeichen dimensioniert, d.h. sie hat eine L├Ąnge von 255 Zeichen, egal ob nur 10 Zeichen in sie geschrieben werden. Die restlichen Zeichen werden der Einfachheit halber durch Nullen bzw. Leerzeichen ersetzt. Hierauf wird die L├Ąnge auf die L├Ąnge der Variable Ausgabe gesetzt (in diesem Fall 255). Nun wird die API - Routine GetComputerName aufgerufen. Diese erh├Ąlt als ├ťbergabewerte zwei Argumente, n├Ąmlich den Text (Variable: Ausgabe) und die L├Ąnge des Textes (Variable: Length). Damit nun die restlichen Leerzeichen abgeschnitten werden, wird der Befehl "Left" verwendet. Dieser erh├Ąlt nun ebenfalls zwei Argumente, genau dieselben, die zuvor der API - Routine entnommen wurden. Mit dem Befehl Left werden von der Variable "Ausgabe" soviel Zeichen behalten, wie in der L├Ąngenangabe "Length" enthalten sind. Ist Length zum Beispiel 15, so werden 15 Zeichen genommen, der Rest wird abgeschnitten. Nun wird noch die Variable "Ausgabe", die nun genauso viel Zeichen enth├Ąlt, wie die Information wirklich hat, in das Bezeichnungsfeld eingetragen. Dasselbe geschieht nun mit der API - Routine GetUserName, nur mit dem Unterschied, dass diese Routine den Benutzernamen anstatt des Computer - Namens ausgibt.

Die zweite Prozedur gilt den Akku - Ladestatus - Informationen:

DIM PSTATUS AS SYSTEM_POWER_STATUS
IF GETSYSTEMPOWERSTATUS(PSTATUS) THEN
ELSE
 MSGBOX "FEHLER BEIM ABFRAGEN DES BATTERIESTATUS"
END IF
LABEL3.CAPTION = "AC POWER STATUS:" 'BATTERIESTATUS
SELECT CASE PSTATUS.ACLINESTATUS
 CASE 0
 ..... 
Hier wird zu Beginn die Variable pStatus (steht f├╝r Power Status) als benutzerdefinierter Datentyp deklariert. Nun folgt eine ├ťberpr├╝fung, ob der Computer Informationen ├╝ber den Batteriestatus liefert. Tut er dies nicht, so wird eine Fehlermeldung ausgegeben. Hier wurde die API - Routine in eine If - Schleife mit eingebaut. Auch auf diese Art erh├Ąlt Visual Basic den Wert der API - Routine (bzw. die Werte). Der API - Routine wird nur ein Argument ├╝bergeben, n├Ąmlich die Variable, in der die Informationen gespeichert werden sollen. Nun wird je nach Wert mit Hilfe einer Case - Auswahlschleife die Information ermittelt und der dazu passende Text ausgegeben. Nun folgen verschiedene Aufrufe, die verschiedene Werte (alle aus dem benutzerdefinierten Datentyp pStatus) ausgelesen. Diese werden dann in die verschiedenen Bezeichnungsfelder geschrieben.
Die Prozedur GetSystemDirs:

'WINDOWS SYS - VERZEICHNIS ERMITTELN
TEMP$ = SPACE$(255)
LENGTH& = GETSYSTEMDIRECTORY(TEMP$, LEN(TEMP$))
LABEL6.CAPTION = "WINDOWS SYSTEMVERZEICHNIS: " + LEFT(TEMP$, LENGTH&)

'TEMPOR├ĄRES VERZEICHNIS ERMITTELN
TEMP$ = SPACE$(255)
LENGTH& = GETTEMPPATH(LEN(TEMP$), TEMP$)
LABEL6.CAPTION = LABEL6.CAPTION + VBCRLF + "WINDOWS TEMP - VERZEICHNIS: " + LEFT(TEMP$, LENGTH&)

Dies ist wiederum eine kurze Prozedur, die nur zwei Aufrufe erfordert. Genau wie bei dem Computernamen wird auch hier die Variable "Temp" (entspricht der Variable "Ausgabe" beim Computernamen) auf die L├Ąnge von 255 Zeichen gebracht. Der einzige Unterschied zum Computernamen besteht darin, dass die L├Ąnge nicht einzeln als Variable dimensioniert wird. Sie wurde bereits in die API - Funktion mit einbezogen. Ansonsten verl├Ąuft der gesamte Aufbau gleich wie bei der ersten Prozedur dieser Form.

Die letzte Prozedur liest aus verschiedenen API - Routinen Informationen zur Multimedia Ausstattung aus.

VERSIONOFMM% = MMSYSTEMGETVERSION
WINOD% = WAVEINGETNUMDEVS 'ANZAHL DER WAVE - IN GER├ĄTE
WONOD% = WAVEOUTGETNUMDEVS 'ANZAHL DER WAVE - OUT GER├ĄTE
'EINTRAGEN
LABEL7.CAPTION = "VERSION DES MM - SYSTEMS: " + STR$(VERSIONOFMM%) + VBCRLF
LABEL7.CAPTION = LABEL7.CAPTION + "ANZAHL DER WAVE - IN GER├ĄTE: " + STR$(WINOD%) + VBCRLF
LABEL7.CAPTION = LABEL7.CAPTION + "ANZAHL DER WAVE - OUT GER├ĄTE: " + STR$(WONOD%)

Zuerst wird mit der Routine mmsystemGetVersion die Versionsnummer des Multimedia - Subsystems ausgelesen. Danach werden noch die Anzahl der Wave - In - (Ger├Ąte, die Musik aufzeichnen k├Ânnen) und die Anzahl der Wave - Out - (Ger├Ąte , die Musik abspielen k├Ânnen) Ger├Ąte ausgelesen. Zum Schlu├č werden diese Informationen noch in diese Form eingetragen. Damit ist auch die Form GenInfo fertig.

Die Form DiffAPI:
Diese Form stellt mehr oder weniger Funktionen zur Verf├╝gung, die auch ├╝ber die Systemsteuerung einzustellen sind. Unter anderem beinhaltet sie eine M├Âglichkeit zum Einstellen der Doppelklickgeschwindigkeit. Diese Form ist nicht dazu da, wirklich zum Nutzen meines Programmes beizutragen. Diese Form ist eher als Darstellung der verschiedenen M├Âglichkeiten, die mit API - Funktionen m├Âglich sind, zu sehen. Sie beinhaltet im wesentlichen drei Teile: Der erste Teil dient dem Einstellen der Doppelklickgeschwindigkeit. Dazu geh├Ârt auch, dass der aktuelle Wert zun├Ąchst ausgelesen wird. Dies geschieht bereits beim ersten ├ľffnen der Form. Au├čerdem werden hier auch gleich die Werte des Tastaturzeichens ausgelesen (CaretBlinkTime)

'DOPPELKLICKZEIT UND CARET - BLINKZEIT - INFORMATION HOLEN UND EINTRAGEN
LABEL2.CAPTION = STR$(GETDOUBLECLICKTIME) + " MS"
LABEL3.CAPTION = STR$(GETCARETBLINKTIME) + " MS" 

In das erste Bezeichnungsfeld (Label2) wird ├╝ber die API - Routine "GetDoubleClickTime" die Doppelklickzeit ausgelesen. Durch den Befehl Str$ wird diese in einen Zeichenfolgen - Datentyp umgewandelt und der Zusatz MS (Millisekunden) wird an den Wert angeh├Ąngt. Das Selbe geschieht mit dem Tastaturzeichen.

Um die Doppelklickgeschwindigkeit einzustellen, ben├Âtigt man eine andere API - Routine: Die zur Get - dazugeh├Ârende Set - Anweisung

ANFANG:
NEWDCTIME = INPUTBOX("NEUE DOPPELKLICKZEIT EINGEBEN")
IF ISNUMERIC(NEWDCTIME) = TRUE THEN 
 NEWDCTIME = CLNG(NEWDCTIME)
 XXX& = SETDOUBLECLICKTIME(NEWDCTIME)
 STARTPROZ
ELSE 'SONST: FEHLERMELDUNG
 MSGBOX ("BITTE GEBEN SIE EINE G├╝LTIGE ZAHL IN MS EIN (STANDARD = 500)")
 GOTO ANFANG
END IF

Gleich zu Beginn wird eine Zeilenmarke eingef├╝hrt, an die das Programm im Falle eines Fehlers bei der Ausf├╝hrung springt. Die neue Doppelklickzeit wird ├╝ber eine InputBox eingegeben. Nun wird ├╝berpr├╝ft, ob dies ├╝berhaupt eine Zahl ist (IsNumeric). Ist dies der Fall, so wird die Zeit vom Zeichenfolgen - Datentyp in den Datentyp Long umgewandelt (Long = Lange Ganzzahl). Mit Hilfe der Funktion SetDoubleClickTime, der als Argument der Wert der neuen Doppelklickzeit ├╝bergeben wird, wird nun die neue Doppelklickzeit eingestellt. Zum Schlu├č wird noch einmal die Prozedur StartProz aufgerufen, die die Werte neu liest und in der Form neu darstellt. Ist nun aber der eingegebene Wert keine Zahl, so wird eine Fehlermeldung ausgegeben und das Programm springt zum Anfang der Prozedur, es fordert demnach den Benutzer zu einer neuerlichen Eingabe auf.

Um die Blinkgeschwindigkeit der Tastaturcursors einzustellen, wird genau dieselbe Funktion verwendet. Die API - Routine f├╝r diese Prozedur lautet SetCaretBlinkTime. Der folgende Code bedarf keiner Erkl├Ąrung, da eigentlich alles schon in der Prozedur zur Einstellung der Doppelklickgeschwindigkeit beschrieben wurde.

ANFANG:
NEWCBTIME = INPUTBOX("NEUE CARET BLINKZEIT EINGEBEN")
IF ISNUMERIC(NEWCBTIME) = TRUE THEN 
 NEWCBTIME = CLNG(NEWCBTIME)
 XXX& = SETCARETBLINKTIME(NEWCBTIME)
 STARTPROZ
ELSE
 MSGBOX ("BITTE GEBEN SIE EINE G├╝LTIGE ZAHL IN MS EIN (STANDARD = 500)")
 GOTO ANFANG
END IF 

Der n├Ąchste Teil, der dem Einstellen der Mauscursor - Koordinaten dient, ist nicht viel komplexer, allerdings wird hier ein benutzerdefinierter Datentyp verwendet, der den X - Wert (horizontal) und den Y - Wert beinhaltet. Im Gegenteil zu den beiden vorhergehenden Funktionen werden die angezeigten Werte nicht nur einmal aktualisiert, sondern bei jeder Bewegung der Maus ├╝ber der Form.

DIM LPPOINT AS POINTAPI
D& = GETCURSORPOS(LPPOINT)
KOOX = STR$(LPPOINT.X)
KOOY = STR$(LPPOINT.Y)
LABEL1.CAPTION = "AKTUELLE X - KOORDINATE DES MAUSZEIGERS " + KOOX + " PIXEL" + VBCRLF
LABEL1.CAPTION = LABEL1.CAPTION + "AKTUELLE Y - KOORDINATE DES MAUSZEIGERS " + KOOY + " PIXEL"

Zuerst wird die Variable lpPoint als benutzerdefinierter Datentyp dimensioniert. Mit der Funktion GetCursorPos werden die aktuellen Werte in die Variable lpPoint eingetragen. Nun werden die einzelnen Werte aus der Variable ausgelesen, umgewandelt, formatiert und in die Form eingetragen.

Um die Werte zu setzen wird die API - Routine SetCursorPos verwendet.

ON ERROR GOTO ENDE 
DIM XPOS AS LONG 
DIM YPOS AS LONG
XPOS = CLNG(INPUTBOX("BITTE GEBEN SIE DIE X - KOORDIANTE EIN:"))
YPOS = CLNG(INPUTBOX("BITTE GEBEN SIE DIE Y - KOORDIANTE EIN:"))
IF ISNUMERIC(XPOS AND YPOS) = TRUE THEN 
 XXX& = SETCURSORPOS(XPOS, YPOS)
ELSE
 MSGBOX ("FEHLER!!!!!!!!!!!!!!!!")
END IF

ENDE:
Hier wird eine Sprungmarke eingesetzt, um bei einem Fehler zu einem anderen Teil des Programms zu verzweigen. Hierauf werden die X - und Y - Koordinaten als Long - Datentyp dimensioniert. In zwei Eingabek├Ąstchen wird der Benutzer aufgefordert die gew├╝nschten Variablen einzugeben. Es folgt eine G├╝ltigkeits├╝berpr├╝fung mit dem Verkn├╝pfungsoperator AND. Sind nun beide eine g├╝ltige Zahl, so wird das Programm normal fortgesetzt und die API - Routine SetCursorPos kann aufgerufen werden (als Argumente werden ihr der X - und der Y - Wert ├╝bergeben). Ist dies nicht der Fall, so wird dieser Teil einfach ausgelassen und es geschieht nichts, au├čer dass eine Fehlermeldung ausgegeben wird.

Die Form LWInfo:
Diese Form ist wohl die komplexeste Form innerhalb meiner Programmes. Obwohl nur drei API - Routinen vorkommen, ist sie sehr komplex, da verschiedene Werte miteinander verkn├╝pft werden.

Der gesamte Code dieser Form befindet sich in einer einzelnen Prozedur, die aufgerufen wird, sobald die Form geladen wird.

DIM PFAD AS STRING
DIM DRIVETYP AS STRING
DIM DISKNAME AS STRING
DIM T AS STRING
LET X = VBCRLF

PFAD = LEFT$(UEBERGEBEL, 1) + ":\"

RESL& = GETDISKFREESPACE(PFAD$, LPSECTORPERCLUSTER&, LPBYTESPERSECTOR&, LPNUMBEROFFREECLUSTERS&, LPTOTALNUMBEROFCLUSTERS&)

IF RESL& = 0 THEN
 L_INFO = "FEHLER - - - - LAUFWERK NICHT BEREIT"
 EXIT SUB
END IF

BPC& = LPSECTORPERCLUSTER& * LPBYTESPERSECTOR&

PROZ! = LPNUMBEROFFREECLUSTERS& / LPTOTALNUMBEROFCLUSTERS&

‚LAUFWERKSTYP ERMITTELN
SELECT CASE GETDRIVETYPE(PFAD)
 CASE DRIVE_REMOVEABLE
 DRIVETYP$ = "AUSTAUSCHBARE WECHSELPLATTE"
 CASE DRIVE_FIXED
 DRIVETYP$ = "FESTPLATTENLAUFWERK"
 CASE DRIVE_REMOTE
 DRIVETYP$ = "NETZWERKLAUFWERK"
 CASE DRIVE_CDROM
 DRIVETYP$ = "CD - ROM (ISO 9660/JOLIET/DVD)"
 CASE DRIVE_RAMDISK
 DRIVETYP = "RAM - DISK - LAUFWERK"
 CASE ELSE
 DRIVETYP$ = "UNBEKANNT - ANDERER TYP"
END SELECT

‚LAUFWERKSNAMEN ERMITTELN
DISKNAME$ = STRING$(100, 32)
FILESYSTEMNAME$ = DISKNAME$
RESL& = GETVOLUMEINFORMATION(PFAD, DISKNAME$, LEN(DISKNAME$), SERIENNR&, MAXIMUMCOMPONENTLENGTH&, FILESYSTEMFLAGS&, FILESYSTEMNAME$, LEN(FILESYSTEMNAME$))

'NAMEN KAPPEN
DISKNAME$ = LEFT$(DISKNAME$, INSTR(DISKNAME$, CHR$(0)) - 1)
FILESYSTEMNAME$ = LEFT$(FILESYSTEMNAME$, INSTR(FILESYSTEMNAME$, CHR$(0)) - 1)

'DATEISYSTEM FLAGS AUSWERTEN
'UNICODE?
IF FILESYSTEMFLAGS& AND FILE_UNICODE_ON_DISK THEN
 FILESYSTEMNAME$ = FILESYSTEMNAME$ + " (UNICODE)"
END IF
'KOMPRIMIERT?
IF FILESYSTEMFLAGS& AND FILE_VOLUME_IS_COMPRESSED THEN
 FILESYSTEMNAME$ = FILESYSTEMNAME$ + " (KOMPRIMIERT)"
END IF

'VERSION
VERSIONX$ = STR(GETVERSION&)

'EINTRAGEN DER INFORMATIONEN IN DIE RECHTE SEITE
T = DISKNAME + X
T = T + STR$(SERIENNR&) + X
T = T + FORMAT$(FILESYSTEMNAME$, "#,0") + X
T = T + DRIVETYP$ + X + X
T = T + FORMAT$(LPTOTALNUMBEROFCLUSTERS& * BPC&, "#,0") + X
T = T + FORMAT$(LPTOTALNUMBEROFCLUSTERS& * BPC& / 1024, "#,0") + X
T = T + FORMAT$(LPTOTALNUMBEROFCLUSTERS& * BPC& / 1048576, "#,0") + X
T = T + FORMAT$((LPTOTALNUMBEROFCLUSTERS& - LPNUMBEROFFREECLUSTERS&) * BPC&, "#,0") + X
T = T + FORMAT$(LPNUMBEROFFREECLUSTERS& * BPC&, "#,0") + X + X
T = T + FORMAT$(LPTOTALNUMBEROFCLUSTERS&, "#,0") + X
T = T + FORMAT$(LPTOTALNUMBEROFCLUSTERS& - LPNUMBEROFFREECLUSTERS&, "#,0") + X
T = T + FORMAT$(LPNUMBEROFFREECLUSTERS&, "#,0") + X + X
T = T + FORMAT$(LPSECTORPERCLUSTER&) + X
T = T + FORMAT$(LPBYTESPERSECTOR&, "#,0") + X
T = T + FORMAT$(BPC&, "#,0") + X

L_INFO.CAPTION = T

Zu Beginn dieser Prozedur werden verschiedene Variablen dimensioniert, in welchen sp├Ąter die verschiedenen Werte abgelegt werden. Beim Aufruf der Form aus der Form DateiInfo wird der Form LWInfo auch ein Laufwerksbuchstabe mitgeteilt, der hier global ├╝bergeben wird (Variable "uebergebel"). Um diesen zu vervollst├Ąndigen, werden noch ein Doppelpunkt und ein verkehrter Schr├Ągstrich angeh├Ąngt (\). Somit "wei├č" das Programm nun, welches Laufwerk untersucht werden soll. Nun wird die erste API - Routine aufgerufen, der als Argument der Laufwerksbuchstabe (Pfad$) ├╝bergeben wird. Die Variablen die sie von der Funktion ├╝bernimmt werden in den Variablen lpSectorPerCluster (Sektoren pro Cluster), lpBytesPerSector (Anzahl der Bytes pro Sektor), lpNumberOfFreeClusters (Anzahl der freien Cluster) und lpTotalNumberOfClusters (Gesamtanzahl der Cluster - Einheiten) gespeichert. Es folgt eine ├ťberpr├╝fung, ob der Aufruf g├╝ltig war - ansonsten wird eine Fehlermeldung ausgegeben.

Es werden nun die Anzahl der Sektoren / Cluster mit der Anzahl der Bytes /Sektoren multipliziert, um die Anzahl der Bytes / Sektor zu ermitteln. Um eine Prozentanzahl zu erhalten, wird nun die Anzahl der Freien Cluster durch die Anzahl der gesamten Cluster dividiert. Mit Hilfe der API - Routine GetDriveType, der das Laufwerk als Argument ├╝bergeben wird, wird der Laufwerkstyp ermittelt (Festplatte, Diskettenlaufwerk, CD - ROM).

Um den Laufwerksnamen und ├Ąhnliche Informationen zu ermitteln, wird die dritte Routine ben├Âtigt. Sie lautet GetVolumeInformation und gibt als R├╝ckgabewerte den Namen des Laufwerks (und die L├Ąnge des Namens), die Seriennummer, Dateisystem - Flags (also Bytes, die verschiedene Eigenschaften der Dateisystems identifizieren), und den Dateisystem - Namen (ebenfalls die L├Ąnge) zur├╝ck.

Um einen String in passender L├Ąnge f├╝r das Dateisystem und den Namen zu erhalten, werden diese Variablen nun gekappt. Es werden genau soviel Zeichen verwendet, wie der R├╝ckgabewert liefert (VB Funktion Left$()). Hierauf werden die Dateisystem - Flags "dekodiert". Je nachdem, was f├╝r ein Wert zur├╝ckgegeben wird, wird entweder der String UNICODE (egal, ob Gross - oder Kleinschreibung) oder komprimiert an den Dateisystem - String angeh├Ąngt. Die Version wird schlu├čendlich mit einer kleinen API - Routine namens GetVersion() ermittelt. Schlu├čendlich werden noch die gesammelten Informationen formatiert (Format$) in das rechte Bezeichnungsfeld eingetragen. Das "X" ersetzt hierbei einen Zeilenschub (vbCrLf).
Das Modul Modul1.bas
Dieses Modul beinhaltet s├Ąmtliche API - Aufrufe, die f├╝r mein Programm von Bedeutung sind. Ich stelle an dieser Stelle nur zwei vor, die sich in ihrem Aufruf etwas voneinander unterscheiden. Auch beinhaltet dieses Modul die Typdefinitionen. All diese Informationen k├Ânnen direkt aus dem Microsoft API - Katalog kopiert werden. Dieser beinhaltet alle verf├╝gbaren API - Routinen und Typdefinitionen.
'LAUFWERKSBELEGUNG
DECLARE FUNCTION GETDISKFREESPACE LIB "KERNEL32" ALIAS "GETDISKFREESPACEA" (BYVAL LPROOTPATHNAME AS STRING, LPSECTORPERCLUSTER AS LONG, LPBYTESPERSECTOR AS LONG, LPNUMBEROFFREECLUSTERS AS LONG, LPTOTALNUMBEROFCLUSTERS AS LONG) AS LONG

Diese Funktion wird im Programm ben├Âtigt, um den Speicherplatz zu ermitteln. Mit der Variable lpRootPathName wird dem Programm mitgeteilt, welches Laufwerk untersucht wird. Diese Variable muss angegeben werden. Die restlichen Namen liefern Informationen wie z.B.: die Anzahl der Sektoren pro Cluster, die Anzahl der Bytes pro Sektor, die Anzahl der freien Cluster und die Anzahl der gesamten Cluster. Mit der Hilfe dieser Funktion kann die Gr├Â├če der Festplatte oder anderer Laufwerken angegeben werden.

'SYSTEM POWER STATUS - STROMRESSOURCEN
DECLARE FUNCTION GETSYSTEMPOWERSTATUS LIB "KERNEL32" (LPSYSTEMPOWERSTATUS AS SYSTEM_POWER_STATUS) AS LONG

Diese Funktion ermittelt die Akku - Informationen und speichert sie in der als SYSTEM_POWER_STATUS deklarierten Variable lpSystemPowerStatus.
Literaturverzeichnis:
Aitken, Peter G.: Visual Basic for Win95 Insider: The Guide to Hard - To - Find and Undocumented Features. 1. Auflage 1996
Appleman, Daniel: Visual Basic Programmer's Guide to the Win32 Api, 1. Auflage 1996
Heiligensetzer, Stefan / Monadjemi, Peter / Markt und Technik: Visual Basic - Das Kompendium. 1.Auflage M├╝nchen 1992
Hergert, Douglas A. / SYBEX Verlag: Visual Basic - Das Buch. 1.Auflage D├╝sseldorf 1992
L├Âffelmann, Klaus / V├╝llers Dieter / tewi - Verlag: Visual Basic 3.0 - Professional Edition. 1. Auflage M├╝nchen 1994
Maslo, Andreas / Verlag Data Becker: Visual Basic 5 - Das gro├če Buch. 1.Auflage D├╝sseldorf 1997
Monadjemi, Peter / SYBEX Verlag: Visual Basic ganz einfach. 1.Auflage D├╝sseldorf 1992
Steiner, Josef / Valentin, Robert / H├╝ckst├Ądt, J├╝rgen / Verlag Markt und Technik: Visual Basic 4. 1.Auflage 1996
tewi - Verlag: Visual Basic 4.0 - Das Buch. 1. Auflage 1996
Tischler, Michael / SYBEX Verlag: Visual Basic - Der Einstieg in 20 Schritten. 1.Auflage D├╝sseldorf 1991
Protokoll
August und Anfang September 97:
Sammeln von Informationen bez├╝glich des Themas "Visual Basic"
Anfang September:
Festlegen des Themas Visual Basic - API Programmierung
19.9.1997:
Abgabe des Anmeldungsformulars:
Pr├╝fungsgebiet: Informatik
Betreuender Lehrer: Prof. Walter RIGGER
Thema: Visual Basic - API Programmierung:
Oberfl├Ąche, Programmierung von Beispielprogrammen, Programmierung (mit Hilfe von Windows - APIs), Versionen der Programmiersprache Visual Basic, Vergleich mit JAVA und C / C++, Object Linking and Embedding (OLE); Selbst├Ąndig erstelltes Programm zur API - Programmierung
1.10.1997 - 2.10.1997:
Einleitung
Grundlegendes
Programm zur API Programmierung (Aufbau der Formen (Fenster))
4.10.1997:
Kapitel: Programmerstellung mit Visual Basic
Programm zur API Programmierung
5.10.1997:
Programmdesign mit Visual Basic (Namenskonventionen und Quelltextformatierung)
Die grafische Oberfl├Ąche
Programm zur API - Programmierung
6.10.1997 - 9.10.1997:
Kapitel: DDE und OLE
Programm zur API Programmierung
15. - 23.10 1997:
Kapitel: API: Aufrufen der Routinen, Multimedia - Funktion wurde in das Programm eingebaut
18.12.1997: Besprechung mit Herrn Professor Walter Rigger wegen des Programmes
Weihnachtsferien (24.12.1997 - 5.1.1998):
Fertigstellung des Beispielprogrammes
Kapitel: Deklaration von API - Routinen, Aufrufkonventionen
Kapitel Unterschiede bzw. Vor und Nachteile zwischen verschiedenen Programmierarten
Glossar, vollst├Ąndig abgedruckter Quellcode des Beispielprogrammes + Form als Text
9.1.1998: Besprechung mit Herrn Prof. Rigger bez├╝glich Inhalt: Wegstreichen eines Teils, Dokumentation des Programms nur teilweise vornehmen (wichtigste Passagen genau erkl├Ąren); Frage bez. Formatierung
12.1.1998 - 17.1.1998: Erkl├Ąrung des Inhalts der Formen: DateiInfo (Hauptform), ProzInfo, OSInfo, RamInfo und der Form SysInfo
24.1.1998: Erkl├Ąrung der Form: SmallDriveDir und GenInfo
25.1.1998: Erkl├Ąrung der Form LWInfo
26.1.1998: Erkl├Ąrung des Moduls
18.2.1998: letzte Besprechung mit Prof. Rigger wegen Abgabe


[1] Vgl. Appleman, David Visual Basic Programmer’s Guide to the Win32 API 1.Auflage 1996, Seite 20 - 25
[2] Vgl. tewi Verlag / Visual Basic 4.0 - Das Buch. 1.Auflage 1996, Seite 763 - 776
[3] Vgl. Appleman, David Visual Basic Programmer’s Guide to the Win32 API 1.Auflage 1996, Seite 37 - 39, 58 - 59
[4] Vgl. tewi Verlag / Visual Basic 4.0 - Das Buch. 1.Auflage 1996, Seite 897 - 899
[5] Vgl. tewi Verlag / Visual Basic 4.0 - Das Buch. 1.Auflage 1996, Seite 823 - 830
[6] Vgl. Appleman, David Visual Basic Programmer’s Guide to the Win32 API 1.Auflage 1996, Seite 1408 - 1418

10362 Worte in "deutsch"  als "hilfreich"  bewertet