In this mode, all operations occur on a background thread simultaneously with other operations, but .only one operation at a time may be outstanding on the DicomConnection.  If another is attempted before it has completed, this causes the container to wait until the first completes, but if care is taken to avoid multiple outstanding operations true asynchronous operation is possible.  The best way to achieve this is by firing all events except the first from the attached DicomViewer or DicomServer’s ActionComplete event.  However, alternatives to ensure synchronization include the Wait method and isReady property. 

Incoming N-EVENT-REPORTs are checked only when an outgoing operation is in progress or when CheckForEvents is called, and in either case, a success code is returned immediately.  The EventReport is called at the next opportunity, but the status code is disregarded.

In this mode, it is the container’s responsibility to ensure that DicomObjects is never left waiting for an operation to complete.  This can be achieved by ensuring that all operations on a DicomConnection other than the first (normally SetDestination) are fired only from ActionComplete events.  The advantage of this mode is that  as the container is never waiting, EventReport events can always fire synchronously, allowing a meaningful result to be returned.  This is a very specialised mode of operation, intended primarily for use with reverse SCU/SCP role negotiation (e.g. for Storage Commitment use).

The default value depends on the method of creation of the DicomConnection object.  If created stand-alone (which was not permitted in versions prior to 4), then mode is always doSync, and this cannot be changed, as an associated object would be required to fire ActionComplete events.  For DicomConnections created through the DicomViewer’s or DicomServer’s New method, the initial value (as in prior versions) is doAsync, but this may be altered prior to the first actual operation.  For incoming connections, the mode is always doAsync.

In this mode, every operation is performed synchronously – i.e. the method does not return control to the container until it is complete.  This mode is useful for short operations, where it does not matter if the container has to wait for a network operation or for initial testing and debugging.  This last feature is useful, as errors are guaranteed to be reported at the relevant method, rather than at the next, as will normally happen with the asynchronous modes.

ActionComplete events are not generated.
Incoming N-EVENT-REPORTs are checked only when an outgoing operation is in progress every 200ms, and in either case, a success code is returned immediately.  The EventReport is called at the next opportunity, but the status code is disregarded.