Instances are enabled separately for send and receive. For example, an application can choose to enable an instance for send only. A reference count is kept of how many times an instance is enabled for send, and a similar count is kept for receive.
If the request is for both send and receive, and the instance only supports one direction, then either MIDIERR_SENDONLY or MIDIERR_RECEIVEONLY is returned (as appropriate), and the instance is not enabled for either direction. If the instance supports neither send nor receive, MIDIERR_NOT_ALLOWED will be returned. Therefore, the application should call MIDIQueryInstanceList to determine the capabilities of the instance before attempting to enable it.
MIDIEnableInstance has special meaning for hardware nodes. Hardware nodes are disabled by default and must be explicitly enabled. When a hardware node is enabled for the first time, the Type A driver that it represents is issued an open request. If this request fails then MIDIERR_HARDWARE_FAILED is returned.
All other nodes are enabled by default.
If an application attempts to enable an instance for both directions simultaneously, it is possible for one direction to succeed and for the other to fail. In this case, the instance will be enabled for only one direction and the application will not know which direction that is. This can happen when enabling a hardware node or when the reference count for one direction (but not the other) exceeds an internal limit. In the former case, MIDIERR_HARDWARE_FAILED is returned and in the latter case, MIDIERR_RESOURCE_NOT_AVAILABLE is returned.
Therefore, it is suggested that an application make separate MIDIEnableInstance calls to enable the instance for both directions. If the first call fails, the application can then take appropriate measures.