Avoiding the Need to Register DicomObjects

Whilst ActiveX controls like DicomObjects have many advantages, one of the downsides is that they need to be registered in the registry before they can be used, and this has the following disadvantages:

  • Only an administrator or power user can do this on a locked down system
  • Only one copy can be registered on a machine at a time (potentially giving version conflicts for other applications)
  • These features make it very difficult to run an application from CD etc.

There is no simple solution to this possible within DicomObjects, as it has to obey the ActiveX/COM rules, but there is now a good and reasonably priced solution on the market, called "MoleBox Pro", which allows any DLLs, OCXs etc you wish (and even registry settings if you like!) to be "wrapped up" into a single self-contained .exe. It can be downloaded from http://www.molebox.com and is reasonably priced. Of course, the advantages for your executable are:

  • You don’t need any user rights etc. to register the OCX
  • It leaves no "footprint" on the machine
  • It Guarantees that you’re running against a specific OCX version (no more “DLL hell”)

My experiences with this product have been excellent:

  • It does exactly what it says on the box
  • It works perfectly with DicomObjects – I have not encountered any issues using it
  • A free trial is available.
  • It doesn’t need a recompile – it works on the ready made .exe etc.
  • There are no "per application" or run-time license fees

And for the record, there is no commercial connection between Medical_Connections and MoleBox - I just happen to like the product!

User Experiences

Please do add your own, as a new section, as per the one(s) already here.

Alan Grace, Sybermedica

I have used MoleBox with dicomobjects, most of the time it has worked ok but I have had some funnies. Our situation is slightly odd in that the main exe loads a dll dynamically, this dll uses DicomObjects. Occasionally I have seen a problem when the dll tries to load that looks the same as if DicomObjects was not registered. One possible solution to this has been to put an instance of DicomViewer on the main form in the exe but not make it visible, this should force DicomObjects to be loaded before the dll is loaded. This seems to work but we need to test on multiple machines to confirm.