Frequently Asked Questions (CFx)

Owned by Andre Neumann
Last updated: Aug 28, 2020 by Tamara Silai
5 min read

Coding the Libraries

How can I specify handle values for objects that I add to a database?

The following code reserves a specified number of object handle values in an OdDbDatabase and supplies a custom handle value for an entity that is added to the database:

// Create a database but do NOT initialize the default objects // in the database. OdDbDatabasePtr pDb = myServices.createDatabase(false); // Reserve myHandSeed handle value, which causes all future // object handles created automatically by DWGdirect to be greater // than myHandSeed. pDatabase->getOdDbObjectId(myHandSeed, true); // Create if not found // Default objects created starting with handle myHandSeed + 1. pDb->initialize(); // Create a new entity OdDbCirlePtr pCirc = OdDbCircle::createObject(); // Set circle params... // Add the circle to database with a specified handle pDb->addOdDbObject( pCircle, // Entity to add OdDbObjectId::kNull, // OwnerId is set when entity is added to block MyCircleHandle); // Custom object handle // Add the entity to a block pBlockRecord->appendOdDbEntity(pCircle);

Compiling the Libraries

Why do I get link errors of the form "operator new already defined in DD_XXXX_Alloc.lib"?

When the Microsoft VC /MT static library version of DWGdirect is linked into an application that uses the MFC Static Library (/MT configuration), the linker may issue errors described in the MS KB article Q148652: http://support.microsoft.com/default.aspx?scid=kb;[LN];Q148652.

This error occurs because TD_XXXX_Alloc.lib contains definitions of the following functions:

  • odrxAlloc

  • odrxRealloc

  • odrxFree

  • operator new

  • operator delete

MFC provides its own versions of "new" and "delete", thus causing the error.

To resolve this error, do not link TD_XXXX_Alloc.lib to the client application. Instead, include the following code in the client application:

extern "C" { ALLOCDLL_EXPORT void* odrxAlloc(size_t s) { return ::malloc(s); } ALLOCDLL_EXPORT void* odrxRealloc(void* p, size_t new_size, size_t /*old_size*/) { return ::realloc(p, new_size); } ALLOCDLL_EXPORT void odrxFree(void* p) { ::free(p); } } // extern "C"

Why do I get link errors of the form 'undefined symbol' "public: class OdWString const & __thiscall OdWString::operator=(wchar_t const *)"?

Most likely you have the (/Zc:wchar_t) compiler option set. This causes wchar_t to be defined as its own type. Since the DWGdirect libraries are not built with this option, the linker is treating wchar_t (from your application) as a separate type from the one used to compile the DWGdirect libraries internally, where it is defined as unsigned short.

Disabling (/Zc:wchar_t) compiler option eliminates the error.

Working with DWG Files

When I convert a DWG 2004 file back to R15, why do my gradient fills disappear and other items look different, such as colors?

DWG 2004 files can store a direct color or an RGB value, which allows a single drawing to store millions of unique color values. DWG files from R15 and earlier versions can only store a color table index, which is a number representing one of 255 possible colors. When you save a DWG 2004 file as DWG R15 or earlier, you must map each RGB value to the closest color table index. As a result, the colors in the DWG R15 file may look bleak or dreary when compared to the original DWG 2004 file. DWG R15 files saved from AutoCAD 2004 have the same behavior.

Similarly, gradient fills from DWG 2004 are not supported in DWG R15. When saving a hatch with a gradient fill to a DWG R15 file, the fill is converted to a solid fill using the first of the two gradient colors.

MText in DWG 2004 files might contain tab and indentation values that are not supported in DWG R15 and earlier files, and therefore, are lost when saving from DWG 2004 back to earlier versions. The formatting and appearance of MText may change.

Note: AutoCAD R14 supports only a single paper space layout and it does not support lineweights, as lineweights are available starting with AutoCAD 2000.

Working with Drawings

How do I determine the drawing units (millimeters, inches, feet, or kilometers) of a drawing?

Any drawing stores a number of system variables that are responsible for units and their display. It is important to know the DWG version in which the system variables were introduced. As some DWG file versions do not store all of the system variables, loading an older file assigns default values to the newer system variables.

MEASUREMENT is a read-only system variable that was introduced in DWG R14. This system variable controls hatch pattern and linetype files used in the drawing.

OdDb::MeasurementValue OdDbDatabase::getMEASUREMENT()

Returned values:

  • kEnglish — Uses files with ANSI Hatch and Linetype definitions (acad.pat and
    acad.lin).

  • kMetric — Uses files with ISO Hatch and Linetype definitions (acadiso.pat and acadiso.lin).

INSUNITS was introduced in DWG R15 (AutoCAD 2000).

OdDb::UnitsValue OdDbDatabase::getINSUNITS()

Returned values:
kUnitsUndefined = 0
kUnitsInches = 1
kUnitsFeet = 2
kUnitsMiles = 3
kUnitsMillimeters = 4
kUnitsCentimeters = 5
kUnitsMeters = 6
kUnitsKilometers = 7
kUnitsMicroinches = 8
kUnitsMils = 9
kUnitsYards = 10
kUnitsAngstroms = 11
kUnitsNanometers = 12
kUnitsMicrons = 13
kUnitsDecimeters = 14
kUnitsDekameters = 15
kUnitsHectometers = 16
kUnitsGigameters = 17
kUnitsAstronomical = 18
kUnitsLightYears = 19
kUnitsParsecs = 20
kUnitsMax = kUnitsParsecs

The value of INSUNITS is used for scaling during drag-and-drop, cut-and-paste, and other operations where objects are copied from one drawing to another.

AUNITS was introduced before DWG R12. It controls the units for angle measurements (decimal degrees, degrees/minutes/seconds, or radians). This system variable affects only the display of values. API functions always return angles in radians.

LUNITS was introduced before DWG R12. It controls how coordinate values display (scientific, decimal, engineering, etc.). This system variable affects only the display of values. API functions always return coordinate values as they are stored in the drawing without any scaling.

NOTE: Altering the values of INSUNITS, LUNITS, or AUNITS does not effect any coordinates stored in the drawing. The contents of the drawing are not scaled.

Why linetypes do not display when using OdDb3dPolyline?

Linetypes do not display for 3D polylines. In AutoCAD, OdDb3dPolylines (AcDb3dPolylines) always display with a SOLID linetype.

You can use OdDb2dPolyline or OdDbPolyline for planar polylines or OdDbLine for a single line segment.

Note: Linetype generation for planar polylines can be different. See OdDb2dPolyline::isLinetypeGenerationOn() and OdDbPolyline::hasPlinegen().

If entities overlap, which one is rendered on top?

It depends. The rendering works differently in 2D wireframe and 3D render modes:

  • 3D render modes — The appearance depends on which of the two entities is closer to the camera. If the entities are in the same plane, the result is unpredictable.

  • 2D wireframe render mode — The appearance depends on the drawing order. By default, the entity that appears in the file first is rendered first. The order can be changed using OdDbSortentsTable methods. The value of the SORTENS system variable determines whether OdDbSortentsTable is taken into account or not.

The Sort Table is returned by OdDbBlockTableRecord::getSortentsTable() for Layout blocks.

Note: OdDbBlockTableRecord::newIterator() can return a "sorted" iterator, which takes into account the Sort Table.