Feature #425
closed
For now, a comment has been added to the INSTALL file:
Known limitations of DCMTK on the Windows platform.
[...]
5. DCMTK does not compile when UNICODE or _UNICODE is defined because the
VisualStudio compiler then uses the Unicode version instead of the ANSI
version for all Windows API functions (i.e. type wchar_t instead of char
for all character string parameters and return values).
- Tracker changed from Bug to Feature
- Status changed from New to Assigned
- Assignee set to Pedro Fernando Arizpe Gómez
- Related to Feature #543: Check whether "oflog" supports character set conversion added
With commit b55e5e1 the internal XML parser (ofxml) has been enabled to support "wide characters". However, by defining the macro WIDE_CHAR_XML_PARSER, the class DcmEncapsulatedDocument and the tool cda2dcm loose the ability to parse CDA data (since the API of the parser becomes incompatible) and become useless. pdf2dcm and stl2dcm should still work as expected.
This issue should also be fixed when enabling support for UNICODE / _UNICODE.
- Subject changed from DCMTK does not compile with UNICODE / _UNICODE defined (Windows only?) to DCMTK does not compile with UNICODE / _UNICODE defined (Windows only)
- Status changed from Assigned to Closed
- Assignee changed from Pedro Fernando Arizpe Gómez to Marco Eichelberg
- % Done changed from 0 to 100
- Estimated time set to 5:00 h
Closed by commit #621d553e8 (public modules) and 3aa1fcb67 (private modules).
Note: UNICODE/_UNICODE does not implicitly activate the wide-char mode in ofxml anymore. When this is actively activated by the used by defining WIDE_CHAR_XML_PARSER at compile time, a compiler warning will be printed indicating that cda2dcm will not work.
Also available in: Atom
PDF