TurboCAD Forums

The Ultimate Resource for TurboCAD Knowledge

All posts discussing pricing or where to buy TurboCAD will be deleted.

Is there current life in the SDK?
Read 5745 times
* May 18, 2010, 08:41:36 PM
I'm evaluating CAD packages as the basis for a new development project.

Turbocad meets my CAD requirements, but I'm concerned about the state of the SDK.

1. The documentation appears to be well behind the current version of the product.

2. I can't find official evidence of support for current versions of .NET languages.

3. VBA, which is a dead technology, still appears to comprise the majority of SDK effort.

Now, Turbocad isn't alone in this respect. Only Autocad appears to have current documentation with latest technology support, but the price of that product makes it a scarey platform on which to develop a new product.

The other platform I'm evaluating is Bricscad, but apart from documentation problems it appears to be lurching off into Linux-land, and that makes it unviable as a commercial platform.

Your comments are most welcome.


* May 20, 2010, 04:00:25 PM
Is this an official Turbocad / IMSI forum? Perhaps I'm asking the question in the wrong place.

If not, the lack of activity and attention in the forum might have given the answer to my question.


* May 20, 2010, 06:16:28 PM
In another post in this Forum I pointed out that Microsoft has included VBA in Office 2010, that hardly makes it a "dead technology".  While it is true that VBA was dropped from TCad, as I have pointed out in several posts in this forum TCad can still be automated using VBA from an MS Office product.  My choice has been Excel.

My advice is to take the time to learn the TCad object model using this forum as support.

I recall reading .Net technologies can be used; however, use of .Net requires writing Function Wrappers.

My preferred method of tool creation is to debug VBA code and then write a tool using the VBA code in VB6.  C++ tool creation is also supported and I suppose one fluent in both VBA and C++ would be able to debug in VBA and rewrite in C++.

In my experience people in this forum respond when a question is asked.  You asked no questions and; therefore, received no answers.  Like most programming forums people who post here will be happy to provide help in your programming efforts but they will not do your work for you.

There was a wealth of information in the earlier TCad forum that is no longer accessible.  When or if IMSI will be providing a way to utilize that resource has never been addressed by the IMSI posters on the current forum.  Our fear is the library was destroyed.

My work involves plan views only.  I have found the TCad SDK to be a great help in automating the repetitive tasks that go into making my plan views.  If your interest is in cameras, 3-D and lighting I would suggest you ask others in this forum about those aspects.



* May 20, 2010, 08:44:42 PM
cwcookman, thank you for your reply.

Trust me ... VBA is dead ... my day-time email address ends in "microsoft.com" :)

Microsoft has continued to provide it to keep legacy code executing. You wouldn't want to base any significant new development on it.


* May 21, 2010, 12:47:31 AM
I agree with CWC.
I use vba and vb6. For me it was a delight to read, that Microsoft support vbrun.dll in windows7 – so to use vba and vb6 will work at least the next 10 years. :)

Best regards

« Last Edit: May 21, 2010, 12:49:08 AM by ibruethsch »


* May 21, 2010, 09:10:02 AM
Rondunn, if Microsoft is phasing out  VBA, what are they replacing it with?  I would hope that whatever comes next has the ability to debug code with a method thats similar or better to what we currently have in VBA.

My understanding of SDK coding for TurboCad is that as long as your coding language supports the object model, you can use it to code a TCad tool.  With your close association with Microsoft you should have no problem finding a language and a coder that fits your purpose.

You might have missed my point regarding  VBA.  I use it to easily code and debug a new tool.  It works for me.  I suppose there are other ways that work for others.

In my opinion just because company declares their newest product to be vastly improved over the last, that does not necessarily make it so.  For the time being I will stick to my outdated VBA debugging and recoding in VB6 to create the tool dlls that work in TCad.  If you find another coding environment that is better, I would love to hear about it.



* May 25, 2010, 10:25:15 AM
With regard to .NET, we are well along in implementing .NET wrappers for the SDK. I expect these to be made available to the public sometime this year.

The advantages of the .NET wrappers will be that, in many cases, you will get more efficient type matching to the underlying code, compared to what you get automatically when you reference TurboCAD's COM dlls.