1.2 eDirectory Event Functions

eDirectory Event provides two types of functions: registration and helper. eDirectory Event Registration Functions allow an NLM application to register and unregister callback functions when a specific event occurs. eDirectory Event Helper Functions are for accessing and evaluating the event data.

1.2.1 eDirectory Event Registration Functions

The following table lists registration functions:

Name

Description

NWDSERegisterForEvent

Registers a function to be used as a callback when a specific eDirectory event occurs.

NWDSEUnRegisterForEvent

Unregisters a callback that has been registered to be called when a specified eDirectory event occurs.

See Also

1.2.2 eDirectory Event Helper Functions

The functions listed in the following table are helper functions:

Name

Description

NWDSEConvertEntryName

Converts object names returned in the DSEEntryInfo structure to a form that is consistent with the NWDS functions.

NWDSEGetLocalAttrID

Retrieves the local ID of a specified eDirectory attribute.

NWDSEGetLocalAttrName

Retrieves the name of the eDirectory attribute associated with the supplied local ID.

NWDSEGetLocalClassID

Retrieves the local ID for the specified object class.

NWDSEGetLocalClassName

Retrieves the name of the eDirectory object class associated with the supplied local ID.

NWDSEGetLocalEntryID

Retrieves the local ID for the specified eDirectory object.

NWDSEGetLocalEntryName

Retrieves the name of the eDirectory object that is associated with the supplied local ID.

See Also

1.2.3 eDirectory Event Handling

The handler parameter of NWDSERegisterForEvent points to a function called when the event occurs. Separate functions can be registered for each event or a single function can be registered for multiple events. If a callback processes multiple events, it can use the type parameter to determine which event has occurred.

See Also

1.2.4 eDirectory Event Slot Table

Each event has an assigned number (see Values), which corresponds to the event slot. The Slot Table is dynamically extended if a new event is registered with an event number greater than those previously registered. The system does not currently do any validation on the event number, so the callers of the registration function need to be reasonable and not ask to register for event 1,000,000 when the system is handling only a few hundred events.

When an event is first registered for, an EventSlot structure is allocated containing fields to hold the number of handlers registered for the event, and fields to manage the individual handlers in priority order.

The Slot Table initially allocates enough handler space to hold two handlers for each of the three priorities. Handler space can be dynamically expanded if more handlers are needed within a priority. The following figure illustrates this design.

Event     Slot Table

The figure above illustrates a possible configuration for slot number 3. The other slots would have similar configurations. Slot 3 has the default configuration with space for two handles for priorities 0 and 2, and a space for an extra handler for priority 1. Just as the Slot Table can grow dynamically as events are added, the list of handlers can grow as handles register for an event.

See Also