Heute will ich den Umgang mit Sub-Routinen in AppleScript erläutern.

Im Kern war der AppleScript Code in den bisherigen Beiträgen immer von oben nach unten zu lesen, lief also ganz simpel der Zeilen-Reihenfolge nach ab. Dies wird sich nun ändern.

Im Kern sind Sub-Routionen in AppleScript ausgelagerte Funktionen auf die man jeweils mit einem simpeln Funktionsaufruf zugreift und dann jeweils nach Ablauf der Funktion zurück zum Aufrufort springt von wo das Script dann wieder nach dem alten Prinzip weiterabläuft.

Vorteile von Sub-Routinen:

Je länger der Code wird umso schwerer ist er im Regelfall auch zu verstehen (geht bei eigenem Code noch relativ gut bei ausreichender anzahl an Kommentaren -> ist bei Fremd-Code aber oft einfach ein Problem). Mittels Sub-Routinen lagert man Teilfunktionalität aus und hat so kleinere einzelne Bereiche.
Dies macht vor allem dann Sinn wenn man einen Code-Schnippel regelmäßiger innerhalb seinem AppleScript-Programm verwenden will.

Aber nun zur Umsetzung …

Einführung:

Fangen wir also mit einem Minimal-Beispiel an. Das folgende Script macht folgendes:
Es zeigt einen Dialog an der uns sagt, dass wir im Hauptprogramm teil sind, ruft dann unsere weiter unten definierte Funktion / Sub-Routine mySubRoutine auf, und springt zurück zum Programmablauf wo abschließend ein erneuter Dialog uns mitteilt dass wir wieder ausserhalb der SubRoutine sind. Klingt einfach -> ist einfach =)

Ok, nun mal die Minimal Sub-Routine im Detail. Die SubRoutine wird wie folgt definiert:

Und wie folgt aufgerufen:

Diese Minimal-Funktion ist stark limitiert. Weder geben wir aktuell beim Funktionsaufruf Werte mit an die Sub-Routine, noch gibt die Sub-Routine selber Werte zurück ans Hauptprogramm. Dies werden wir später ausbauen, keine Sorge.

Zu beachten ist noch folgendes:

Erfolgt der Funktions- / SubRoutine-Aufruf innerhalb eines Tell-Blockes (den ich bis dato leider noch nicht erklärt habe, kommt aber noch irgendwann hehe) gilt dies als Sonderfall.

Trifft dies zu müsste man die SubRoutine mySubRoutine nicht so aufrufen:

mySubRoutine()

sondern:

my mySubRoutine()

Dies hat nichts mit unserem Funktions Namen zu tun, sondern gilt für jeglichen Funktionsnamen (sofern diese eben innerhalb eines Tell-Blockes aufgerufen wird)

Ok, das wichtigste ist erklärt, also weiter im Konzept.

SubRoutine mit übergebener Variable:

Nun variieren wir obiges Beispiel und definieren eine Variable myTestVar mit einem beliebigen Text. Anschliessend rufen wir wieder unsere SubRoutine auf, übergeben jedoch beim Aufruf die Variable myTestVar mit an die Funktion. Innerhalb der SubRoutine geben wir diese übergebene Variable dann mit einem Dialog aus und kehren zurück zum normalen Programmablauf.

SubRoutine mit Rückgabe-Wert

Nun minimieren wir obiges Beispiel wieder um die Test-Beispiele auch klein zu halten. Dafür soll unser Code nun eine SubRoutine aufrufen welche einen Rückgabewert hat. Ein Blick auf den Code:

Der interessante Part ist hier klar … der Aufruf der SubRoutine und das Ergebnis.

Wir verwenden display dialog um einen Dialog zu erzeugen und rufen innerhalb dieser Zeile dann unsere SubRoutine auf. Da die SubRoutine mittels return einen Wert zurückgibt haben wir für den display dialog einen anzuzeigenden Inhalt. Der Rest sollte selbsterklärend sein, wenn nicht einfach nachfragen.

 

Das wars dann erstmal wieder von mir, ich hoffe Lektion 7 war hilfreich.

