Die Gruppe der #SPI:'s sind ja eigentlich keine Befehle sondern Direktiven für den Compiler.
Das erkennt man daran, dass diese stets mit einem Kommentarzeichen anfangen.
Und daher werden diese "Befehle" bzw. Direktiven vom eigentlichen, ausführenden "Robot" stets ignoriert.
Aber wozu sind sie dann gut?
Sie dienen dazu die EXE die man mit "Compile" erstellen kann, zu verändern.
Eines der undokumentierten Features ist hier
Code: Select all
#SPI:NoMutex
Ein MUTEX ist ein "Ding" das beim Start einer Datei geprüft werden kann, um zum Beispiel festzustellen, ob diese Datei bereits läuft. Das ist nützlich, denn eine automatische Installation will man ja nur ein mal starten, und nicht noch ein zweites Mal.
Da geht es darum, daß man ja mit dem MPR auch zum Beispiel Help-Desk-Skripte machen kann.
Nun sendet man dem User so ein Skript - zum Beispiel über ein "shared Drive".
Und der User startet das Skript lokal.
Das ist kein Problem, denn MPR-Executables können ja auch Ihre eigenen Admin-Rechte mitbringen (via in der EXE verschlüsseltes Passwort). So ein Skript kann zum Beispiel die Druckerumgebung reparieren.
Dann muß der Helpdeskmitarbeiter nicht von 100 Supportfällen 80 Mal das Gleiche machen.
Nun sind User ungeduldig. Und starten das automatische Support-Skript (also die EXE).
Aber die entpackt sich erst und so passiert nicht sofort etwas. Aber User sind ungeduldig.
Sie wissen ja nicht was da alles im Hintergrund passiert.
Also klicken die User noch Mal und nochmal ... und am Ende würde das Skript dann 5 Mal laufen!
Damit das nicht passiert hat jede MPR-Exe automatisch ein "Mutex".
Wenn man also ein Skript das bereits läuft noch mal starten will, dann hört man nur ein "Bing" (Systemsound).
Das bedeutet, dass der MUTEX den erneuten Start des bereits laufenden Skriptes verhindert hat. Alles Gut.
In seltenen Fällen kann es nun sein, daß man ein Skript mehrfach starten will.
Zum Beispiel ein Backup-Skript mit Parametern, was wohin gesichert werden soll.
In diesem Fall gibt man dann einfach das
Code: Select all
'#SPI:NoMutex
Und dann kann man das gleiche Skript beliebig oft starten!
Ein weiteres aktuell nicht dokumentiertes SPI: ist das
Code: Select all
'#SPI:ForceUpdate
Code: Select all
'#SPI:ForceWrite
Das
Code: Select all
'#SPI:ForceUpdate
Man kann jedoch alle Arten von Dateien in so eine EXE-Paket einpacken bis zur maximalen Dateigröße für EXE-Dateien von 2 Gigabyte.
Meistens hat man die für eine Installation benötigten Dateien in "?path\" das ist der Projektordner.
Also der Ordner den wir bei der Erstellung des Skripts für alle benötigten Dateien verwenden.
Da liegt auch das eigentlich Skriptfile drin.
Im Zielsystem ist unser Projektordner jedoch nicht vorhanden, also muß er zunächst von der EXE dort nachgebaut werden.
Dann kann das Skript dort 1:1 - wie in der Testumgebung - laufen.
Das geschieht normalerweise in einem neuen Unterordner im TEMP-Ordner. Weil das fix eingebaut ist muß man sich darum nicht kümmern.
Man kann jedoch auch Dateien an beliebigen Stellen auf dem Ziel-PC ablegen.
Und zwar schon beim Entpacken des Skriptes. Dazu gibt es die
Code: Select all
'#INC:[?path\Dateiname.xyz]->[Zielpfad]
Nur, was passiert nun wenn auf dem Zielsystem die Datei bereits vorhanden ist?
Dann kommt eine manuelle Messagebox. Die fragt dann was sie tun soll.
Das will man aber in der Regel nicht. Und hier kommt nun das
Code: Select all
'#SPI:ForceUpdate
Und last not least kann man mit:
Code: Select all
'#SPI:Diskfree=<Zahl> (MB)