C# .Net

John Finlay

Does BricsCAD have the same ability as AutoCAD's C# .Net?

Luc De Batselier

Hi John,You can call the COM API from a C#.NET application, I know of existing applications that are doing this today.However, this is not yet available in Bricscad:- Managed object wrappers for the C++ BRX API (analog to wrappers for ObjectARX)- The NETLOAD commandBest regards,Luc De Batselier

Its_Alive

Here is a netload command you can use with Bricscad, I have also wrapped some stuff see. http://www.intellicad.net/forum/topics/a-little-net-and-bricscad

John Finlay

Thank you all for your assistance.Regards

Terry Dotson

I would like to add a vote for a Bricsys supported .NET API including all wrappers, events and a NETLOAD command.

Its_Alive

Vote++although, I am having great success doing mixed managed/unmanaged applications …the best of both worlds.

Terry Dotson

Daniel, I tried the example you provided and it looks great. Whats the possibility of Bricsys picking this up and maxing it out and supporting it?About 6mo ago we switched to .NET for all our new code and we would like to provide the new products on Bricscad as well.

Luc De Batselier

Hi everybody,Thank you for all the interest and feedback !Some explanation of where we are today:First of all, we advise NOT to switch to .NET, as long as the managed wrappers for our BRX API are not available. The BRX SDK is 100% code compatible with the ObjectARX SDK, so it allows you to run the same unmanaged ARX based C++ code on both the Bricscad and AutoCAD platform. If you switch to .NET today, we can not offer support for your application that calls ObjectARX managed object wrappers. Please understand that the BRX API is a huge development, it's done entirely by Bricsys and it's unique for the Bricscad plaform. To give an idea, the total amount of functions offered inObjectARX is about 22.0000 (!). We are already supporting a good base set of 3000+ functions,included support for advanced items such as reactors, MDI, AcEdJig, input point monitor,custom objects and entities, deep cloning, transactions, etc... all fully code compatible andcovered by our in-house automated testing system. With this set we already have multiple ARX applications running today, but we also have are hands full with adding more and more functionality to support the larger applications. We estimate that the "critical mass" of functions is about 4000-5000, with this amount we should be able to support the majority of ARX modules.This is our first target, after that we can start to add managed object wrappers in BRX for completeness. But the demand for more unmanaged BRX support today is substantially higher, than the demand for managed object wrappers. So please bear with us, know that we are working hard to extend the amount offunctions in BRX. We are determined to support as much as applications as possible, butwe need to select our priorities carefully to make the best use of our development resources.After all, before we can make "object wrappers", those "objects" need to be fully functional in the first place, isn't it :-)Best regards,Luc De Batselier

John Finlay

My understanding is that Microsoft has stopped support for VBA and Visual Studio Tools for Applications (VSTA) will take over. VBA and VSTA will be able to run along side each other during the transition period.Will Bricscad be transitioning into VSTA?

Hans De Backer

Probably, but it is not considered a priority.

Jerry Johnson

Sounds like you may be trivializing high level languages (i.e. VB.Net, C#) because of the lack of managed code staff? This while you know that more and more of the ACAD code is being opened to managed code. Are you afraid that by the time you code in low level that the code and ACAD compat. will be obsolete? ARX is likely not the future! A really open cad engine is what programmers are looking to use. Innovation comes from the oddest sources.

Its_Alive

Jerry, With all due respect, The low level ARX/BRX code base will need to complete before Bricsys can start making managed wrappers. The low level code will never be obsolete because it is the foundation where the other APIs are built I.e Lisp, COM and eventually Managed .NET., We just need to be a little patient while Bricsys finishes up the foundation. Having said that, I see no reason why people can’t party on top the COM API with .NET since Visual studio will automatically generate he wrappers for COM..