Es gibt verschiedene Wege die Icons in Mac OS X zu ersetzen. Da ich heute selbst über ein Problem in diesem Kontext gestolpert bin werde ich nochmal kurz darauf eingehen.

Eumel blogte hier gestern über ein schönes neues Icon-Set namens Pry Systems. Nach kurzem Blick auf die Icons kam bei mir der Haben-Reflex und ich hab mir die 42 MB Icons heruntergeladen.

Also erstmal LiteIcon gestartet um die Haupt-Icons meiner 10.5 Installation abzuändern. Dies funktioniert wie immer mit LiteIcon sehr stressfrei.

Zu LiteIcon:

LiteIcon starten und man sieht in etwa dieses Bild

Nun kann man seine Wunsch-Icons aus dem Finder einfach direkt auf die entsprechenden Felder ziehen und abschließend mit Apple die Änderungen wirksam machen. Es bietet sich an um Probleme zu umgehen einmal via Logout bzw Reboot (ne danke) die Änderungen zu forcieren.

Spätestens zu diesem Zeitpunkt sollten die mit LiteIcon neu definierten Icons aktiv sein.

Im nächsten Schritt will man ggf. eigens definierte Ordner mit Custom Icons versehen typischerweise macht man dies mittels folgendem Ansatz:

Icons via Get-Info Dialog ändern:

Man selektiert das neue Wunsch-Icon im Finder und öffnet den Get-Info Dialog. Dies sollte in etwa so aussehen:

und in so einem Resultat enden:

Anschliessend vollzieht man die gleichen Schritte beim zu ändernden Ordner und hat damit folgendes Bild (links mein Desktop Icon und Rechts das neue Desktop-Wunsch-Icon) :

Nun selektiert man im rechten Dialog das Icon des neuen Wunsch-Icons und kopiert (APPLE+C) dieses. Die Markierung sollte mit einer blauen Umrandung visualisiert werden wie im folgenden Bild:

Anschliessend selektiert man das Icon im linken Dialog (unser Ziel) und fügt das zuvor kopierte Icon mittels APPLE+V ein. Man sollte gleich sehen dass sich das Icon unseres Ziel-Ordners ändert.

Im Normalfall war es das schon, einfach und funktioniert.

Eventuelle Probleme:

Im Falle des Pry Systems Icon Set hatte ich jedoch ein kleines Problem. Die Icons sind zwar wunderbar / schön, zeigen im Get-Info Dialog aber nicht das angedachte Icon, sondern nur eine dumme nicht helfende Vorschau, die man natürlich nicht in seinen Ziel-Ordner reinkopieren will.

Der Get-Info Dialog der Pry-Systems Icon sieht bei mir jeweils so aus:

obwohl er eigentlich so aussehen sollte:

Dieses Problem läßt sich mit dem freien Programm ICNS2ICON erschlagen. Dazu einfach das Tool runterladen und das “zu reparierende” ICNS File auf das laufende Programmsysmbol von ICNS2ICON ziehen (gute alte Droplet Manier also).

Anschliessend sollte das .ICNS File korrekt dargestellt werden und auch für die Icon-Wechsel-Variante via Get-Info brauchbar sein.

Ich hoffe der Beitrag klärt eventuelle Probleme. Viel Spass mit euren neuen Icons.

Links:

• Icns2Icon
• Pry System Icon Set
• Icon Beitrag by Eumel

Dies ist der dritte Beitrag der Serie “Getting started mit AppleScript” und befasst sich thematisch erneut mit “display dialog”.

In den vorherigen Beiträgen wurden Dialoge erzeugt und mit Grundeigenschaften wie Fenster-Titel (title), Anzeige-Dauer (giving up after X) sowie Knöpfen versehen.

Zielsetzung Lektion III:

Aufzeigen zusätzlicher Möglichkeiten im Rahmen der Verwendung von Display Dialog. Aufzeigen der Limitierungen bei reiner Verwendung vom Script Editor.

Praxis:

Fangen wir mit einem leeren Dokument an und füllen erstmal einige Grundkommentare ein, damit klar wird wer hier was macht.

Erzeigen wir nun mit den Mitteln aus Lektion II einen Dialog mit 2 Knöpfen

Nun wollen wir natürlich die Antwort auch verarbeiten, daher müssen wir prüfen was der User geklickt hat. Dazu fürge ich in diesem Fall einfach 2 IF-Prüfungen ein, die jeweils nur prüfen ob es sich bei der Antwort um ein JA oder NEIN gehandelt hat.

Dies könnte man auch mit einer geschatelten if-else Konstruktion machen, ich ziehe hier 2 einzelne Prüfungen vor um das Beispiel klein und nachvollziehbar zu machen. Lektion II arbeitete bereits mit geschachtelten Prüfungen.

Zum aktuellen Zeitpunkt alles sehr simpel, jedoch auch sehr eingeschränkt, da der User nut vorgefertigte Antworten geben kann. 

Stellen wir uns vor wir wollen diesen Dialog mitbrauchen um das Alter des Users zu erfragen. Wollen wir nun 100 Buttons in den Dialog einfügen und diese wiederrum prüfen ?

Nein, würde auch mit den Dimensionen eines Display Dialog Fensters nicht wirklich spassig sein.

Wir bauen unseren Display Dialog also um, so dass der User zwar weiterhin 2 Knöpfe hat, nämlich um den Dialog abzuarbeiten oder abzubrechen. Ich habe den Code zum vorherigen Schritt wieder vereinfacht um alles klein zu halten

Der folgenden Code stellt und also nur die Frage ohne Eingabemöglichkeit, abgesehen von unseren 2 Grund-Buttons:

Nun benötigen wir ein zusätzliches element in unserem Dialog-Fenster um dem User die Möglichkeit zu geben uns zu antworten. Dies ist relativ einfach aber auch gleichzeitig eingeschränkt möglich. Zu den Einschränkungen später mehr.

Wir modifizieren unseren Display Dialog mit dem Zusatz “default answer”. Um den Dialog gleichzeitig auch noch etwas hübscher zu gestalten zeigen wir auch noch ein Icon an. Die Verwendung von “default answer” fügt dme Dialog automatisch ein Textfeld hinzu welches wir mit der ebenso neuen Variable “myDefaultAnswer” befüllen um einen VorgabeWert zu haben. 

Der Code sollte in etwa so aussehen:

So Zeit das ganze mal in Action zu sehen -> daher im Script Editor “Compile” und dann “Run” betätigen. Das Ergebnis sollte wie folgt aussehen:

Nun gut … sieht doch schon besser aus wie bisher. 

Im folgenden werden wir die Antwort des Benutzers verarbeiten. Dafür müssen wir im Kern 2 Sachen prüfen. Einerseits welchen Knopf der User gedrückt hat und als Unterfall die Prüfung des Wertes im Textfeld.

Eine einfache Variante würde so aussehen. Bitte beachten dass die unteren Zeilen nur zum ersten Test da sind.

Nun könnte man das ganze mit Hilfe einer verschatelten IF-Konstruktion wieder in einen logischen Ablauf zwängen.

Ablauflogik:

Drückt der Anwender “Abbrechen” zeigen wir einen Fehler-Dialog. Entscheidet sich der User jedoch den Dialog mit “Ok” zu beantworten, geben wir seine Antwort aus.

Eh voila, wir haben einen Dialog, der uns User-Eingaben ermöglicht und das ganze auch noch passend mit Icons untermalt. Die verwendeten Icons sind die Default Icons im Script Editor (icon 0 / icon 1 …).

Ich denke die Grundmöglichkeiten sind ausreichend gezeigt, daher werde ich abschließend auf die Einschränkungen eingehen.

Einschränkungen:

Script Editor ist relativ gut zum testen kleiner Scripte jedoch kommen wir schon hier so langsam an die Grenzen der reinen Script Editor Verwendung. Wir können die Dialog-Fenster nicht bis ins letzte Detail unseren Vorstellungen anpassen.

