VBA calling .EXE with parameter passing -- problem re-executing with ENTER key

Well I know this might sound weird but would anyone know how I can run the last command
I issued which happens to be a macro by pressing Enter key or Space bar?

I know it sounds silly because all commands behave like that right? The last
command you issue can be re-run by simply pressing Enter key. Not so with my eraseentity macro.

This macro runs an .EXE passing an argument to it -- and that is the only thing I am suspecting as the culprit.

Even if my eraseentity macro was the last command run, I cannot seem to get it to re-run like I normally would by pressing Enter.

When I hit enter right after running the eraseentity macro from the command line what I get is this

Command:
-VBARUN
Macro name:

Then I have to type the whole macro name eraseentity.

The reason why I undefined my erase command is so that I can monitor and correctly erase certain entities based on our existing requirements (i.e. line, mtext, point and text entities) triggered by using a lisp routine like the one below but everybody now is complaining to me why they cannot run the erase command anymore by simply hitting enter like
they used to (if erase was the last command issued) and
instead they now have to type e or erase in the command
line just to issue another erase command:

My LISP trigger calls, small code from VBA which in
turn calls the code that actually does the job, said code sits in VB and is called with a parameter pass

Please help me -- what am I doing wrong?

I gratefully appreciate all the kind help you can give

Matt

----- start of my LISP trigger ----
(command "undefine" "erase" )
(defun c:erase() (vl-vbarun "eraseentity") )
(defun c:e() (vl-vbarun "eraseentity") )
----- end of my LISP trigger ----


--- start of code from VBA ---

Sub EraseEntity()
Dim dblS As Double
dblS = Shell("C:\events.exe e")
End Sub

--- end of code from VBA -----

My VB code that does the actual job is shown below:

--- Start of actual code VB compiled as events.exe that does the job -----

Private Sub Form_Load()
Dim strEvent As String, clsK As clsKo
Dim sel As AcadSelectionSet, q As String

q = Chr(34)

connectDrawing
Set clsK = New clsKo

strEvent = UCase(Trim(CStr(Command())))

Select Case UCase(Trim(strEvent))
Case "M"
MoveIt
Case "S"
Stretch
Case "E"
EraseEntities
Case Else
End Select

Set clsK = Nothing

End
End Sub


Public Sub EraseEntities()
Dim sel As AcadSelectionSet, clsK As clsKo, entA As AcadEntity, lngLineId As Long
Dim intHasImported As Integer, intHasTraversed As Integer, varResult As Variant
Dim aoj As AcadObject

Set clsK = New clsKo


With ThisDrawing
Set sel = .SelectionSets.Add("toErase")
sel.SelectOnScreen
End With


'loop through the selectionset and look for lines,mtext,point and text
With ThisDrawing

For Each entA In sel
Select Case UCase(Trim(CStr(TypeName(entA))))
Case "IACADLINE"
DoAutoEraseStuff "LineID", entA
Case "IACADPOINT"
DoAutoEraseStuff "ObjectPointID", entA
Case "IACADTEXT", "IACADTEXT2"
DoAutoEraseStuff "ObjectIdentity", entA
Case "IACADMTEXT", "IACADMTEXT2" 'type 4
DoAutoEraseStuff "ObjectDescID", entA
Case Else
'object is none of the entities being observed e.g. text, mtext, line, point
'so just automatically erase it
entA.Delete
End Select

Next entA

End With

sel.Delete
Set clsK = Nothing
Set sel = Nothing

End Sub

--- end of actual code VB compiled as events.exe that does the job -----

 

I created a small VBA subroutine inside ThisDrawing that runs notepad.exe. I used your method to redefine the erase command and was able to repeat the new erase command (which just launches notepad) multiple times.

Suggestions:

Maybe you should try something simple like what I did to see if you can get that to work.

You didn't show the subroutine: DoAutoEraseStuff

Why not put the code from the EXE into the VBA macro? See if it works that way.

 

Thank you for your answer

I am pretty sure that if I convert everything in VBA its going
to run and re-run (with every press of the Enter key like it
should) . In fact, I have reason to believe that if I do a
separate .exe, say call it events2.exe entirely devoted to
eraseentity so that I do not have to pass parameter e in the
shell function -- I know it will work, i.e. (repeat command
functionality of Enter and space bar will be retained)

The reason I know it will work is because all my other .exe's that are called from VBA without passing parameter has no
problem re-executing when I hit enter or space bar. The only
thing that makes this different from all the others I made
(which has never caused me problem like this) is that it
passes parameter in the shell exe call.

Its my first time to be redefining a command like erase -- so
that one can be suspect as well (though my gut feeling is
more on the parameter pass)

The only reason I am passing parameters is to be able to do
redefined move, stretch, erase etc. from just one exe.

So there is the quick solution : And yet if I do not really
understand what is happening here -- why is it doing something that I know it should not be doing to the best of my knowledge -- I know -- I would be ill equipped.

I believe that the parameter passing to .exe with redefine
without losing enter functionality to repeat command which I
am trying to achieve is possible -- and I fully trust there are
people out there better than I am who can make this thing
work.


Matt

 

The parameter is not the cause - AutoCAD cannot tell if you pass a parameter. I tried passing a parameter to notepad and there was no problem.

