BRX Explained

Bricsys released an ARX source-compatible SDK called BRX a while ago. Judging by the number of applications listed at their Applications page, I would say that quite a few third party developers have been using it. However, I have been receiving many questions regarding the BRX SDK from users, especially AutoCAD users, and a few developers as well. From the questions I get the feeling that people have not quite completely understood what “ARX source-compatible” means and how it can affect them. This article is written for end users, but I guess, some developers may find it helpful as well.

Let’s start from the beginning. When Autodesk developed AutoCAD they also created a SDK (Software Development Kit) called ObjectARX, which enabled third party developers to write plug-in applications that work inside AutoCAD. This SDK is basically a set of C++ classes and functions. For sake of simplicity, let’s assume that the ObjectARX SDK has a function called DrawLine. As a third party developer, I can use this function in the C++ code of my plug-in to draw a line in AutoCAD. I simply need to call this function in my plug-in code and supply it with input, in this case, a start point and an end point. But unlike LISP, I don’t give the source code to my customer. I need to build it into an .ARX file (basically a DLL) using the ObjectARX SDK and ship it to my customer, who then loads it into AutoCAD and runs a command which draws the line.

So as you can imagine, AutoCAD users who rely on such ARX plug-ins are virtually tied down to AutoCAD and cannot move to another CAD system unless the developers of the ARX plug-ins they use offer similar plug-ins for the other CAD system as well. Bricsys has decided to solve this problem in a unique way, by means of their ARX source-compatible BRX SDK, the “source-compatible” part of which I am now going to explain.

Say you are an AutoCAD customer and are using an ARX plug-in developed by me. You want to dump AutoCAD and are looking for an alternative. It looks like Autodesk has just given you another reason to do so. You look around and try Bricscad. It seems to fit your bill, both in terms of functionality and cost. But there is a problem. I don’t offer a version of my ARX plug-in for Bricscad. So it appears that you are stuck with AutoCAD. But as a third party developer I see this as an opportunity to make some money and at the same time, widen my product line. I take the existing C++ code of my ARX plug-in and rebuild it using the BRX SDK supplied to me by Bricsys. And behold, I get a BRX plug-in that works with Bricscad. You dump AutoCAD, purchase a license of Bricscad and a license of my BRX plug-in and we both live happily ever after.

But is it as simple and straightforward as that? And here is where all the skepticism and confusion starts. Does the BRX SDK contain each and every function of the ObjectARX SDK? The answer is no. But it does contain almost all the functions that are most commonly used. ObjectARX contains thousands of functions, most of which are rarely used. And frankly, I do not see the point in Bricsys spending their time and resources adding all of them to BRX.

Which begs the question: What happens if BRX does not have a function that my ARX plug-in uses? Take the DrawLine function I mentioned above. Suppose Bricsys has not yet implemented it in their BRX SDK, my BRX plug-in will not be able to draw a line in Bricscad.

Bricsys has a solution for that as well. When I build my C++ code containing unsupported functions I will get compilation errors, which will tell me exactly which functions are missing. I simply need to send the build log file containing these compilation errors to Bricsys. Their engineers will put these functions in the top of their priority list and start working on them immediately. Bricsys regularly releases updates of their BRX SDK, along with the corresponding version of Bricscad. Bricsys will do whatever it takes to add the missing functions as soon as possible. It is in their best interest to do so.

Another thing, Bricsys maintains binary compatibility across the same version of Bricscad. This means that they always add functions to the BRX SDK, never remove them. So I need not worry that a future build of Bricscad V9 will not load my BRX plug-in. Bricscad users are free to download and install updates of Bricscad V9 without having to bother about plug-in compatibility. This also means that I do not need to rebuild my BRX plug-in for each and every update of the BRX SDK. Once I successfully build my plug-in and it loads and runs properly in Bricscad V9, I can forget about it.

So if you are an AutoCAD user and no longer want to be one, Bricsys has a bailout plan specially designed for you. Contact your ARX plug-in developer and let him know about BRX. And if you are a third party developer, BRX may very well turn out to be an opportunity for you. And what’s more, Bricsys is doing all the heavy lifting so that you can sit back and count the money.

I hope this article has helped clear a few doubts about the BRX SDK. By no means do I consider myself an authority on BRX, but if you have any questions, please feel free to ask. If I know the answers I will reply. If I don’t, I will bluff. 😉