TCDRC - TC Developer Options

In this section ...

Options for adding Content/Functionality to TurboCAD

Symbol/Block Libraries
VBA Macros
Addon DLLs
TC Clients
VBA Macro to VB5/6 Pro development pathVBA Prototyping

Compiled Language Options (applies to DLLs only)

Visual Basic 5/6 Pro
.NET languages
VB Script

General Considerations for creating DLLs


Options for Adding Content and Functionality to TC

There a number of ways third parties can add to the content or functionality of TurboCAD. You may choose to do this for your own use, as freeware for all users or on a commercial basis.

Symbol/Block Libraries

This web site is mainly focused on TC Development, but while strictly seeking Symbols really fall under the umbrella of 'Content Creation' I mention them here because it is not uncommon for Development and Content Creation to go hand in hand. Depending on the project, it may be possible to save a lot of cold coding by distributing it with a few specialised Symbols/Blocks/Templates etc. So keep them in mind. Also making Symbol or Block Libraries is one if the easiest ways to add functionality to TurboCAD, and anyone can do it.

A common practice is to make Symbols of Blocks, and add a number of Block Attributes. Then when the symbol is dragged into a drawing, the user will be asked to fill in fields for the Block Attributes. It is also possible to use Symbols to drag in new versions of Blocks already in the drawing (with the same name), and in this way automatically update the appearance of all instances of those blocks.

The TC documentation is quite good in this area. Probably the main thing to note is that in general, all parts of a Symbol should be on Layer_0 ... otherwise all the layers will automatically be created when it is dragged into the drawing. Pay particular attention to Symbols/Blocks with nested graphics.

VBA Macros 

VBA Macros are the first level of TC Development.

Addon DLLs

TC Clients

Prototyping with VBA

Particularly if you are going to be using Visual Basic as the language for your DLL, one of the best ways to go IMO is to prototype it first as a VBA macro. The VBA editor is a very convenient way to create and debug basic code, because it's always available in TC.

Once you have the majority of the functionality sorted in the macro, creating the dll becomes a more or less automatic process of creating the shell for the project and copy/pasting from VBA to VB-proper. 99% of the code should copy without need for modification. Unfortuneately, the forms will not and you will need to redraw them, so keep this in mind.


Compiled Language Options (applies to DLLs only).

Visual Basic 5/6 Pro 

Due to the ability to prototype with VBA, IMO VB5 Pro or VB6 Pro are currently among the best options. You get the idea, test it with a macro, convert it to a dll with VB, all with a minimum of fuss. Note this is not the case with Visual Basic.NET (see below).

The VB debugging environment is good too, though it's a bit of a pain switching between running the compiled .dll vs the .vbp file. What you have to do to debug is make sure the the project's .vbp file is in the appropriate TurboCAD folder (delete the compiled .dll if necessary), then click Run in VB, then start TC ... then you should have your project running in debug mode. When satisfied do final testing, recompile the .dll and restart TC without the project running in the VB environment.

One disadvantage is that VB's older forms libraries (and maybe others) are beginning to be superceded. Whereas once you could almost guarantee to find them on users computers this is no longer the case, so it looks like in the future you will need to supply a full install package that includes all the runtime .dlls.


There was time when you might have chosen C++ because of it's speed advantage, but that is not so significant now that VB, Delphi are compiled languages, and in the particular context of developing dlls for TC the speed advantage is probably almost non-existent.

The prime advantage of using C++ instead of something like VB is that it has a greater level of control and flexibility. The automation of VB is great most of the time but when it's automating in a way that doesn't suit you, there isn't much choice. In C++ you can go into the generated code and change it if you need to. For example it doesn't seem to be possible to have two regen classes in the one VB generated dll, whereas it is possible with C++. C++ is also more flexible in the libraries it can use - there are a few in the TC SDK that can be used with C++ but not with VB.

The disadvantage of course is that all this extra flexiblity puts extra reponsibilities on the programmer not to go doing things that will break peoples computers. Whereas the advice above to get a book on COM/OLE programming is desirable with VB it's pretty much essential in order to even get started in C++. This goes the other way too though ... the deeper understanding required to use C++ can be an advantage because it reveals more opportunities as well. It is also considerably more difficult to program (IMO) and the sheer scale of waht's available in C++ is overwhelming at times (there must be at least a dozen different types of strings -which one to use?). In practice the extra flexibility in C++ is not often used in TC development, but it is now my preferred language anyway 'just in case I need it'.

Here is a short summary of the most popular C++ compilers.

VC's MFC library is a big Application Framework that has the ability to do COM/OLE as well, and also has a bit of a reputation for creating 'bloatware'. It is very usable for creating DLLs targeted at TurboCAD, and most of the C++ examples in the SDK are MFC.  Also I believe that TurboCAD itself is coded in MFC, so pretty much all of the required libraries will already be on the user's system ... so in the case the resulting DLLs should be a reasonable size.

VC's ATL is a much smaller library specifically targeted at producing COM/OLE classes, it does it's chosen task very well and without all the overhead of MFC. It also is a good language for vreating DLLs for TurboCAD, though there are fewer examples in the SDK. It does not have the built in Dialog tools found in MFC ... to make dialogs you have to get a copy of WTL which is a windowing library that uses the same methods as ATL and fits in with it very well. Caution though, while WTL is created by a Microsoft empolyee on comanpy time, it is not officially supported by Microsoft.  (ATL/WTL is what I use. DB.)

In general it's best to avoid .NET languages (see below). However note that C++ is a bit of  an exception, because it allows you to switch off the .NET 'feature' to produce 'normal' code. What is often called MS VC++.NET actually is the latest version of MS's C++ complier and includes all the MFC/ATL functions described above (at time of writing anyway).

Sorry, I am going to have to ask someone with experience to contribute here. I think there are a couple of BCB examples in the SDK, but at this stage I don't know of anyone who has a working TurboCAD addon DLL produced from the more recent versions of BCB, and I know one person who has tried unsuccessfully at this stage. If anyone knows different please share your secrets! BCB should work.

Anyone know?


Again, I have no experience with Borland Delphi, though I believe there are people using it. If anyone has Delphi experience does please share it. Delphi should work.

.NET Languages (VB.NET, C#.NET etc)

There is a problem with all .NET languages (except C++.NET see above). In theory they should work via .NETs COM Interop features ... but in practice they don't work out of the box for TuirboCAD addon DLLs.  Don't really know what the problem is, but it may have something to do with needing the .NET framework already loaded when TurboCAD starts loading the DLLs. Anyway my conclusion is it's best to avoid .NET languages until TC supports them directly. I don't think it matters which particular flavour of .NET languages, as they all run off the same framework.

If you really insist, .NET languages can be made to work by providing a wrapper DLL (usually done in C++), that TC loads and then in turn loads the .NET component that has the real functionality. There is an example in the later SDKs. It may also be possible to create a single wrapper that loads several .NET DLLs.

** This is a bit of a shame by the way, because when MS released .NET some of their older languages got discontinued. So if you want to use one of the best TurboCAD languages (VB6 Pro) you can't buy it ... instead you have to buy VB.NET which is practically useless! So it's off to EBay :-) **

VB Script

Well I believe VBScript is possible in theory. The problem is there is really no debugging environment for VBSript that I know of. So you try it, it doesn't work, and you get a helpful message like "Script Failed" or something. For anything beyond simple projects it just isn't practical. I think there is an example in the SDK, and that it works for Tools and Regens only.


General Considerations for creating DLLs

Q: Can a dodgy DLL crash TC?
A: Yes.

For (I think) all of the Addon DLLs listed above, what you are creating is a Windows COM/OLE Server. When placed in the correct TC folder, each instance of TC will create a single instance of that class when it starts up, and call it's functions as required. Also note that while TC initialises the process, COM/OLE objects are actually created/destroyed by Windows - not by the application directly. This has a few implications.

Firstly, get a big book and read up on COM/OLE before you start. There is a lot going on behind the scenes with these suckers. With some languages like C++ that require more manual programming you simply have to read up on it to make sure you don't break something. With other langauges like VB a lot of it is done automatically, but it is still worthwhile taking the time to understand the system.

Second, when starting a new project/class, it is bad practice to simply copy complete projects/classes to a new folder and modify from there. Instead always create a new project/class from scratch, and copy/paste code only from the old project to the new. The reason is that when Windows creates an instance of COM/OLE objects, it does so by finding them in the Windows Registry. If you have two DLLs with non-unique registry values, it could lead to unexpected results. When you create a new project/class most programming environments automatically creates various unique Registry values for you at the same time. They are pretty easy to find in C++, but they are in VB too even if they are hidden. Anyway copying a complete project breaks this system, and means that there may be two or more copies of the supposedly unique values floating around. Windows can be a bit touchy about these things.

Third, take particular care with global variables. Depending on how they are declared, global variables may be available to all instances of the class. In other words, if you start more than one instance of TC, the exact same variable would be used for all of them, which may not be what you expect. For example they are not appropriate for holding dialog values becasue one instance of TC can affect dialogs in another TC instance (generally bad but not illegal). A second consideration with global variables with COM/OLE classes when using C++ is that the above implies that they must be thread-safe in case two instances try to access them at the same time (this handled automatically if you use VB). Class level variables are generally better, but in VB at least they can't be used as a proxy for moving data between forms and modules, and whether they are always thread-safe might depend on the programming language. So the moral is read your programming language documentation and use global/class level variables with care.