[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ginkgocadx ...



Hi Gert,

On 29.01.2016 14:41, Gert Wollny wrote:

>> let me know what kind of problems you encountered.
> 
> Nice, here they are:
> 
> (1) UID_FINDGeneralPurposeWorklistInformationModel is gone (no 
> changelog entry though)

This is an easy one (if you know where to look:).  From time to time
DICOM removes ("retires") services from the standard that have
never/rarely been implemented in practice. Sometimes alternative
services are available, in this case one could use the "Unified Worklist
and Procedure Step" service.

Long story short: The UID constant has been renamed to
UID_RETIRED_FINDGeneralPurposeWorklistInformationModel which is the one
to use. We do the same for other retired  services.

> My workaround: I defined it to its old value 
> "1.2.840.10008.5.1.4.32.1" in the source file where it was used.

Clean solution from the functional point of view.

> [oflog stuff]

No idea about those yet since I do not know much about unicode or the
log4cplus integration in DCMTK (someone else did that some time ago, and
we also should upgrade our copy).

> i.e. I defined:
> 
> #define DCMTK_LOG4CPLUS_TRACELOGGER_H #define 
> DCMTK_LOG4CPLUS_LOGGING_MACROS_HEADER_
> 
> Then I prayed for forgiveness and all compiled and linked.

If they are not used (as you said) this sounds like a viable solution...

I cannot offer other insights, sorry.

> I'd be grateful for any help, be advised though, that the developers 
> of ginkgocadx did a lot of dirty coding, e.g. copying files from 
> original libraries and then slightly adjusting them. For example
> they provided a copy of offile.h  with their own changed
> implementation of OFFile without changing the class name or the
> header guard define.
> 
> That means it is quite possibe that this last error is a result of 
> such a mixup and the only way to find this is digging through the 
> preprocessed source.

I tend to believe the same.

If you encounter something that looks wrong on the DCMTK side of things
do not hesitate to contact me again, we also can patch upstream DCMTK if
it makes sense.

> ... but first I have to fix the VTK transition bugs.

Best regards,
Michael


Reply to: