Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 then 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 appliation 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 for the following functions:

  • odrxAlloc

  • odrxRealloc

  • odrxFree

  • operator new

  • operator delete

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

This error can be resolved by not linking TD_XXXX_Alloc.lib into the client application, and by instead including the following code somewhere 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 (there it is defined as unsigned short).

If you remove this option from your language settings, the error will go away.

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 RGB value, which allows millions of unique color values to be stored in a single drawing. DWG R15 files and earlier versions can only store a color table index, which is a number representing one of 255 possible colors. When saving a DWG 2004 file back as DWG R15 or earlier, each RGB value must be mapped to the closest color table entry and stored as a 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 exhibit the same behavior.

Similarly, DWG 2004 gradient fills 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 2 gradient colors.

MText in DWG 2004 files can contain tabs and indentation values. These items are not supported in DWG R15 and earlier files, so they will be lost when saving from DWG 2004 back to these versions. This loss can change the formatting and appearance of MText.

Also note that AutoCAD R14 supports only a single paper space layout, and it does not support lineweights (lineweights were added in AutoCAD 2000).

Working with Drawings

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

There are a number of system variables stored in a drawing that are responsible for units and their display. The DWG version in which the system variables were introduced is important. Some DWG file versions do not store all of the system variables so if an older file is loaded, the newer system variables are assigned default values.

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

OdDb::MeasurementValue OdDbDatabase::getMEASUREMENT()

The values returned are:

  • 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()

The values returned are:
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 how angle values display (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 don't linetypes 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 that 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, as follows:

  • 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. But this order can be changed using OdDbSortentsTable methods. If OdDbSortentsTable is taken into account or not depends on value of the SORTENTS system variable.

The Sort Table is returned by OdDbBlockTableRecord::getSortentsTable() for Layout blocks. Note that OdDbBlockTableRecord::newIterator() can return a "sorted" iterator, which takes into account the Sort Table.

  • No labels