Die wichtigsten XFolder Klassen-Ersetzungen sind:

1. XFolder für die normalen Ordner, sie enthält die Hauptfunktionalität von XFolder;
   
2. XFldDisk für Datenträger-Objekte, die im "Laufwerke"-Ordner erscheinen;
   
3. XFldObject, die WPS-Wurzel-Klasse, um Zugang zu vielen WPS-Interna zu haben, und
   
4. XFldDesktop für die neuen Desktop-Eigenschaften, vor allem für die erweiterte Systemabschluß-Prozedur.

Wie auf der vorhergehenden Seite beschrieben, ist die XFolder-Klasse eine Ableitung der Klasse WPFolder. So kann sie alles machen, was auch ein normaler Ordner kann. Als neue Funktion fügt sie neue Kontextmenü-Einträge zu allen Ordnern hinzu, erlaubt Ordner-Tastenkürzel (Hotkeys), verändert die Titelzeile u.v.a.

Durch Benutzung der Polymorphie definiert XFolder verschiedene WPFolder-Methoden neu, die nachstehend noch erläutert werden.

XFolder ist jedoch dann in der WPS als ein WPFolder-Ersatz registriert, was bedeutet, daß die WPS die XFolder-Klasse anstatt WPFolder als ihre Ordner-Standard-Klasse benutzen wird. Dadurch wird WPFolder nicht mehr direkt benutzt, sondern nur noch durch ihre Ersatz-(und Ableitungs-)Klasse XFolder. Für mehr Informationen über dieses Thema siehe die Seite "WPS-Klassen" im Einführungs-Teil.

Hier einige der WPFolder-Methoden, die von der XFolder-Klasse ersetzt werden sind (wahrscheinlich nur für Programmierer von Interesse):

• wpModifyPopupMenu: Diese WPObject-Methode wird von der WPS aufgerufen, kurz bervor das Kontextmenü angezeigt wird. Jede WPS-Klasse fügt hier ihre eigenen, klassenspezifischen Einträge hinzu.

  Da XFolder viel mit den Menüs spielt, ist dies eine der wichtigsten Methoden, die XFolder ersetzt. In dieser Methode ruft XFolder zuerst wpModifyPopupMenu von der Stammklasse (WPFolder) auf, um alle standardmäßigen Einträge zum Kontextmenü hinzuzufügen.

  Dann sucht sie nach dem XFolder-Konfigurationsordner (der die Objekt-ID <XFOLDER_CONFIG> haben muß) und fügt ihn völlig transparent ein. Jetzt werden alle Objekte, Untermenüs und Menüpunkte durchgegangen. Wenn der Konfigurationsordner nicht gefunden wird, erscheint ein Nachrichtenfenster, und ein leerer Ordner mit der erforderlichen ID wird auf der Arbeitsoberfläche erstellt.

  Dasselbe geschieht mit den "Ordnerinhalt"-Funktionen und den "Lieblingsordnern". Jedoch werden diese Untermenüs nur dann mit Objekten gefüllt, wenn sie vom Benutzer geöffnet werden; dies geschieht, indem XFolder die Fensternachricht WM_INITMENU abfängt, und zwar in der "unterklassierten" (subclassed) Fensterprozedur für den Ordnerrahmen (siehe unten). XFolder "unterklassiert" ebenfalls alle Untermenüfenster (und nur diese), damit es die Symbole zeichnen und Maustaste 2 zum Öffnen eines Ordners abfangen kann.

  (Bitte beachten Sie, daß "subclassing" nichts mit WPS-Klassen zu tun hat, sondern ein Presentation Manager-Terminus für die Benutzung verschiedener Nachrichten-Prozeduren für ein existierendes Fenster ist, um bestimmte PM-Nachrichten für dieses Fenster abzufangen. Dafür wird die API WinSubclassWindow benutzt.)

  XFolder modifiziert mit dieser Methode auch diverse andere Menüs (wie das "Sortieren"-Untermenü), wenn die globalen Einstellungen dies erlauben, und fügt andere Menüeinträge hinzu, wenn dies in den globalen Einstellungen aktiviert worden ist.
  

