Einführung in Ressourcenskripte


Ressourcenskripte sind normale Textdateien, die beliebig viele Ressourcendefinitionen und Kommentare enthalten können.
Ein Kommentar wird C-üblich entweder durch doppelte Forward-Slashes (//), für einen einzeiligen Kommentar, oder durch einen Forward-Slash, der mit einem Sternchen kombiniert ist (/* ... */), für Kommentarblöcke, dargestellt.

Eine Ressourcendefinition hat folgende Syntax:

id RESOURCETYPE [Liste von Parametern] [Liste von Statements]
{
  [Control-Definitionen]
}

Die id ist entweder ein Integer zwischen 0 und 65535 oder ein String, der den Namen der Ressource angibt. Faktisch gesehen handelt es sich bei den Integer-Werten aber auch um Strings, die jedoch in ihre (kürzere) binäre Zeichenform umgewandelt werden (sie verbrauchen daher im Endeffekt weniger Speicher in der fertigen EXE-Datei). Dadurch müssen sie bei ihrer Verwendung mit Hilfe des Makros "MAKEINTRESOURCE" entsprechend konvertiert werden; beispielsweise

CreateDialog(hInstance,
  MAKEINTRESOURCE(100),  // entspricht '100'
  0,
  @dlgfunc);


RESOURCETYPE ist einer der 15 Ressourcentypen, u.a. DIALOG, MENU, STRINGTABLE und einige weitere. Hier gilt das gleiche wie beim Identifier. Anstelle des Klarnamens können Sie auch numerische Werte benutzen. Ein gutes Beispiel ist der Wert 24 für das mittlerweile häufig benutzte Manifest von Windows XP. Sinnvoll ist das, wenn Ihr Ressourcencompiler etwas älter ist und daher mit einem Begriff wie MANIFEST o.ä. nichts anfangen kann.

Die Liste der Parameter ist abhängig vom Typ der Ressource. Bei Dialogen hat man die Position und die Höhe und Breite des Fensters, beim Bitmap nur den Dateinamen.

Die Liste der Statements ist nicht bei jeder Ressource und auch nicht immer vollständig verfügbar. Welcher Ressourcentyp welche Statements unterstützt, steht im SDK. Einiges ist aber auch logisch, so macht bei einem Bitmap ein CAPTION-Statement nicht sehr viel Sinn und wird deswegen nicht erlaubt. Auch wenn man alle Statements in einer Zeile hintereinander schreiben kann, erhöht es doch die Lesbarkeit erheblich, wenn man nach jedem Statement jeweils eine neue Zeile anfängt. Den Compiler stört das überhaupt nicht.

Die Control-Definitionen sind immer in geschweiften Klammern (alternativ auch BEGIN und END) eingeschlossen und können beliebig viele weitere Definitionen enthalten. Jede Definition geht bis zum Ende einer Zeile, dementsprechend kann auch immer nur eine Definition pro Zeile stehen. Einige Ressourcen, wie z.B. ICON oder BITMAP, akzeptieren jedoch keine Controls.
Eine Control-Definition wiederum hat folgende Syntax:

CONTROLTYPE [text,] id, x, y, width, height [, weitere Parameter]

CONTROLTYPE gibt den Typ des Controls an, z.B. LTEXT für einen statischen, linksbündigen Text oder PUSHBUTTON für einen Button.
text gibt die Caption des Controls an. Der Text muss in doppelten Anführungszeichen stehen und entsprechend der C-Syntax escaped, also Sonderzeichen für den Compiler entsprechend markiert, werden. Beispielsweise muss ein "\" also entsprechend "\\" geschrieben werden. Ein Kaufmannsund (&) vor einem Buchstaben kennzeichnet diesen als "Mnemonic", also als Tastenkürzel. Der Buchstabe wird automatisch unterstrichen. Beachten Sie bitte, dass nicht jedes Control eine Caption hat!

Die id ist der Identifier des Controls, der bei Notify-Messages zur Identifikation übergeben wird oder bei Funktionen wie "SetDlgItemText" übergeben werden muss.

x, y, width und height geben die Position und die Maße des Controls an. Diese werden nicht in Pixeln, sondern in Dialog Units angegeben, die ich im nächsten Kapitel erklären werde. Beachten sie auch hier, dass es Ausnahmen gibt, die keine Position- und Größenangaben akzeptieren, wie z.B. Strings aus einer STRINGTABLE-Ressource.

Die weiteren Parameter sind optional und Control-abhängig. Die meisten unterstützen eine HelpID oder verschiedene Styles (die übrigens genauso definiert sind wie die Windows-Styles).