Um z.b. ein wirklich inidivduell gestaltetes Fenster zu verwenden müssen wir uns dieses im Interface Builder basteln und dann darauf via AppleScript zurückgreifen.

Auch die Verwendung von Icons empfand ich bei meinen Test sehr eingeschränkt, weshalb ich selber auch relativ fix zu Xcode gewechselt bin, einfach um mehr Möglichkeiten zu haben.

Um diese Einschräkungen mal deutlich zu machen hier ein Screenshot eines Fensters welches ich mit dem Interface Builder erstellt habe. Es zeigt sehr gut dass die Gestaltung des Fensters und die Anzahl an grafischen Elementen so sehr vielseitig ist und bei weitem flexibler wie nur mit dem Script Editor an sich.

Der Screenshot zeigt das Interface eines kleinen Spieles (YaDoWa) welches ich aktuell zum AppleScript lernen bastel. Mehr dazu bald hier in diesem Blog.

Über Interface Builder:

Der Interface Builder ist Teil der XCode Tools welche Apple frei anbietet. Allgemein ist zu sagen dass man damit relativ einfach User-Interfaces basteln kann welche man dann z.b. via AppleScript ansprechen kann. Die XCode Tools sind auf der Mac OS X Installations-CD enthalten oder direkt bei Apple downloadbar, jedoch nur wenn man sich einen kostenlosen ADC-Account erstellt. Die Ergebnisse im Interface Builder werden üblicherweise als .NIB gespeichert.

 

Abschließend:

Ich hoffe dieser dritte Teil hat den Umgang mit Dialogen weiter erleichtert. Wer Fragen oder Anregungen hat ist im Kommentar-Bereich herzlich willkommen.

Ich habe mich entschlossen ab Teil II keinen AppleScript Code direkt in Text-Form einzubinden, einfach um nicht alles vorzukauen und auch etwas Notwendigkeit für Eigeninitiative zu forcieren. Selber tippen ist immer besser wie reines Copy & Paste. Denke die Screenshots zeigen alles notwendige.

Die nächste Folge wird sich dann mit dem Umgang mit Strings beschäftigen, damit wir mal von reinen Dialogen wegkommen.

Bis dahin weiterhin Viel Spass beim Scripten

Links:

• Wikipedia über Interface Builder (englisch & umfangreicher)
• Wikipedia über Interface Builder (deutsch)
• Apple XCode Tools
• Apple Interface Builder
• Apple NIB Doc

Based on a post on macosxhints.com

While lookupd was existing & working in 10.4 to clear DNS Cache the command was replaced in 10.5 with:

dscacheutil

So now you can flush your DNS cache with

dscacheutil -flushcache

Here the link to the matching post for Tiger / 10.4

Found a nice hint for all cli-lovers on OSXDaily.com

Quote from the article:

Quick Look is a nice feature added in 10.5, I use it often for glancing at the content of various documents and it certainly beats launching an application. If you’re an avid command line user though, you may be browsing through a directories contents and wondering just what is that JPG or DOC file. Wonder no more, because you can easily use Quick Look from the command line:

From the command line, use the following syntax:

qlmanage -p filename.jpg

This will launch a Quick Look window with whatever file is specified as ‘filename.jpg’, the file type can be anything that Quick Look is compatible with (which seems to be just about everything).

Some weeks ago i tested the package macfuse & fink’s ntfs-3g to get a basic write-support for OSX working on my Mac Pro.

Today lets do it much easier and much better

Get yourself the following packages:

• MacFuse 0.4
• NTFS-3G.dmg

Install MacFuse first, then install the ntfs-3g package. Reboot your mac.

If you have an NTFS-partition connected to your mac you will recognize some small changes:

• Icon changes from default HDD-Icon to Network-device-Icon
• You should have read & write support now on that drive

Big thanks to the MacFuse project and for sure to those guys from the ntfs-3g project.

The big advantage to my first attempt is clear and easy:

• Less installation trouble (i.e.fink is not needed)
• Drives are auto-mounted with ntfs-3g driver

Nice