FUNKTION
        varargs void handle_event(mixed info)

ARGUMENTE
        info - Beliebiger Wert != 0 (optional).

BESCHREIBUNG
        Markiert den aktuell laufenden Event als 'gehandelt'. Moeglich ist
        dies natuerlich nur, wenn gerade ein Event laeuft, handle_event()
        also im gleiche Backend-Cycle abgearbeitet wird, wie der Event. Es 
        macht daher nur Sinn, handle_event() auszufuehren, wenn das Objekt
        als Lauscher angemeldet ist, und gerade einen Event mitgeteilt
        bekommt.

        Normalerweise ist das 'handlen' den Systemhandlern vorbehalten. Das
        'Handeln' von Systemevents ist NICHT erlaubt! Bei privaten Events
        ist dies nicht nur erlaubt, sondern sogar notwendig. *grins*

        'info' muss nicht gesetzt werden. Wird es gesetzt, wird es im Event-
        Daten-Mapping in Key E_HANDLED gespeichert. Der Handler wird automa-
        tisch immer in Key E_HANDLER des Mappings gespeichert.

BEACHTE
        Ein Event muss nicht als gehandelt markiert werden. Die meisten
        System-Events testen jedoch den Erfolg des Events mittels des
        E_HANDLED und/oder E_HANDLER. Es ist auf jeden Fall ein guter
        Stil als Handler den Event als 'gehandelt' zu markieren...

        System-Handler sind meist als globale Lauscher angemeldet und
        in /global/handlers/* zu finden.

        ES IST NICHT ERLAUBT, NACH handle_event() WEITERE AKTIONEN AUS-
        ZUFUEHREN! D.h. wenn man handle_event() aufgerufen hat, darf
        man KEINE WEITEREN AKTIONEN mehr ausfuehren, die dazu fuehren
        koennten, dass ein weiterer Event erzeugt wird. Am besten ist das
        handle_event() also am Ende der Funktion unmittelbar vor return.
        Wer das nicht macht, muss sich nicht wundern, wenn der Event nicht
        korrekt als gehandelt markiert wird! Der Event-Daemon markiert den
        Event naemlich nicht sofort, sondern erst, wenn die Funktion ein
        return macht. Sendet man aber nach handle_event() einen neuen 
        Event werden die internen Variablen des Event-Daemons dadurch neu
        initialisiert und das Handeln wird nicht ausgefuehrt. Also: Immer
        erst alles erledigen, was zu tun ist, neue Events senden, etc und
        erst dann (ganz am Ende) den Event als gehandelt markieren!!!

        ES IST NICHT ERLAUBT, EINEN BEREITS GEHANDELTEN EVENT EIN WEITERES
        MAL ZU HANDLEN! (bei System-Events)

BEISPIEL
        Der System Move-Handler lauscht als Handler auf ET_GO:

        void create() {
          if(clonep()) { destruct(this_object()); return; }
          listen_event(ET_GO, EPRIO_DEF_HANDLE, #'receive_event);
          set_global_listener(ET_GO, 1);
        }

        void receive_event(mapping data, string type, int prio) {
          // wenn schon gehandelt, dann nichts machen!
          if(data[E_HANDLED]) return;
          //
          // .. ein Handler muss tun, was ein Handler tun muss ;-)
          //
          handle_event();
        }

        Der Go-Event wird gehandelt und der Event markiert.

SIEHE AUCH
        listen_event(S), unlisten_event(S), set_global_listener(S),
        send_event(S), cancel_event(S), events(WL), event_senders(WL),
        event_prioritaeten(WL), event_types(WL)