The future of VBA in BricsCAD?
Hi everybody!Since VBA in general is dwindling and in AutoCAD it is not even anymore installed by default, I wonder how the future of VBA will look like in BricsCAD. And if there will be a "substitute" for it.Are there any plans about the future of VBA in BricsCAD as of yet?Regards, Stephan
Comments
-
Hi, Stephan,at least, Microsoft still continues to update the VBA runtime license to any licensee ... so at least, in near future, there is no technical or legal problem to still install and ship VBA runtime with Bricscad.
0 -
Thanks for the info, Torsten!Do I read between the lines correctly, that BricsCAD has no plans yet for the time, when VBA is gone completely, besides the obvious: to let go of VBA without any substitute.Or I sometimes read the letters "VSTA" as a thought of a possible substitute for VBA from Microsofts point of view. Could that be something for BricsCAD?Anyways, for how long, do you, Torsten, suggest, that BircsCAD will still be supporting VBA?
0 -
Let us start by making a distinction between VBA and COM: Visual Basic for Applications (VBA) uses the COM API to accomplish what it does. It runs 'in process', inside the application program process, and the Visual Basic code is interpreted on the fly. Programs that use the COM API may be written in languages other than VB, e.g. C++. These programs can run 'in process' as Add-Ins, or out of process, which is a slower but more typical use of the COM API. Also our built in Lisp-VLAX uses the Bricscad COM API.At present we are still extending the Bricscad COM API, and given that VLAX uses the COM API, we definitely do not have any plans to stop supporting the COM API.VBA is a different story: if MicroSoft one day decides to stop selling licenses for VBA (in an attempt to force VSTA down our throats) it will no longer be possible to offer a Bricscad version that includes the VBA environment. It is interesting to see that large companies like AutoDesk don't seem to be in a hurry either to switch to VSTA ...Anyway, what happens to VBA will not influence our continued support for the COM API.
0 -
Thanks, Hans, for your answer!This seems to be a delicate subject for you guys, since you avoid answering my questions directly.So, what I understood out of your two answers is:You don't know for how long the VBA environment will still be included in BricsCAD. It could be for another 10 or even just another 2 years. But once it is discontinued, there will likely be NO other new developing environment "in place" of it.Since you will continue to support the underlying COM interface, those who are using VBA now will have to switch to AutoLISP, C++ or any other supported language, using the COM interface from there. Or they decide to anyways switch to using BRX with C++ only. But in both cases they better start merging from VBA now, since nobody knows, for how long VBA will still be around.Did I get that right?
0 -
This time, lets start by making the distinction between VB and VBA. Visual Basic for Applications uses the Visual Basic language to write (powerful) 'macros' to customize applications. The next generation of this VBA customization environment is VSTA.So, discontinuing the support for the VBA customization environment is not equal to discontinuing the support for the Visual Basic language or the VB compiler. Compiled Visual Basic programs can and will continue to use the Bricscad COM api without any difference.The reason we cannot guarantee how long support for the integrated VBA will continue is simple: it is beyond our control.
0 -
I did some googling on the topic and found some references that might be interesting to you.1)OK, the statement is more than one year old, but on MSDN Microsoft stated they "have no plans to remove VBA from future versions of Office for Windows. We understand that VBA is a critical capability for large numbers of our customers; accordingly, there is no plan to remove VBA from future versions of Excel."(http://blogs.msdn.com/excel/archive/2008/01/16/clarification-on-vba-support.aspx)2)Without mentioning any source MAGINiT Technologies seems to know that Autodesk "encourages all VBA using developers to not write any new VBA code - and to use VB.NET instead to insure your code is "future proof". "(http://www.rand.com/imaginit/1/rss/viewitem.asp?feedid=BLOGS_GIS_ALL&guid=596)3)VBA programmers probably go VB.NET(http://discussion.autodesk.com/forums/thread.jspa?threadID=718885&tstart=120)
0 -
Thanks, Hans, for your coninued aswering!You wrote: "Compiled Visual Basic programs can and will continue to use the Bricscad COM api without any difference. "Does that mean, that once the VBA-IDE is gone, you can still start and use old VBA-macros without changing them? (I am asking because you write "Visual Basic programs" and not "VBA programs".) Or will any old VBA-macros/programs have to be transferred to (maybe rewritten in) the "normal" version of Visual Basic (whether dotnet or not).My whole concern is about any already existing vbA!!-Code. It is not about the COM interface.
0 -
Hello, Stephan,to provide some more clearance - regarding VB and VBA.Both is virtually the same language :-)So the efforts to "convert" VBA into VB (with/without .NET) are extremely small, so it is not a problem to switch from VBA to VB - if ever nessecary.The main difference between VB and VBA is, that VBA is strictly (and only) "interpreted" by a VBA runtime interpreter ... this is, what the VBA license includes; and this is what Microsoft will continue for a longer time, as documented above.As long as Microsoft provides that VBA runtime system (and therefore, also continues existing licenses), as long VBA will be present in Bricscad.If, at one day, Microsoft stops licensing VBA and therefore, does no longer allow to (re)distribute that VBA runtime system, then it might be nessecary to switch the VBA code to VB - the most logical step; even the IDEs are quite the same ... with the advantage, that VB can be interpreted and/or even be compiled, and the code can run "in-process" as a DLL or "out-of-process" as an EXE.So in my opinion, there is no need to worry about VBA at the moment ... and personally, I guess, that VBA is provided at least for a few years.Many greetings, Torsten
0