3.1.4.4.1.1 IDMNotify::ObjectsChanged (Opnum 3)

The ObjectsChanged method notifies the client of object changes.

 HRESULT ObjectsChanged(
   [in] DWORD ByteCount,
   [in, size_is(ByteCount)] byte* ByteStream
 );

ByteCount: Length of ByteStream in bytes.

ByteStream: Array of bytes that compose any number of variable-length change notification structures. Memory for the array is allocated and freed by the caller (that is, the server).

Any variable-length change notification structure in the array starts with a fixed header that contains the fields shown in the following table.

Field name	Data type	Description
size	ULONG	The total size of the structure in bytes.
type	DMNOTIFY_INFO_TYPE	The type of object that changed.
action	LDMACTION	The type of change that the object underwent.

Depending on the value of type, the fixed header of the notification structure is followed by one of the following items.

Type	Structure following the fixed header
DMNOTIFY_VOLUME_INFO	VOLUME_INFO
DMNOTIFY_TASK_INFO	TASK_INFO
DMNOTIFY_DL_INFO	DRIVE_LETTER_INFO
DMNOTIFY_FS_INFO	FILE_SYSTEM_INFO
DMNOTIFY_SYSTEM_INFO	ULONG
DMNOTIFY_DISK_INFO	If client called Initialize on IVolumeClient interface, then DISK_INFO. If client called Initialize on IVolumeClient3 interface, then DISK_INFO_EX.
DMNOTIFY_REGION_INFO	If client called Initialize on IVolumeClient interface, then REGION_INFO. If client called Initialize on IVolumeClient3 interface, then REGION_INFO_EX.

Note The structures that are transmitted within ByteStream are not marshaled in RPC Network Data Representation (NDR) format. They are C structures, and the memory layout and field types are those found on the Windows/Intel 32-bit and 64-bit architectures, and, Windows/AMD 64-bit architecture. These structures are not packed, and padding bytes can exist between successive structure fields to ensure that the field of a given data type begins at a byte offset that is an integer multiple of the type's size with respect to the beginning of the structure. The structures transmitted within ByteStream also appear in other interfaces as RPC-marshaled structures. In these interfaces, the structure fields will be marshaled in NDR format.

The byte stream contains a sequence of one or more notification frames. Each frame is made up of a sequence of the following fields: size, type, action, and a structure of the type specified in the type field. Some of the structures contain character pointer fields. These fields contain pointers to variable-length character strings, and the following technique is used at the server to load the byte stream:

1. The structure is copied one byte at a time from memory into ByteStream beginning at first byte after action field. If the structure contains character pointer fields, those fields are omitted.

2. The character strings of the character pointer fields are copied into ByteStream following the structure in the order in which they appear in the structure. All strings are null-terminated. There is no padding between the end of the structure and the first string, or between successive strings.

   At the client, the following technique is used to parse the byte stream back into the appropriate structures:

3. The notification size, type, and action are parsed from the byte stream.

4. The notification object structure, up through the first string field, is copied out of the byte stream and into the appropriate structure. For the IVolumeClient interface, the disk and region structures are DISK_INFO and REGION_INFO; for the IVolumeClient3 interface, the structures are DISK_INFO_EX and REGION_INFO_EX. The client's ObjectsChanged implementation MUST switch based on which version of the IVolumeClient interface is being used. The client MUST also determine the type of processor architecture for both the server and client. If the architectures are the same, the padding in the client-defined structures will match that used in the server's byte stream. If the architectures are not the same, the client MUST use the proper method for parsing the byte stream, taking into account padding that MAY have been added for alignment purposes on either the client or on the server. For more information, see section 8.

   Allocations are done on the client to hold the character strings of the character pointer fields. These fields are copied from ByteStream to the client-allocated buffers, and appropriate structure fields are set to point to the client-allocated buffers. All strings are null-terminated.

Return Values: The method MUST return 0 or a nonerror HRESULT on success, or an implementation-specific nonzero error code on failure (as specified in [MS-ERREF] section 2.1).