Possible to program macros without AutoCAD installed?

[smith101]

Hi! I am trying to help someone whose AutoCAD Architect VBA macro quit working after upgrading from a 32-bit system (AutoCAD 2010, Office 2010) to a Windows 7 64-bit system (AutoCAD 2012 64-bit with AutoCAD 2010 also installed, Office 2010 64-bit). The macro is used to populate an Excel spreadsheet with square footage by department. They need to be able to run the macro on AutoCAD 2010 (32-bit or 64-bit) since it is the version that they use to edit space tags. (Was this feature lost in 2012?) I am a .NET programmer, I do not have AutoCAD installed. The only download available for a 30-day trial from Autodesk is AutoCAD 2013 - which has file differences from 2010-2012 according to what I have read. Is there any way I can work on "fixing" this macro without having AutoCAD installed? Is there an SDK that would give me the ability to compile and debug (intelli-sense would be nice too)? Am I being naive to think I can re-create the macro using the code from a .txt file? Any thoughts or suggestions would be greatly appreciated!

[hugh.69031]

Short answer is no, with few exceptions you must have the right version of AutoCAD available to allow a VBA macro to run. VBA is being phased out in favour of a .NET based API so is no longer being installed by default (it can still be downloaded and installed from http://usa.autodesk.com/adsk/servlet...linkID=9240618).

I suggest you download and install ACAD 2013 and the relevant VBA module from the above link to investigate the problem in ACAD 2013's VBE and get it going in a 64bit environment. So long as the VBA code does not reference anything in the object model that does not exist in 2010 or 2012 you should be able to port the result to the earlier environment then change the referenced libraries using VBE's Tools>References.

OTOH if you can gain access to the system in question you could investigate the problem at first hand. It may be the problem could be fixed by just adjusting the referenced libraries.

[jsbernholt576976]

Thanks! I am now working on getting a 64-bit system up and running. It may be easier than dusting an old laptop and firing up VB6.

I did spend a bit of time investigating first hand. We tried removing and adding back the "MISSING" references but the changes would not "stick" - we were unable to compile because the menu option was disabled (even after clicking the "reset"/stop button to stop the macro after getting the infamous "Can't find project or file" error message). I think it may be due to the macro being originally compiled in the 32-bit environment but now he is trying to run it in a 64-bit environment without making any changes to the code. I guess my short-term goal will be to make the necessary changes to get the VBA to compile in 64-bit so we can get the data required by the end of the fiscal year (in two weeks); then I can try to rewrite in .NET for future compatibility.

- smith101 (previously pearson850594)

[Ed Jobe]

With vba, some stuff happens automatically. When the project loads, the compiler tries to bind it to the instance of AutoCAD currently running. Then the code compiles against that tlb. This is why you don't have to declare the variables AcadApplication and ThisDrawing. So the reference you checked is still "MISSING" if you checked something other than the current version of acad that you were testing with. IOW, you can't "fix" it on one version of acad and then expect it to run on another version. The Compile menu option was disabled because it already compiled. It only becomes enabled when you make code changes and they have not compiled yet. If you hit Run/F5, it compiles automatically.

[hugh.69031]

Good thing that Ed has a better grasp of the fundamentals.

Seems all you need do is make a trivial change in the VBA to enable the Compile menu option on the original system and click on it to find the next problem.
Just addng a blank to the VBE code editor did the trick here. Compiling disables the meunu item until the next alteration. Worth a try.

[Jeff H]

They might make the jump with VBA7
http://msdn.microsoft.com/en-us/library/ee691831.aspx

[Ed Jobe]

I don't think vba is going away anytime soon. Even MS hasn't gotten rid of it in Office. I was reading the editorial in the June issue of MSDN and there is a huge user base still using VB6, because as the article pointed out, "rewriting functional code nonrecreationally just doesn't pencil out".