Die VISTA-TCAD-Shell arbeitet grundsätzlich ereignisgesteuert. Das Basiskonzept der Implementierung geht aus der Generalisierung des Callback-Konzepts des X Window Systems [Sch88] hervor. Dort werden besondere Prozeduren, die Callback-Funktionen, einem bestimmten Ereignis über sogenannte Callback-Listen zugeordnet. Tritt dieses Ereignis ein, etwa wenn der Benutzer mittels Maus einen Kommandoknopf drückt oder ein Fenster am Bildschirm verschiebt, so werden die zugeordneten Callback-Funktionen aufgerufen. Die Callback-Funktionen müssen bestimmte Kriterien erfüllen, die am einfachsten in der Form eines C-Prototyps darzustellen sind [Nye90]:
XtCallbackProc callback_function(
Widget w,
XtPointer client_data,
XtPointer call_data);
Eine Callback-Funktion hat keinen Rückgabewert (der Datentyp
XtCallbackProc entspricht void) und genau drei Parameter:
, der die Callback-Liste gehört, in der die
Callback-Funktion registriert ist.
Innerhalb der Callback-Funktion gibt es keinerlei Einschränkung der gültigen exekutierbaren Anweisungen, insbesondere dürfen weitere Callback-Funktionen aufgerufen und Ereignisse im X Window System ausgelöst werden. In [McC91] wird es als Frage des guten Programmierstils bezeichnet, in den Parametern client_data und call_data generell nicht zuviel an Information unterzubringen. Statt über allzu komplexe Strukturen wird dort der Datenaustausch über einzelne Variablen empfohlen.
In einem wichtigen Schritt der Abstraktion werden Callback-Funktionen in der TCAD-Shell nicht auf die Anbindung des X Window Systems beschränkt. In völliger Analogie wird das Callback-Konzept etwa in der Subprozeßverwaltung eingesetzt. Auf die Shell-Implementierungssprache LISP übertragen, entspricht der C-Prototyp etwa folgendem Prozedurkopf:
(callback_function caller_identifier
client_data
call_data)
In LISP wird einer Variablen kein fester Datentyp zugeordnet, sondern
dynamisch nach dem ihr zugeordneten Wert bestimmt [Win89].
Daher gibt es auch bezüglich des Datentyps des ersten Parameters
caller_identifier keine Einschränkung.
Der Aufrufer der Callback-Funktion kann sich als
Widget, Prozesses oder Queue-Eintrag identifizieren.
Ebenso gibt es keine Einschränkungen des Datentyps für client_data
und call_data.
Eventuelle Fehler im Datentyp der Aktualparameter können allerdings erst
bei der Ausführung erkannt werden. Das Fehlen der Kompilierphase mit den
strengen Typüberprüfungen (z.B. wie in ANSI-C) kann die Fehlersuche,
zumal in einer ereignisgesteuerten Programmierumgebung, sehr langwierig
werden lassen.
Anhand zweier einfacher Beispiele soll die Funktion des Callback-Konzepts erläutert werden: Es sei vom Benutzer ein Zahlenwert über ein kleines Fenster mit dem entsprechenden Widget abzufragen. Dem Widget wird beim Kreieren eine Callback-Funktion zugeordnet und als client_data der Name der Variablen definiert, in der der eingegebene Zahlenwert abgespeichert werden soll. Verläßt der Benutzer später mit dem Mauszeiger das Eingabefeld, löst dieses Ereignis die Ausführung der Callback-Funktion aus. Die drei Parameter sind der Zeiger auf das Widget, der Variablenname und der aktuelle Zahlenwert. Als client_data wird also Information an die Callback-Funktion weitergereicht, die zum Zeitpunkt der Registrierung feststeht, während call_data das auslösende Ereignis näher beschreibt.
Als Beispiel aus der Subprozeßverwaltung sei die punktweise Berechnung einer Strom-Spannungs-Kennlinie mit einem Bauelementsimulator als Subprozeß angeführt. Jedem Simulatoraufruf wird dieselbe Callback-Funktion zugeordnet, jedoch ein verschiedenes client_data, nämlich die Spannung für den Arbeitspunkt. Das Ereignis ,,Beendigung des Subprozesses`` löst die Ausführung der Callback-Funktion aus. Die drei Parameter sind ein Identifikator des Subprozesses, der Spannungswert und der vom Simulator errechnete zugehörige Stromwert. Die Aufgabe der Callback-Funktion ist es demnach, das Strom-Spannungs-Wertepaar in eine die Kennlinie darstellende Struktur einzutragen und die Kennlinie anzuzeigen.