Why are you creating a separate EXE when it could be done all in VBA? Seems like it is extra complicated and slower.

In order to diagnose the problem you have to try the other methods instead of just saying you are "pretty sure" it will work.

 

Matt,
This sounds like a silly question, but do the other commands, "MoveIt" and
"Stretch", have the same problem? You mentioned EraseEntity repeatedly, but
never the other two.

James

thing I am suspecting as the culprit.

get it to re-run like I normally would by pressing Enter.

command line what I get is this

 

Why are you creating a separate EXE when it could be >done all in VBA?
The moment I say that what I am trying to do cannot be done with VB (i.e exe), that would be the time that I would have surrendered a very capable tool without a good fight -- it is really a matter of principle.

You are right that it seems extra complicated work, but in the long run staying your ground on a challenge like this can be a good tool towards deeper understanding.

If I know that there is something wrong in what I am doing (you have seen my code) -- then I will swallow my pride.

The solution you have offered inadvertently pitted VB against VBA. I like both of them so I hate this language rivalry thing.

It is not that I hate cutting and pasting my VB code to VBA -- it is simply that I want to learn the most from this experience -- which is why I have not accepted VBA as the only way to go --

Matt

 

Hello James,

I said it myself -- it does sound like a silly question and not only silly but weird as well. I will try what you are suggesting and experiment with my Move and Stretch redefinition -- we will see if it is doing the same thing.

I have my code in a lot of machines by now -- and the problem is consistent which means to say that anybody with VB can copy paste the code create exe and actually reproduce the same error in their machines.

Matt

 

I meant my question sounded silly, not yours.
I just wondered if there was something in the Erase VB that was causing it
to happen. I have a macro with SendCommand in it; the ENTER key causes the
SendCommand line to repeat, but UP arrow will repeat my original command,
like I want.

James

but weird as well. I will try what you are suggesting and experiment with
my Move and Stretch redefinition -- we will see if it is doing the same
thing.

consistent which means to say that anybody with VB can copy paste the code
create exe and actually reproduce the same error in their machines.

 

Thanks James,

I think I am starting to get close to solving this riddle -- a few more experiments and I shoud be able to make solid conclusions.

Its is starting to look like it has nothing so much to do with the code at all but with some other technique.

Matt

 

The easiest way is to write a lisp wrapper which calls your macro.

 

Hello Frank,

Thanks for your answer.

I am calling the VBA macro using lisp vl-vbarun cannot seem to call it repeatedly with usual enter key

I have ruled out by now the parameter passing I have described as the culprit after doing some experiments.

It is starting to look like problem with calling multiple .exe from VBA -- but I need to prove this with further experiments (in theory this should not be the case though and it should not matter how many EXE are called from the same VBA trigger).

My VBA (which is called via lisp) calls 2 different executables depending on the keystrokes made by user.

It is strange because the first executable runs perfect and I can rerun it repeatedly with enter key. On the other hand the other exe which stores the eraseentity stuff misbehaves.

I compare the two triggers and the only difference are the names of the executable and of coarse the other one has a parameter being passed. Other than that they look the same.

So I tried to get rid of the parameter pass thing and recompiled an EXE for erase stuff so that it will no longer require a parameter to be passed -- but I am still ending up with the same problem as before i.e. enter key does not work for the second executable in the VBA trigger.

Have you encountered something like that before?

Matt

 

Your lisp routine starts with DEFUN C:XXX?

 

Matt,
If you want to check whether multiple EXE's cause the problem, you could try
this experiment:
1 - compile MoveItCopy.EXE which is just a copy of MoveIt.EXE
2 - replace the call to EraseEntity with MoveItCopy, still triggered by "E"
3 - can you now use "M", "S", and "E" with no problem?

If so, then it's something that the EraseEntity code does that is messing
you up. Perhaps in the DoAutoEraseStuff routine that GTVic mentioned...?

Awaiting the experiment's results....

James

repeatedly with enter key. On the other hand the other exe which stores the
eraseentity stuff misbehaves.

executable and of coarse the other one has a parameter being passed. Other
than that they look the same.

for erase stuff so that it will no longer require a parameter to be
passed -- but I am still ending up with the same problem as before i.e.
enter key does not work for the second executable in the VBA trigger.

 

Hello Frank,

I see what you mean:

(command "undefine" "erase" )
(defun c:erase() (vl-vbarun "eraseentity") )
(defun c:e() (vl-vbarun "eraseentity") )

The actual lisp file has 3 defun statements inside one .lsp file and since the first defun statement was about one mile long I took the important stuff from there that user needs to know and posted it in this forum i.e. that I undefined the erase command prior to calling my own erase version to replace the undefined erase.

If I call the first defun for example mama -- the three defun statements inside the lisp file reads:

(defun c:mama()
(manyclosing pairs of parenthesis with functionsnames
here ... many lines of code bla bla bla the last stuff
to be called in this first defun statement is the undefine
statement shown directly below)
(command "undefine" "erase" )
)
;next two defun statements shows my version of the erase
;command

(defun c:erase() (vl-vbarun "eraseentity") )
(defun c:e() (vl-vbarun "eraseentity") )

LSP file saved as mama.lsp user calls mama first from the command line to make it perform many things including call another executable from the same VBA that the same macro calling EXE (problematic one) is being called from.

Matt