• wpMenuItemSelected: Dies wird immer dann von der WPS aufgerufen, wenn ein Eintrag im Kontextmenü vom Benutzer ausgewählt worden ist.

  XFolder überprüft, ob einer seiner eigenen (variablen) Einträge benutzt wird; wenn dem so ist, findet es das zugehörige Objekt im Konfigurationsordner. Falls es sich bei dem Objekt um eine Instanz der WPProgramm-Klasse handelt, werden die bereits vorher beschriebenen Tricks ausgeführt. Wenn das Objekt eine Schablone ist (egal welche WPS-Klasse), wird es nicht geöffnet, sondern XFolder erstellt dann davon ein neues Objekt im aktuellen Ordner (via wpCreateFromTemplate).

  Falls der gewählte Eintrag zu den "Ordnerinhalt"-Untermenüs gehört, wird einfach das zugehörige Objekt gestartet.

  Wenn irgendein anderer Menüeintrag, den XFolder zum Kontextmenü hinzugefügt hat, benutzt wird, führt XFolder intern die entsprechende Aktion aus.

  Wurde allerdings kein XFolder Menüeintrag ausgewählt, wird die wpMenuItemSelected-Methode der Stammklasse (WPFolder) aufgerufen, um die Standardeinträge nicht am Funktionieren zu hindern.
  

• wpMenuItemHelpSelected: Jedesmal wenn die F1-Taste auf einem Kontextmenüeintrag gedrückt wird, kommt diese Methode ins Spiel. Falls nötig, zeigt XFolder die zugehörige Hilfeseite auf.
  
• wpFilterPopupMenu: Mit dieser Methode entfernt XFolder die standardmäßigen Menüeinträge, die Sie in den globalen Einstellungen angegeben haben. (Diese Methode wird von der WPS noch vor wpModifyPopupMenu aufgerufen, also zuerst werden die Einträge zuerst entfernt und dann neue eingefügt.)
  
• wpclsQueryTitle: Die Zeichenkette XFolder (oder was auch immer Sie in den globalen Einstellungen angegeben haben) wird zurückgegeben, um der XFolder-Klasse einen unverwechselbaren Namen zu geben.
  
• wpclsQueryIconData, wpclsQueryIconDataN: Diese zwei Klassen-Methoden aktivieren die neuen XFolder-Ordnersymbole (offen und geschlossen), wenn Sie dies in den globalen Einstellungen erlaubt haben.
  
