Tx

Teigha: A library provided by the Open Design Aliance (www.opendesign.com), to read and write DWG files, generate graphic display objects of DWG entities, fire database related reactors, etc... BricsCAD is based on this library. The full library is only available for ODA founding members, such as the Bricsys company.

TX SDK: A free C++ SDK, consisting of the headers and libs of the Teigha library, and provided by the Open Design Aliance. The runtime dlls are not included in this SDK. Those are installed with the BricsCAD product. This SDK can be downloaded freely on the public section of the ODA website (www.opendesign.com). BricsCAD is based on a Bricsys-adapted version of the Teigha libraries, as a consequence BricsCAD is NOT compatible with the ODA version of the TX SDK.

Bricsys TX SDK: The Bricsys-adapted version of the TX SDK, compatible with BricsCAD. To get access to this SDK, please contact Bricsys Support.

Bricsys is working closely with the ODA to merge away all code differences as much as possible. Still, TX modules for BricsCAD need to be compiled with the Bricsys TX SDK to guarantee full compatibility.

The Bricsys Teigha eXtension (TX) SDK enables to produce C++ based TX module files, which can be loaded to run in BricsCAD. Typically, such modules have the extension ".tx".

In versions prior to BricsCAD V12 these modules where called .drx. A drx file can no longer be loaded in current BricsCAD version; the source code needs to be recompiled to *.tx using the latest TX SDK.

Binary compatibility for TX modules can not always be maintained accross different BricsCAD versions, even within one major release cycle. Whenever breaking changes are introduced, a new Bricsys TX SDK version is made available. Application developers should be aware that TX based modules require more frequent recompiling and version-specific distributions compared to other API's.

If you consider to work with the TX SDK, please read the following sections carefully. This documentation is intended to help you make the best decision for your application strategy, in particular the choice of API.

There might be some confusion, about how exactly TX and Teigha relate to ObjectARX. In this section, we hope to give you a clear view on this subject.

At first sight, the TX classes, methods and functions look very similar to the ones found in ObjectARX. If you look at the help files or headers delivered with the TX SDK, you will recognize a lot of things when you have some experience in ARX development.

However, there are a number of fundamental differences that can be summarized as followed:

To illustrate this, please compare following code samples. The objective of the sample is simple: add a new line entity to the active drawing.

How it's done in ARX:

How it's done in TX:

Note: The differences with the corresponding ARX code are added as comments in the code.

void createLine()
{
//1. message to command line
acutPrintf(ACRX_T("\nCreating a new line entity..."));

//difference: command function needs command context argument.
void createLine(OdEdCommandContext* pCmdCtx)
{
try
{
//1. message to command line
//difference: requires a command context and OdEdUserIO instance.
OdEdUserIO* pUserIO = pCmdCtx->userIO();
pUserIO->putString(_T("\nCreating a new line entity..."));

//2. get active database
AcDbHostApplicationServices* pServices = acdbHostApplicationServices();
AcDbDatabase* pDb = pServices->workingDatabase();

//2. get active database
//difference: the active database is provided through the command context.
OdDbCommandContextPtr dbCmdCtx = OdDbCommandContext::cast(pCmdCtx);
OdDbDatabase* pDb = dbCmdCtx->database();

//3. get model space BTR
AcDbBlockTable* pBlockTable = NULL;
pDb->getSymbolTable(pBlockTable, AcDb::kForRead);
AcDbBlockTableRecord* pBlockTableRecord = NULL;
pBlockTable->getAt(ACDB_MODEL_SPACE, pBlockTableRecord, AcDb::kForWrite);
pBlockTable->close();

//3. get model space BTR
//difference: the modelspace BTR is provided through its object ID.
OdDbObjectId modelSpaceId = pDb->getModelSpaceId();
//difference: entities are opened by calling a method on the object ID.
OdDbBlockTableRecordPtr modelSpace = modelSpaceId.safeOpenObject(OdDb::kForWrite);

//4. create new line entity
AcDbObjectId lineId;
AcGePoint3d ptStart(0.0, 0.0, 0.0);
AcGePoint3d ptEnd(10.0, 10.0, 0.0);
AcDbLine* pLine = new AcDbLine(ptStart, ptEnd);

//4. create new line entity
OdDbObjectId lineId;
//difference: you can not call the constructor of OdDbLine, you need to call the OdRxClass::create function to construct objects.
OdDbLinePtr odLine = OdDbLine::desc()->create();
//difference: you can only set the start and end point of the line, after it has been created. There are no argument constructors.
odLine->setStartPoint(OdGePoint3d(0.0,0.0,0.0));
odLine->setEndPoint(OdGePoint3d(10.0,10.0,0.0));

//5. append entity to model space
pBlockTableRecord->appendAcDbEntity(lineId, pLine);

//5. append entity to model space
//difference: the object ID of the line is returned, not passed as an argument.
lineId = modelSpace->appendOdDbEntity(odLine.get());

//6. close all objects
pBlockTableRecord->close();
pLine->close();
}

//6. close all objects
//difference: in TX there are no calls here, all objects are smart pointers so they don't need to be closed explicitly
}
catch (...)
{
//difference: exception based error handling. For the clarity of the sample, error handling has been minimized.
OutputDebugString(_T("\nTeigha exception"));
}
}

