&xwp; contiene attualmente un piccolo elemento di esempio (toolkit\miniwdgt.c) che contiene un elemento minimale, senza alcuna funzionalit… particolare. Tutto quel che questo elemento fa Š mostrare un punto interrogativo.

Questo mini elemento Š stato aggiunto per mostrare qualcosa con cui cominciare. Pu• decisamente essere migliorato. Esso non

In definitiva, una DLL plug-in deve fare le seguenti cose:
  1. Deve esportare tre procedure per numero ordinale.

    a) La funzione esportata "init" (ordinale 1) viene chiamata una sola volta dallo &xcenter;, al momento del caricamento della DLL, che pu• per• essere anche caricata in situazioni diverse dalla creazione di elementi, per cui non Š detto che questo sia l'unico caso. All'atto dell'inizializzazione, la DLL deve registrare la classe di finestre PM dell'elemento (tramite una chiamata a WinRegisterClass). In aggiunta, essa pu• importare funzioni da XFLDR.DLL, il cui handle al modulo le Š stato dato (in via opzionale). Comunque, essa deve ritornare sempre un puntatore all'array delle strutture XCENTERWIDGETCLASS contenute nella DLL, cosŤ che lo &xcenter; conosca quali sono le classi contenute.

    Consultare toolkit\miniwdgt.c per sapere come si fa.

    b) La funzione esportata "uninit" (ordinale 2) viene chiamata quando la DLL Š scaricata dallo &xcenter;. Questa funzione pu• eseguire operazioni di pulizia, se necessario.

    c) La funzione esportata "query version" (ordinale 3) viene chiamata anche prima della funzione "init" per controllare il numero di versione di &xwp; richiesto dall'elemento.

  2. La DLL plug-in deve poi contenere una window procedure PM per la classe dell'elemento. Nel nostro piccolo esempio, questa Š la funzione fnwpSampleWidget. La funzione "Init" Š responsabile della chiamata a WinRegisterClass su questa window procedure per creare una classe di finestre di PM da essa.

    Questa funzione ha la classica struttura switch/case usata con ogni window procedure di PM. Ci sono per• alcune considerazioni da fare, spiegate pi— sotto.

  3. In presenza di WM_CREATE, l'elemento deve immagazzinare il puntatore a XCENTERWIDGET che riceve con mp1 nella sua window word QWL_USER. Ecco perch‚ l'esempio chiama WinSetWindowPtr(hwnd, QWL_USER, mp1); su WM_CREATE.

  4. All'apparire di WM_CONTROL, l'elemento deve gestire le notifiche dallo &xcenter;. Lo &xcenter; spedir… messaggi WM_CONTROL all'elemento quando vuole, per esempio, conoscerne le dimensioni.

    I codici di notifica che lo &xcenter; usa con WM_CONTROL sono elencati in toolkit\center.h. Probabilmente non ne saranno aggiunti altri in futuro.

  5. Normalmente, in PM, tutti i messaggi non elaborati sono mandati a WinDefWindowProc. La cosa cambia con gli elementi: Š necessario passare sempre i messaggi non elaborati alla procedura predefinita dello &xcenter;, il cui indirizzo Š passato all'elemento nella struttura XCENTERWIDGET su WM_CREATE, nel campo pfnwpDefWidgetProc. (Proprio per questo Š necessario immagazzinare quella struttura nelle window words.)

    Se non vengono passati i messaggi non gestiti, la funzionalit… dell'elemento sar… compromessa. Peggio ancora, cosŤ facendo si causeranno perdite di memoria, poich‚ la procedura di default degli elementi Š responsabile della ripulitura delle risorse e di notifiche importanti allo &xcenter;.

  6. Anche se viene fatta un'elaborazione personalizzata di WM_DESTROY, Š comunque necessario passare sempre WM_DESTROY a pfnwpDefWidgetProc. In caso contrario lo &xcenter; non pu• ripulire correttamente le risorse dell'elemento.