Dies ist die älteste Changed-Message. Sie wird von vielen Applikationen - vor allem aus dem Freeware- und Shareware-Bereich - unterstützt, und mittlerweile ziehen auch kommerzielle Anwendungen nach.
Die GEM-Message SC_CHANGED sollte von einer Applikation an alle anderen im System erreichbaren Applikationen verschickt werden, nachdem am Klemmbrett Änderungen vorgenommen wurden. Unter alten TOS-Versionen kann dafür z.B. ein geeignetes Protokoll (XAcc/AV) verwendet werden, unter MultiTOS und kompatiblen Betriebssystemen benutzt man dazu appl_search() oder (besser) schickt ein AES-Broadcast per shel_write(7,...). Die Nachricht ist wie folgt aufgebaut:
msg[0] = SC_CHANGED $0050 (80)
msg[1] = apID
msg[2] = 0
msg[3] = Bitmap des Dateiformats (s.u.)
msg[4] 4 Zeichen für die "beste" der abgespeicherten Dateien
+ = (z.B. ".RTF"), damit beim Lesen möglichst wenig
msg[5] Information verloren geht
msg[6] = 0
msg[7] = 0
Folgende Konstanten charakterisieren das Dateiformat. Nur wenn die
gespeicherten Daten auch im entferntesten nicht in eine der
Kategorien passen, sollte SCF_INDEF übergeben werden.
SCF_INDEF = $0000;
SCF_DBASE = $0001; Daten, die in eine Datenbank geladen werden
können (".DBF", ".CSV", ...)
SCF_TEXT = $0002; Textdateien
(".TXT", ".ASC", ".RTF", ".DOC", ...)
SCF_VECTOR = $0004; Vektorgrafik
(".GEM", ".EPS", ".CVG", ".DXF", ...)
SCF_RASTER = $0008; Rastergrafik
(".IMG", ".TIF", ".GIF", ".PCX", ".IFF", ...)
SCF_SHEET = $0010; Tabellenkalkulation
(".TXL", ".XLS", ".DIF", ".WKS", ...)
SCF_SOUND = $0020; Samples, MIDI-Files, Klänge, ...
(".MOD", ".SND", ".WAV", ...)
SCF_SYSTEM = $8000; Systemdateien (Farbpaletten etc.)
Durch Auswertung der Bitmap müssen nur diejenigen Applikationen,
die evtl. Verwendung für solche Daten haben, im Klemmbrett
nachschauen. Wenn "kombinierte" Dateiformate gespeichert werden (z.B.
Raster- und Vektorgrafik in einer Datei), muß entsprechend mehr
als ein Flag gesetzt werden. Eine Anwort auf SC_CHANGED wird *nicht*
erwartet.
Wenn eine Applikation das Klemmbrett nur löscht (wofür es eigentlich keinen Grund gibt), sollte SCF_INDEF sowie in msg[4] und msg[5] Null übergeben werden. Löscht eine Applikation das Klemmbrett, um gleich danach neue Daten darin zu speichern (dies ist der Normallfall), wird nur die "normale" Message verschickt, d.h. der neue Dateityp mit der optimalen Extension.
Reaktion auf SC_CHANGED
Wie sollte eine Applikation nun beim Empfang von SC_CHANGED reagieren? Zunächst sollte man überprüfen, ob die in msg[3] übergebenen Bits einer Kategorie angehören, die die Applikation überhaupt verarbeiten kann. Dabei sollte man zuerst die für die Anwendung optimale Kategorie abtesten, da das applikationseigene Dateiformat natürlich auch in diese Kategorie fällt.
Wenn die Applikation anhand der Bits entschieden hat, daß die Daten im Klemmbrett prinzipiell für sie geeignet sind, kann sie nun anhand der Extension entscheiden, ob z.B. die Lade- oder die Importroutine aufgerufen wird, oder aber mit "try and error" versuchen, bestimmte Dateien im Klemmbrett zu öffnen. Eine gute Möglichkeit besteht auch darin, beim Empfang dieser Message einen kleinen, unmodalen Fensteralert anzuzeigen, mit dem der Benutzer die Klemmbrettdaten nur auf seinen expliziten Wunsch hin importieren kann.
Hier geht es weiter.