MCI_WAIT specifies that the application should not send a notification message. It also specifies that the driver should not return to the caller until the entire command has been completed.
MCI_NOTIFY specifies that upon completion of the command a notify message is to be sent to the application using the mdmDriverNotify function. If the notify flag is specified, the MCD should perform error checking and minimal processing on the command before returning to the caller. Error checking should ensure that the command can begin the main processing.
If neither MCI_WAIT or MCI_NOTIFY is specified, the processing is the same as if MCI_NOTIFY were specified, except that notification is not provided when the command completes.
Error and parameter checking should minimize the possibility that an error occurs after control is returned to the calling thread, requiring a notify error message to be sent to the calling application. The list of error conditions that are checked before returning to the caller will vary from driver to driver.
The main processing of the command should be done using a separate thread or a mechanism that allows control to be returned to the calling thread. If the MCD is using the SSM subsystem, the event procedure should be used for handling notify commands.
If an error is returned on an mciDriverEntry call, the error should not be sent using mdmDriverNotify. After an error is returned on mciDriverEntry, the MCD has finished processing that command.
On notify commands, it is the responsibility of the MCD to ensure that the data structure associated with the command message is copied into driver memory before returning to the caller. If this is not done, the driver might find that the memory was changed before it could process the command. For example, the hwndCallback, ulFrom, and ulTo fields on the MCI_PLAY message should be copied when the MCI_NOTIFY flag is specified.
Media control messages that can require a lot of time to complete are MCI_PLAY, MCI_RECORD, MCI_SEEK, and MCI_STEP. These commands are action commands. Messages such as MCI_PAUSE, MCI_GETDEVCAPS, MCI_STATUS, and MCI_SET are non-action commands and do not require much processing time. The non-action commands need not be processed on a separate thread if the notify flag is specified. For these commands, the call to mdmDriverNotify should be made at the completion of the command.
If the MCD is using the Stream Programming Interface (SPI) functions to perform data streaming, the SPI events should be used instead of separate threads. SPI requires an event routine to handle SPI events such as End-of-Stream, an error, and so on. SPI will call this event routine on one of its threads. Therefore, the mdmDriverNotify call could be made as part of the event routine.
An MM_MCINOTIFY message can have the notification codes shown in the following table associated with it.
旼컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿙otification Code 쿎ondition That Caused the Notification � 쳐컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿘CI_NOTIFY_SUCCESSFUL 쿟he command completed successfully with no � � 쿮rrors. � 쳐컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿘CI_NOTIFY_SUPERSEDED 쿌 second command of the same type is received� � 퀇ith the notify flag set. � 쳐컴컴컴컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿘CI_NOTIFY_ABORTED 쿌 second command is received that prevents � � 퀃he first command from completing � � 퀂uccessfully. If the driver finds an error � � 쿮arly in the parameter-checking or command � � 쿾rocessing that requires an error to be � � 퀁eturned to the caller, no notification is � � 퀂ent back to the application. � 읕컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴�If the notification code field of MM_MCINOTIFY contains a value other than those shown in the previous table, the value is the error code for a specific OS/2 multimedia error condition. Only one MM_MCINOTIFY message per command should be sent.