• wpOpen: Diese Routine wird aufgerufen, sobald die WPS einen Ordner (oder auch jedes andere Objekt) öffnet. XFolder muß diese Methode ersetzen, um eine ganze Reihe von Funktionen zu implementieren.

  Als erstes wird die Stammethode aufgerufen, um die Ordner-Ansicht zu öffnen: Die WPS erstellt ein Fenster mit einem Standard-PM-Container darin und zeigt es auch an.

  XFolder fängt dann das Handle für den Fensterrahmen ab, mit dem es dann den Fenstertitel des Ordners ändern und den kompletten Pfad dort einfügen kann (falls aktiviert). Eigentlich ist es nur ein einfacher Aufruf von WinSetWindowText, nur mit einigen Berechnungen, um den Titel nötigenfalls zu kürzen.

  In dieser Methode "unterklassiert" XFolder auch die Fensterprozedur für den Ordnerrahmen, damit WM_CHAR-Nachrichten für Hotkeys und viele andere Dinge verarbeitet werden können. Das Unterklassieren erschien mir die beste Möglichkeit zu sein, da der gesamte nötige WPS-Initialisierungskram durch das Aufrufen der Stamm-Methode erledigt wird. Der Nachteil ist, daß der Benutzer nicht mit dem Ordner interagieren kann, weil er erst danach mit Objekten gefüllt ("bevölkert" oder "populated" in WPS-Terminologie) wird.

  XFolder fängt alle WM_CHAR-Nachrichten (die nur zur Fensterrahmen-Prozedur weitergereicht werden, wenn sie noch nicht von einem Container, wie den Pfeiltasten, bearbeitet worden sind) ab und wertet sie gemäß der Ordner-Tastenkürzel-Liste aus, die in den globalen Einstellungen geändert werden kann.

  Unterklassieren wird auch für die Statusleisten der Ordner benötigt; die WM_QUERYFRAMECTLCOUNT-, WM_FORMATFRAME-, und WM_CALCFRAMERECT-Nachrichten werden abgefangen, um die Größe des Ordnerrahmens und seines Container-Unterfensters entsprechend dem für die Statusleiste benötigten Platz zu ändern.

  XFolder fängt auch einige Container-Benachrichtigungen ab, um in der Baumansicht automatisch zu rollen und die Statusleiste zu ändern, falls der Benutzer die Objektauswahl geändert hat.

  Zusätzlich angelt sich XFolder diverse Menü-Nachrichten, wie WM_INITMENU und WM_MENUSELECT, um einige Menü-Funktionen zu benutzen, die über normale WPS-Methoden nicht nutzbar sind.

  Alle Nachrichten, die keine Bedeutung für XFolder haben, werden zu ihrer ursprünglichen Fensterprozedur weitergereicht.

  Die wpOpen-Methode wird auch zur Implementation der erweiterten Sortierfunktionen von XFolder gebraucht; XFolder aktualisiert die Container-Einstellungen gemäß den Sortierkriterien, die Sie angegeben haben.
  

• wpAddSettingsPages: Die WPS ruft diese Methode auf, wenn das Einstellungsnotizbuch eines Objektes geöffnet wird. XFolder ersetzt diese Methode ebenfalls, um seine neuen Notizbuchseiten einzufügen. Dabei wird die Stammklasse aufgerufen, um auch die "normalen" Reiter einzufügen.

XFldObject arbeitet auf den ersten Blick anscheinend auch nicht so viel, außer daß die Standard Menü-Einträge unterdrückt werden und "Dateiname kopieren" hinzugefügt wird. Aber diese Klasse wird von anderen XFolder-Teilen benötigt, um über einige interne WPS-Ereignisse benachrichtigt zu werden, vor allem von XShutdown, was im Detail auf der nächsten Seite beschrieben wird.

Die XFldDesktop-Klasse wurde für die Änderung der Desktop-Menüeinträge implementiert sowie für XShutdown, das im Detail auf der nächsten Seite beschrieben wird, implementiert.

Während frühere Versionen auch die WPSystem-Klasse ersetzten, so daß das "System"-Objekt in der Systemkonfiguration einige Reiter für XFolders globale Einstellungen enthielt, hat sich dieses Verhalten mit V0.80 geändert. Stattdessen registriert XFolder zwei neue Klassen, die sich zwar von WPSystem ableiten, diese Klasse aber nicht ersetzen. Diese zwei Klassen sind XFldSystem und XFldWPS für das Objekt "OS/2 Kernel" bzw. "Workplace Shell". Die Einstellungen werden größtenteils in der OS2.INI gespeichert und jedesmal dann ausgewertet, wenn XFolder sie braucht (z.B. wenn Sie ein Kontextmenü öffnen). Dagegen werden die "lokalen" XFolder-Einstellungen für einen einzelnen Ordner in seinen .CLASSINFO-EAs gespeichert, wo die WPS auch die anderen Ordner-Einstellungen sichert. Dies wird dann von der XFolder-Klasse erledigt.

Bitte beachten Sie, daß die XFolder-Klassen entworfen wurden, um zu interagieren. Versuchen Sie nicht einfach nur einige der Klassen zu entfernen, da sich XFolder komisch benehmen könnte (wenn Sie Glück haben). Alle Möglichkeiten von XFolder sind individuell einstellbar, so daß Sie nur das einsetzen müssen, was Sie brauchen -- Sie können XFolder auch ganz schnell loswerden, falls Sie wollen.