So umfangreich die Funktionen in mAirList auch sind, so fehlt doch immer wieder mal das eine oder andere Feature für den gewünschten Zweck. Macht aber nichts, denn genau hierfür gibt es die Scripting-Engine, mit welcher die Möglichkeiten in mAirList noch wesentlich umfangreicher werden als ohnehin schon. Also:
Scripting ganz von vorne: Wie schreibe ich Code?
mAirList verfügt über ein recht geniales Werkzeug, um verschiedene Funktionen, die „ab Werk“ zunächst gar nicht vorgesehen sind, seien es blinkende Schaltflächen oder verschiedene Arten der automatisierten Playlistbearbeitung, verwirklichen zu können:
Die Scripting-Engine.
@Torben beschrieb sie hier mal so:
Damit wir aber in dieses Loch überhaupt rein-, geschweige denn durchgucken können, müssen wir (leider) ein Programm schreiben!
Halt! Bitte weiterlesen! So schlimm ist es nämlich gar nicht, wenn man
- ein wenig logisch denken kann und
- ein paar Grundregeln beachtet.
Nummer 1 kann ich Euch nicht beibringen. Nummer 2 schreibe ich hier nieder bzw. fange damit an:
Das eigentliche Programm besteht aus Code. Dies sind Wörter, Zahlen und Buchstaben in einer Sprache, die der Rechner verstehen kann. Die müssen wir erstmal lernen. Ich schicke allerdings voraus: Dies ist kein Hexenwerk! Denn diese Sprache ist so gestaltet, daß auch Menschen sie verstehen können. (Zumindest, wenn sie mindestens mäßig gebildet sind.) Sie heißt Pascal und die Programmierumgebung Delphi. Das gute an der Sache: Wir brauchen von der Pascal-und-Delphi-Gesamtheit nur einen Bruchteil zu kennen, den Rest besorgt @Torben bei sich im Büro.
Der Code wird einfach mit dem Texteditor Eurer Wahl eingetippt und als reine Textdatei unter einem passenden Namen gespeichert – allerdings nicht mit .txt hinten, sondern mit der Endung .mls (mAirList-Skript). Eine nichtproportionale Schriftart ist unbedingt zu empfehlen, der Übersicht halber. In diesem Sinne empfiehlt es sich auch, den Code durch Zeilenumbrüche und Einrückungen zu strukturieren. An und für sich könnte man, Leerzeichen und Zeilenumbrüche werden nämlich bei der Ausführung ignoriert, auch alles in eine einzige Zeile schreiben. Dann aber viel Spaß beim nachvollziehen, was man geschrieben hat, insbesondere wenn der Code nicht geht!
Das Einrücken bitte nur paarweise mit Leerzeichen (nicht mit Tabs) vornehmen, damit der Code auf jedem Editor oder Browser schön lesbar ist. Groß- und Kleinschreibung spielt (zumindest in Windows-Umgebungen) keine Rolle. Auch damit läßt sich Struktur in den Code bringen. Wie das genau aussieht, zeigt ein Beispiel unten.
Kommentare kann man zwischen geschweifte Klammern setzen,
{ Dieser Text wird ignoriert. }
oder zwischen „besternte Klammern“ (oder wie immer man das nennt),
(* Dieser auch. *)
oder innerhalb einer Zeile mit zwei Schrägstrichen hintereinander:
// Alles hinter den Schrägstrichen wird ignoriert.
Damit Ihr (oder andere) auch später noch versteht, was Ihr da zusammenprogrammiert habt, ist eine gewisse Anzahl solcher Kommentare außerordentlich hilfreich!
Hinter einer Anweisung, das ist gewissermaßen ein Befehl an die Maschine, steht immer ein Semikolon!
<Anweisung>;
Damit weiß der Rechner, daß gleich etwas neues kommt. Mehrere Anweisungen, die der Rechner als eine einzige behandeln soll, werden zwischen
begin
und
end;
zusammengefaßt. Aha: Schon wieder ein Semikolon, hinter dem end! Das steht da fast immer, und es gibt nur ganz wenige Ausnahmen davon. (Dann allerdings darf es auch nicht stehen. *seufz* Na ja, „dat kriejen mer später.“)
Das Programm an sich wird übrigens auch zwischen
begin
und
end.
eingepackt. Aber Achtung: Hinter diesem (und einzigen) end steht ein Punkt!
(Delphi ist eigentlich recht gutmütig zu programmieren, reagiert aber auf diese Semikolon-Syntax ziemlich pingelig. Das ist aber in Ordnung so, denn wir Menschen sind genauso: Stellt Euch mal diesen Beitrag ohne Punkte und Kommata vor – na, Mahlzeit!)
Bevor das Programm tatsächlich beginnt, werden noch einige Vereinbarungen getroffen und in den Code geschrieben: Variablen und Konstanten werden eingeführt („deklariert“), die bekommen die Überschrift
var
bzw.
const
und kriejen mer auch später. Außerdem Prozeduren und Funktionen, die stehen der Reihe nach unter
procedure EinProzedurenName(<mit Variablen drin>);
Aber die kommen erst noch viel später. Zumindest, wenn wir selber welche bauen wollen.
Damit Ihr einen Eindruck von einem solcherart strukturierten Programm bekommt, zeige ich hier mal eines:
{
Zwischen die geschweiften Klammern kann der Spickzettel hin, z.B.:
1: SWR, 2: HR, 3: RIAS.
4: NDR, 5: RB; 6: ORF
usw.
}
const
iMax = 15; // Hier die maximale Senderanzahl minus 1 einsetzen.
var
i: integer;
Stream: array[0 .. iMax] of boolean;
procedure SetConnectionEnabled(Index: integer; State: boolean);
begin
Encoder.GetConnections.GetItem(Index).SetEnabled(State);
if State then
ExecuteCommand('BUTTON.' + IntToStr(Index) + ' ON')
else
ExecuteCommand('BUTTON.' + IntToStr(Index) + ' OFF');
end;
begin
for i := 0 to iMax do
case i of
1, 5, 8..12, 14 : // Hier aufzuschaltende Sender durch Kommata getrennt eintragen.
Stream[i] := true;
else
Stream[i] := false;
end;
for i := 0 to iMax do
SetConnectionEnabled(i , Stream[i]);
end.
Was dieser Code im einzelnen bewirkt und wie er das macht, sei hier nicht Gegenstand der Beschreibung. Das ist bzw. wird (so habe ich es zumindest vor) in anderen Posts unter dem Titel Scripting-Hilfe erklärt.
Eine administrative Anmerkung sei mir noch gestattet: Falls Ihr hier im Forum Code posten möchtet, so tut das doch bitte auch als Code markiert. Zum Beispiel mittels der Schaltfläche [\] oben in der Formatierungsleiste des Editors im Browser. Oder mittels vier vorangestellter Leerzeichen zu Beginn der Zeile. Oder durch drei Accents graves in je einer Zeile vor und hinter dem Code. Tut Ihr das nicht, dann wird die Schriftart proportional, also schwerer zu lesen und, wichtiger, die superschlaue Forensoftware nimmt Umformatierungen vor, die nach Copy & Paste in Euren eigenen Code nur Unsinn erzeugen.
So, jetzt habt Ihr das Rüstzeug, also gewissermaßen die liniierte Kladde und den Schreibstift, also kann es losgehen! Bis dahin
strukturierte Grüße
TSD
Nachtrag: Wann schreibt man denn nun ein ; hinter dem end und wann einen .?
Grundsätzlich steht der Code im Hauptprogramm zwischen begin und end. (mit Punkt). Delphi läßt es aber zu, daß auch schon in den Prozedur- und Funktionsaufrufen (das sind die, die zwischen der Variablendeklaration und dem Hauptprogramm stehen – siehe oben) Code laufen kann. Und so wird das bei den Hintergrundskripts in mAirList auch gehandhabt. In diesem Falle steht der Code hinter der entsprechenden Prozedur zwischen begin und end; mit Semikolon.
Da aber kein Code ohne Hauptprogramm läuft (selbst, wenn man es gar nicht braucht!), muß hinter diesen Skripts immer noch das
begin
end.
(mit Punkt) stehen, obwohl es immer so dämlich überflüssig aussieht.
Würde man aus mAirList heraus ein Skript aufrufen wollen (z. B. mit dem befehl RUNSCRIPT <Pfad zur .mls-Datei>) so schriebe man den Code dort in der Regel zwischen begin und end. mit Punkt.
Damit sieht die gesamte Struktur des Codes so aus:
const
<hier werden Konstanten definiert, die für das ganze Skript gelten>;
var
<und hier Variablen>;
procedure Prozedur1(<Variablen nur für die Prozedur>);
begin
<Code der Prozedur1>;
end; // <-- mit Semikolon
procedure Prozedur2(<hat auch Variablen>);
begin
<Code der Prozedur2>;
end; // <-- mit Semikolon
…
function Funktion1(<Variablen für die Funktion>): <Ausgabewert>;
begin
<Code der Funktion>;
end; // <-- mit Semikolon
…
begin
<Code des Hauptprogrammes (oder auch nicht)>;
end. // <-- mit Punkt!
Anmerkung dazu: Funktionen sind in mAirList eher selten – was nicht heißen soll, daß sie gänzlich überflüssig sind.
