Hi there (hope this is in the right area)
Very green to the whole LISP and VBA thing, so please be patient. We are currently running a standalone (custom coded for us) utilty that extracts info from a CAD drawing. Has worked great since 2006 until now.
We are upgrading to Windows 7, and this utility seems to choke on the 64 bit Windows platform. Works flawlessly on a 32 bit XP machine
We I start the extraction (just a cross window on CAD, I get the follwing error"Error loading ActiveX DLL"
When I look at the LISP I can see the area where the stumbling block is, but dont have the foggiest idea how to fix it.
Is this a 64 bit Windows 7 issue or a DLL issue or VBA..........or wayyyy deeper than that.
thanks in advance for any advice or if more info is required.
snippet of my LISP below (that contains the error)
;
; This function initializes the activeX interface
;
(defun initActiveX ()
(if (car (atoms-family 1 '("vl-load-com"))) (vl-load-com))
(setq vbApp (vlax-get-or-create-object "HHSBAcad.HHSB"))
(if (not vbApp)
(progn
(princ "\nError loading ActiveX DLL.")
nil
)
T
)
)
;
; Process the data from the appropriate title block and pass it to the activeX instance
;
(defun processTBlockData ()
; Now you need to build the list of attribute data for the titleblock
(setq tblockdata "")
(setq ss nil)
; Select the appropriate title block
(setq ss (ssget "X" (list (cons 0 "INSERT") (cons 2 TBlockName) (cons 410 PSpaceLayout))))
You didnt say what version of AutoCAD you were running. Prior to 2014 VBA came in 32bit only so to run in a 64bit machine it had to run out of process which caused it to be very slow. The good news is that with 2014 VBA has a shiny new 64bit version and runs better on 64bit machines. I believe that Autodesk is still hinting between the lines that you upgrade your code from vba to .net however. Who knows how long down the road it will be but VBA will probably be leaving AutoCAD at some point.
Hi Keith
We are running Autocad Architecture 2012.
The application that is the trouble is a third party piece of software that extracts very specific information for CAD. It blows up on the extraction process.
We got some prices on getting this application re written in .NET, and wow, it is going to cost quite a bit.
For the time being , we are just trying to get it to work on Windows 7 with ACA 2012. Our company is just rolling out W7 now, and I need to get this working or we will have several people not able to do their job.
Another had mentioned that I might need to get the .dll re-coded for 64 bit, so not really 100% sure what to to make that happen.
Perhaps the new CAD 2014 will run it better with the new VBA version.
Matt
Hi Gary
Fortunately, we do have the original source code.
Unfortunately, I have very limited experience and knowledge in updating these references. Do not think it is in my range of skills.
Might have to consult with someone that specializes in this coding to get this utility updated. Unless of course there is "Updating old software to run better on 64 bit systems for Dummies" book available.. lol
I do appreciate you input.
cheer
Hi Gary
Thanks for your comments
Upon further investigation (I am not an expert by any means), we are indeed talking VB6, not VBA.
Now the question is.
If this program was written in VB6 on a 32 bit machine, can it be re-complied to run on a 64 bit?
Will AutoCad load a 32 bit ActiveX dll in a 64 bit environment?
Sorry for leading anyone astray
Matt
@matt_HH wrote:Hi Gary
Thanks for your comments
Upon further investigation (I am not an expert by any means), we are indeed talking VB6, not VBA.
Now the question is.
If this program was written in VB6 on a 32 bit machine, can it be re-complied to run on a 64 bit?
Will AutoCad load a 32 bit ActiveX dll in a 64 bit environment?
Sorry for leading anyone astray
Matt
Yes and No, it won't be that simple, but it can be modified and updated and without rewriting the entire thing using the .net managed Acad/ACA Components.
The first job will be to retarget for the 64 bit processor (and fix the minor issues that will occur as a result), then the upgrades in coding requirements from VB6 to Visual Studio VB.
If you stay with the ActiveX (COM) objects (and this is all assuming that the dll was written using ActiveX components, which I believe should be the case as I THINK that .net and managed components were part of the change that was introduced with the migration of VB6 to Visual Studio and the open exchange between VB/C#/C++ code bases) then the .net version becomes less important so the version of Visual Studio also becomes less critical (as the ActiveX components are not .net version dependent as the "managed" MS .net functions are)
Bottom line: If it's "mission critical": upgrade the utility from VB6 to Visual Studio VB for the "quick and less expensive interium fix", but you should consider budgeting for the fuller cost of rewriting it for the .net managed libraries as there are more abilities and the majority of Adesk's coding enhancements are going into .Net over the ActiveX (COM) interfaces... else If it isn't "mission critical" consider finding alternative add-ons.
-Gary