Runninb VBA macro from a script

I've seen lots of topics about running scripts and lisp from VBA but none about running VBA from a script.

I haven't got it to work yet and I don't know if it can't be done or if I just have the wrong syntax. I've tried:

_.open "K:/Test/Test.dwg"
(load "C:/LFD") LFD
_.purge All * No _.qsave _.close Yes
_-vbarun "Module1.GetRestoreFileStamp" "K:/Test/Test.dwg"
_.open "K:/Test/EndTest.dwg"

and also:

_.open "K:/Test/Test.dwg"
(load "C:/LFD") LFD
_.purge All * No _.qsave _.close Yes
(command "-vbarun"
"Module1.GetRestoreFileStamp" "K:/Test/Test.dwg")
_.open "K:/Test/EndTest.dwg"

Neither executes the VBA code nor produces an error message. Both open Test.dwg, run the lisp routine and the purge before closing the drawing. Both then leave _.open at the command prompt.

The project is already loaded. If I paste the vbarun line directly to the command prompt the macro executes properly.

I am using 2002 ADT 3.3 and we have 2004 & 2005 in the office.

Can this be made to work?

Thanks

 

Script line should look something like this:
(command "vbarun" "Acad_Projects.dvb!Project1.Module1.Test ")

if you are trying to pass the drawing name to the macro as an argument, see
an Autodesk Knowledge Base article titled
"Passing arguments to a Visual Basic for Applications (VBA) macro"
--
John Goodfellow
irtfnm - (currently accepting projects)
use john at goodfellowassoc dot com

about running VBA from a script.

just have the wrong syntax. I've tried:

Test.dwg, run the lisp routine and the purge before closing the drawing.
Both then leave _.open at the command prompt.

command prompt the macro executes properly.

 

While it'll work, the question is why would you want to? The rule of thumb
is never mix your programming environments if you don't have to! And when
dealing with files, vb is far easier than lisp or shelling to dos and
generating a text file.

For Each File In myList
With ThisDrawing
.Application.Documents.Open File
.PurgeAll
Call Module1.GetRestoreFileStamp(File)
.Close True
End With
Next

Neater, cleaner, faster.

Now that didn't take LFD into account but I bet it can be optimized as well
in vb - you just need to take the time.

-- Mike
___________________________
Mike Tuersley
___________________________
the trick is to realize that there is no spoon...

 

I checked the Knowledge Base article you mentioned. I already had the GETSTRING construct in my macro.

I modified the script file line to:
(command "-vbarun" "C:/FIND_FIRST/A5FileTime.dvb!Module1.GRFS" "K:/Test/Test.dwg")

The script still stops without executing the macro. If I cut and paste this line to the command prompt, it executes correctly.

Do you have any further thoughts?

 

I had already developed the lisp code I needed to select the files for processing and to write the script files over several years. The need to run the VBA macro came recently, so I hoped to call it from the script file rather than learn enough VBA to convert the associated lisp routines.

In the absence of legacy code, I concur that it is better not to mix environments

Thanks for the input.

 

It appears to me to be the "close" command that is causing the problem.

With a drawing other than Test2.dwg current, this script runs the macro
(handling the param correctly):

_.open "C:/Acad/Test/Test2.dwg"
-purge All * No
qsave
(command "-vbarun" "Test2.ThisDrawing.Test2" "ParameterString")

This one displalys the behaviour you noted:

_.open "C:/Acad/Test/Test2.dwg"
-purge All * No
qsave
close Yes
(command "-vbarun" "Test2.ThisDrawing.Test2" "ParameterString")

As for a fix? Umm, I dunno. Moving the macro code to a public module (out
of ThisDrawing) does not appear fix the problem.
--
John Goodfellow
irtfnm
use john at goodfellowassoc dot com

GETSTRING construct in my macro.

this line to the command prompt, it executes correctly.

 

Thanks for looking into it.

I have run the script successfully on 100 files at a time with the 'close' but without the macro (Always starting with Drawing1.dwg as the current drawing).

Strange that there is this incompatability when trying to run the macro.

I guess I'll have to look at a full VBA implementation.

Thanks again,

Allen