Conclusion: even for a simple operation, such as adding a line to a drawing, there are differences in nearly each line of code, which can not be worked around. As a consequence, maintaining an ARX and TX version of your application, will require two separate sets of source code !

To overcome the differences explained above, Bricsys has developed another C++ API that is fully code compatible with ObjectARX. This API is called "BRX", the BricsCAD Runtime eXtension.

We strongly recommend to use this API for C++ client applications. The advantages compared to TX can be of major influence for reducing the time and resources spent to bring your application to the BricsCAD platform:

For more information, please check the BRX section of this developer reference. In case you do prefer to work with the TX SDK, please find some important information listed in the following paragraphs.

Bricsys is a founding member of the Open Design Alliance (ODA), and therefore has access to all the source code of the Teigha libraries. In order to bring BricsCAD to the level of high quality CAD platform it represents today, some parts of the Teigha libraries were adjusted or extended by Bricsys, for different purposes:

In all of this, it's not possible to keep the Teigha runtime libraries that are installed with BricsCAD 100% binary compatible with the TX SDK as provided by the ODA. Therefore, Bricsys distributes its own version of the TX SDK that is fully compatible with BricsCAD.

The SDK is not available for download on the Bricsys website. To get access, please contact Bricsys Support.

A detailed manual and reference guide can be downloaded from the public section of the ODA website, (www.opendesign.com).

In the BricsCAD install folder, a TX sample application is provided that illustrates some BricsCAD-specific functionalities.

In the API folder that is installed with BricsCAD, you can find some header files that contain useful extensions to the TX interfaces. As explained above, these are mainly extensions required to provide access to some important functions of the editor environment of the CAD platform:

Modules that make use of the extensions, should link with odapi.lib, bricscadapi.lib, bmapi.lib which can be found in the same API folder.

How it's done in ARX:	How it's done in TX: Note: The differences with the corresponding ARX code are added as comments in the code.
void createLine() { //1. message to command line acutPrintf(ACRX_T("\nCreating a new line entity..."));	//difference: command function needs command context argument. void createLine(OdEdCommandContext* pCmdCtx) { try { //1. message to command line //difference: requires a command context and OdEdUserIO instance. OdEdUserIO* pUserIO = pCmdCtx->userIO(); pUserIO->putString(_T("\nCreating a new line entity..."));
//2. get active database AcDbHostApplicationServices* pServices = acdbHostApplicationServices(); AcDbDatabase* pDb = pServices->workingDatabase();	//2. get active database //difference: the active database is provided through the command context. OdDbCommandContextPtr dbCmdCtx = OdDbCommandContext::cast(pCmdCtx); OdDbDatabase* pDb = dbCmdCtx->database();
//3. get model space BTR AcDbBlockTable* pBlockTable = NULL; pDb->getSymbolTable(pBlockTable, AcDb::kForRead); AcDbBlockTableRecord* pBlockTableRecord = NULL; pBlockTable->getAt(ACDB_MODEL_SPACE, pBlockTableRecord, AcDb::kForWrite); pBlockTable->close();	//3. get model space BTR //difference: the modelspace BTR is provided through its object ID. OdDbObjectId modelSpaceId = pDb->getModelSpaceId(); //difference: entities are opened by calling a method on the object ID. OdDbBlockTableRecordPtr modelSpace = modelSpaceId.safeOpenObject(OdDb::kForWrite);
//4. create new line entity AcDbObjectId lineId; AcGePoint3d ptStart(0.0, 0.0, 0.0); AcGePoint3d ptEnd(10.0, 10.0, 0.0); AcDbLine* pLine = new AcDbLine(ptStart, ptEnd);	//4. create new line entity OdDbObjectId lineId; //difference: you can not call the constructor of OdDbLine, you need to call the OdRxClass::create function to construct objects. OdDbLinePtr odLine = OdDbLine::desc()->create(); //difference: you can only set the start and end point of the line, after it has been created. There are no argument constructors. odLine->setStartPoint(OdGePoint3d(0.0,0.0,0.0)); odLine->setEndPoint(OdGePoint3d(10.0,10.0,0.0));
//5. append entity to model space pBlockTableRecord->appendAcDbEntity(lineId, pLine);	//5. append entity to model space //difference: the object ID of the line is returned, not passed as an argument. lineId = modelSpace->appendOdDbEntity(odLine.get());
//6. close all objects pBlockTableRecord->close(); pLine->close(); }	//6. close all objects //difference: in TX there are no calls here, all objects are smart pointers so they don't need to be closed explicitly } catch (...) { //difference: exception based error handling. For the clarity of the sample, error handling has been minimized. OutputDebugString(_T("\nTeigha exception")); } }