Comparison of MoveImages MoveSync GetUsingMove and Move

The DicomObjects.COM version of DicomObjects provides 4 different mechanisms for initiating C-MOVE operations, and we are often asked about the differences and relative benefits. This page is therefore a summary of the differences.

Why is C-MOVE so difficult?

The C-MOVE protocol itself is described here

There are several features of C-MOVE itself which are mode difficult to handle than most other operations, many of which related to the network problems associated with the need for a reverse association back from the server to the client - these are detailed in the page C-MOVE Problems. In addition however, there is a need for the client program to be able to receive the images on that reverse connection, and to do so in a way which does not cause a deadlock.

The deadlock problem

This problem would arise if a single threaded program were to issue a C-MOVE request and simply wait for the C-MOVE to complete. The SCP would receive the request and send images using C-STORE on the secondary association to the client, which would trigger an Imagereceived (or ImageReceivedAsync) event. However, an event cannot fire whilst an outgoing COM operation is in progress, so the event would be queued waiting for the C-MOVE to complete. Therefore:

There is no single solution to this issue but the COM version of Dicomobjects provides 4 to choose from (it is all a lot simpler in the .NET Version which is free-threaded, avoiding the deadlock.


This is the simplest of the solutions, but also the least reliable.


This is also very simple, but due to the deadlock issue is only suitable when doing a genuine third party C-MOVE operation - i.e. the recipient of the images is not the program issuing the C-MOVE request.


This is a more complex solution, using an internal thread for listening. As it is quite complex, it has its own page - GetUsingMove


This is very different to the other methods, and is a little more complex to use, being based on the DicomConnection object rather than DicomQuery, but it by far the best, and the only one recommended for production use in workstations etc. The major advantage is that it is asynchronous (avoiding deadlocks and a frozen GUI) but still provides feedback when it completes by using the ActionComplete event. A full description with example code is given on the DicomConnection.Move page.

Summary Table

  Object used C-MOVE Thread Receive Thread Can Deadlock Blocks the GUI Result Available
MoveImages DicomQuery Background Main No No No
MoveSync DicomQuery Main Main Yes Yes Yes
GetUsingMove DicomQuery Main Background No Yes Yes
Move DicomConnection Background Main No No Yes

We use cookies to give you the best possible experience on our website. By continuing to use this website, you agree with our use of cookies. for more information please click HERE