Hier wollen wir die Leistungsfähigkeit dieses Befehls an zwei typischen Beispielen demonstrieren:
Nehmen wir an, dass Sie irgendwo in ihren Intuition Strukturen eine Variable g: Gadget; haben. Sie wollen nun im Debugger anschauen, mit welchen Daten Intuition dieses Gadget zeichnet. Das Problem ist aber, dass das Feld g.gadgetRender vom Typ ADDRESS ist. Im Prinzip zeigt dieses Feld auf eine Border- oder Image-Struktur. Welche Struktur Intuition zum Zeichnen verwendet, steht im Feld g.flags. Als erstes schauen wir im Feld g.flags nach, ob das Bit gadgImage gesetzt ist. Nehmen wir an, es sei nicht gesetzt; dies bedeutet, dass g.gadgetRender auf eine Border- Struktur zeigt. Nun können wir den Typ ändern.
Klicken Sie nun das Feld g.gadgetRender mit dem rechten Mausknopf an. Es erscheint ein Eingabefeld, in das Sie IntuitionL.BorderPtr schreiben. Nachdem Sie Ihre Eingabe mit bestätigt haben, ist das Feld g.gadgetRender vom Typ BorderPtr. Sie können nun in die Struktur hineinzoomen.
Für unser zweites Beispiel nehmen wir folgendes an: Sie schreiben ein Modul, dass mit beliebig langen Zahlen rechnen kann. Dazu deklarieren Sie in der Definition Ihres Moduls SuperREAL: TYPE MyREAL;. Dies ist eine opake Typendeklaration; nur in der Implementation ist bekannt, wie der Typ MyREAL aussieht. Nun ist das solange eine gute Idee, bis Sie Ihr Modul austesten wollen und eventuell auch in die Daten Ihrer Struktur hineinschauen wollen. Der Debugger wird sich aber leider weigern, eine Variable ,,VAR r: MyREAL;`` Ihres Testprogramms näher zu zeigen.
Da Sie aber die Referenzdatei des Moduls SuperREAL besitzen, können Sie den opaken Typ auflösen und ihn in SuperREAL.MyREAL verwandeln. Dann wird der Debugger alle Daten Ihrer Variablen r darstellen können.