Lisp/VBA grief

[matt_HH]

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))))

[Keith.Brown]

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.

[matt_HH]

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

[Gary_J_Orr]

You don't HAVE to have it rewritten for .net, but you DO need to have it updated for the OS and OS architecture and, when you upgrade to 14 it will require additional upgrades (both of which will be a matter of updating the references for OS and Acad version)...

If it was written SPECIFICALLY FOR YOU then you should have access to the original code (unless the contract for development stated that the source code rights stayed with the developer), if it was a purchased product then such belongs to the developer so you're out of luck if you can't get an updated version from them.

If you do have access to (and the right to modify) the source code then it doesn't take all that much to change the references, tweak the few things that will break due to those new references, and recomplie a new version targeted to the correct OS and Acad version.

-Gary

[matt_HH]

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

[Gary_J_Orr]

well, that cuts down on the:
"We got some prices on getting this application re written in .NET, and wow, it is going to cost quite a bit."
portion considerably.

Anyone worth their salt as an Acad VB/VBA Developer should be able to update the references for 64 bit, then recompile the function as <OldName>-64, then change a few more references to prepare you for the '14 upgrade and recompile as <Oldname>-2014-64...

Of course I just realized that you are referencing VBA (for some reason I got to thinking VB and dll's)... in that case, if it truly is VBA (the coding is done inside of Autocad's VBA editor) it gets even easier... and shouldn't take more than half a day to open the file from the VBA module of AutoCAD on a new workstation, fix anything that's broken due to the subtle differences between 32 and 64 bit, then save as a "...-64" version for using on the 64 bit workstations...

-G

[matt_HH]

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

[Gary_J_Orr]

---

@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