how to call acad from std. exe?

[Anonymous]

Hi all,
I have a vba dvb I've been calling from acad with a lisp routine via
vla-runmacro or vl-vbarun
I want to change it to a stand alone .exe

in addition to changing all ThisDrawing references I need to somehow connect
to acad.
but since I'll be calling the exe from within acad (I presume by using
(Startapp) ???) I'm confused about how to connect to acad. I obviously
don't need the usual "on error resume next getobject if err then create
object" that I would use if I was starting the exe from outside of acad. so
what's the proper way to refer to the instance of acad that is calling the
app?
I know this is a stupid question but hey, that's my specialty!
:-)
Mark

[Anonymous]

Mark Propst wrote:
> so what's the proper way to refer to the instance of
> acad that is calling the app?

You'll need to create an ActiveX executable with one publicly creatable
class. That class should have a property that will accept a reference to
an AcadApplication object.

Using VisualLISP, create an instance of the class and set its
application property passing the return value of (vlax-get-acad-object).

I know that sounds like a lot of effort but it's the only reliable way
to attach to the proper instance of AutoCAD. VB's GetObject is
insufficient for scenarios involving multiple running instances of
AutoCAD.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com

[Anonymous]

Hi Mark,
Perhaps it would be easier to answer your question if you stated what you
are trying to accomplish. But on the side, some things you stated are
inconsistent. You stated you wanted a stand alone program, but then you
sound as if you still want it to run in the same process as the current
session of acad. BTW, (startapp) is like using the Shell function, once you
start the app, acad has no control over it.

--
Ed
--

"Mark Propst" wrote in message
news:8CF75C8DCA9D38E6E759AA8156D6B42C@in.WebX.maYIadrTaRb...
> Hi all,
> I have a vba dvb I've been calling from acad with a lisp routine via
> vla-runmacro or vl-vbarun
> I want to change it to a stand alone .exe
>
> in addition to changing all ThisDrawing references I need to somehow
connect
> to acad.
> but since I'll be calling the exe from within acad (I presume by using
> (Startapp) ???) I'm confused about how to connect to acad. I obviously
> don't need the usual "on error resume next getobject if err then create
> object" that I would use if I was starting the exe from outside of acad.
so
> what's the proper way to refer to the instance of acad that is calling the
> app?
> I know this is a stupid question but hey, that's my specialty!
> 🙂
> Mark
>
>
>

[Anonymous]

Thanks Frank,
I'll try that.
Mark

"Frank Oquendo" wrote in message
news:980A78CFEA8EFF9B82938CD27BD09F2C@in.WebX.maYIadrTaRb...

> You'll need to create an ActiveX executable with one publicly creatable
> class.

[Anonymous]

Hi Ed,
Thanks for responding,

"Ed Jobe" wrote in message
news:F5CD95946C476EC4BFE5795790C7D8A9@in.WebX.maYIadrTaRb...
> Hi Mark,
> Perhaps it would be easier to answer your question if you stated what you
> are trying to accomplish.

I just wanted the app to be an .exe so it was compiled so the code wasn't
visible.

But on the side, some things you stated are
> inconsistent. You stated you wanted a stand alone program, but then you
> sound as if you still want it to run in the same process as the current
> session of acad. BTW, (startapp) is like using the Shell function, once
you
> start the app, acad has no control over it.

yeah, I was thinking that startapp or shell would be the two ways I could
think of to fire an .exe file (don't know if there are others)


yeah, i'm not sure the correct terminology, like I say I just wanted to
compile it so I was thinking that meant it was a 'stand alone' .exe.
But yes, the program flow is that i'm in acad and want to use this program
(all it does is draw some symbols, inserting them as blocks with
attributes). It works fine as a dvb but that leaves the source code
visible.
Frank suggested activex exe so maybe that's more the right terminology?

[Anonymous]

> I just wanted the app to be an .exe so it was compiled so the code wasn't
> visible.
You could also compile to dll. The main difference is that the exe will be
an out-of-process server and the dll will be running in acad's process which
is usually faster. You could use Frank's approach for both. As for calling
the dll, the lisp ng has had some discussions recently on how to do this.

--
Ed
--

"Mark Propst" wrote in message
news:E85B987E2A89D3F771DAB8C5408B25F6@in.WebX.maYIadrTaRb...
> Hi Ed,
> Thanks for responding,
>
> "Ed Jobe" wrote in message
> news:F5CD95946C476EC4BFE5795790C7D8A9@in.WebX.maYIadrTaRb...
> > Hi Mark,
> > Perhaps it would be easier to answer your question if you stated what
you
> > are trying to accomplish.
>
> I just wanted the app to be an .exe so it was compiled so the code wasn't
> visible.
>
> But on the side, some things you stated are
> > inconsistent. You stated you wanted a stand alone program, but then you
> > sound as if you still want it to run in the same process as the current
> > session of acad. BTW, (startapp) is like using the Shell function, once
> you
> > start the app, acad has no control over it.
>
> yeah, I was thinking that startapp or shell would be the two ways I could
> think of to fire an .exe file (don't know if there are others)
>
>
> yeah, i'm not sure the correct terminology, like I say I just wanted to
> compile it so I was thinking that meant it was a 'stand alone' .exe.
> But yes, the program flow is that i'm in acad and want to use this program
> (all it does is draw some symbols, inserting them as blocks with
> attributes). It works fine as a dvb but that leaves the source code
> visible.
> Frank suggested activex exe so maybe that's more the right terminology?
>
>
>
>

[Anonymous]

Hi Ed,

I need a little clarification

"Ed Jobe" wrote in message
news:050ED5110F59991CA21502A8371C82FF@in.WebX.maYIadrTaRb...
> You could also compile to dll. The main difference is that the exe will be
> an out-of-process server

is that *any* exe? ie both a standard Exe and an Activex exe would be out
of process?

>and the dll will be running in acad's process which
> is usually faster.

that's what I would prefer

> You could use Frank's approach for both.

you mean I can create Either and activex.exe or an activex.dll and make the
classes etc that frank mentioned and it would work the same?
but the exe would be out of process where the dll would be in process???

> As for calling
> the dll, the lisp ng has had some discussions recently on how to do this.

yes, I was playing with that a bit last week with limited success. I'll
have to try again if I get this conversion working.

Thanks again for your info.
Mark

[Anonymous]

Mark Propst wrote:
>> You could also compile to dll. The main difference is that the exe
>> will be an out-of-process server
>
> is that *any* exe? ie both a standard Exe and an Activex exe would
> be out of process?

Any executable will be out-of-process. However, you can minimize the
performance hit by compiling all code that will be interacting with
AutoCAD into a DLL. Once you've conencted to AutoCAD, you can load the
DLL into AutoCAD's process space by using GetInterfaceObject. Then
manipulate the created object from within your executable.

>> You could use Frank's approach for both.
>
> you mean I can create Either and activex.exe or an activex.dll and
> make the classes etc that frank mentioned and it would work the same?
> but the exe would be out of process where the dll would be in
> process???

That's correct.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com

[Anonymous]

sorry for being so dense, but...
so what would be the advantage of creating an activex.exe *and* an
activex.dll rather than just doing everything in the .dll?
the program flow is merely calling sub main.
sub main calls form.show
form_initialize creates a weldsymbol class instance
the various checkboxes etc in the form set class properties,
then the command button calls the class.draw method which inserts or creates
the appropriate block and attributes.
so the only interaction with autocad is hiding the form and picking a point,
once all the choices have been selected in the form. then that's the end of
the program.


Could all of that not be in the dll, eliminating the exe altogether?
So far the only dlls Ive made are subs and classes only - (toolbox
utilities).
whenever I have created a project with a form I've been making a standard
exe. so I'm not sure if there are issues with dll and a form class.
Thanks as always for your helpful suggestions,.
Mark

all code is then an interaction between

"Frank Oquendo" wrote in message
news:E9043236B1CF438511F079A5CDAA5778@in.WebX.maYIadrTaRb...
>
> Any executable will be out-of-process. However, you can minimize the
> performance hit by compiling all code that will be interacting with
> AutoCAD into a DLL. Once you've conencted to AutoCAD, you can load the
> DLL into AutoCAD's process space by using GetInterfaceObject. Then
> manipulate the created object from within your executable.

[Anonymous]

Mark Propst wrote:
> sorry for being so dense, but...
> so what would be the advantage of creating an activex.exe *and* an
> activex.dll rather than just doing everything in the .dll?

Actually, you wouldn't do both.

The ActiveX executable would be the way to go if you wanted everything
inside the executable as a public class would be the only way for your
app to interact with AutoCAD.

The DLL is the right solution if you don't mind compartmentalizing your
application or want to increase its performance.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com

[Anonymous]

BTW, you can't just code a DLL because you'll still need a client
application to make use of it. You can do that with VBA but it's not a
very secure solution.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com

[Anonymous]

so in this sentence:
"... you can't just code a DLL because you'll still need a client
application to make use of it."
the word "client" refers to something different than just calling a dll from
lisp?
as in this pseudocode idea of how to call a dll from lisp
(defun InvokeDll(dllName dllMethod / ac res res2)
(setq ac (vlax-get-acad-object))
(setq res(vla-GetInterfaceObject ac dllname))
(setq res2 (vlax-invoke-method res dllMethod))
(vlax-release-object res)
(vlax-release-object ac)
res2
)
that function (just pseudocode) probably wouldn't work, it's just my way of
trying to figure out how to call a dll from lisp pasted together from a few
recent posts. I haven't tried it yet.
like I say it's more like pseudocode...i'm not sure what I need to change
yet to make it work as a callable function.
but is that what you mean by "client" or is it something different?

"Frank Oquendo" wrote in message
news:DE67F13EA570CBDDD9E7C4BCADD5A6BB@in.WebX.maYIadrTaRb...
> BTW, you can't just code a DLL because you'll still need a client
> application to make use of it. You can do that with VBA but it's not a
> very secure solution.
>
> --
> There are 10 kinds of people. Those who understand binary and those who
> don't.
>
> http://code.acadx.com
>
>

[Anonymous]

Mark Propst wrote:
> so in this sentence:
> "... you can't just code a DLL because you'll still need a client
> application to make use of it."
> the word "client" refers to something different than just calling a
> dll from lisp?

Not at all... A client can be written in any language that supports
ActiveX, including VisualLISP.

But if you already know VB and are new to LISP, I'd suggest sticking to
what you know if you have any sort of deadline on this project.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com

[Anonymous]

"Frank Oquendo" wrote in message
news:58723241BA8FBB946D562F96764DAF70@in.WebX.maYIadrTaRb...
> Not at all... A client can be written in any language that supports
> ActiveX, including VisualLISP.
> But if you already know VB and are new to LISP, I'd suggest sticking to
> what you know if you have any sort of deadline on this project.

well, I've been mangling lisp for 10 years more than I have been misusing
vb. 🙂

but..., this is the first I've tried calling a dll from lisp.

I started this project as a vba inside autocad.
It is functioning ok when called from lisp with vl-vbarun
(because vla-runmacro won't allow me to hide the form and pick a point).

Now I wanted to turn the .dvb file into a compiled type file. (from your
posts, either an activex.exe or and activex.dll)
(from many posts i've read I thought the .dll was the way to go because
everyone mentions the performance issue, now I need to research the
activex.exe methodology because you mentioned, if I don't mind
"Compartmentalizing" the app. unfortunately I don't understand what that
means cause I'm not up on the details of an activex.exe interacting with
acad. so I don't know whether I "should" mind "compartmentalizing" or not!
obviously I've got a lot of research to do.

If you think of this app as a simple form with a command button on it, the
only action the entire app does (other than set some parameters for the
inserted block) is to have the user pick a point, and then insert a block at
that point, when the user clicks the "InsertBlock" button. so it's a
pathetically simple application - the only other thing it does is decide
which block to insert and if it doesn't exist, it creates it- big deal!

So in that context, would you recommend an activex.exe or and activex.dll.?

and in terms of the "calling client":
as I understand it, there is no possibility of running a vb or vba app in
autocad without the calling client being a lisp function. Is that
incorrect?
so....
would I make a sub that called the form and then run the sub with
vl-vbarun(just like I'm doing now with the dvb file?) or would I use a lisp
construct similar to the one I mentioned re: calling a .dll? and then
invoking the sub(method) with the lisp syntax (once I get it figured out
correctly)
thanks, as always, for your help
(sorry if I'm being incredibly obtuse here...as opposed to just my normal
obtusosity) 🙂
Mark

[Anonymous]

Mark Propst wrote:

> Now I wanted to turn the .dvb file into a compiled type file. (from
> your posts, either an activex.exe or and activex.dll)

A DVB cannot produce either type of file. You'll have to port the code
to Visual Basic, not VBA if you want an EXE or a DLL.

> (from many posts i've read I thought the .dll was the way to go
> because everyone mentions the performance issue, now I need to
> research the activex.exe methodology because you mentioned, if I
> don't mind "Compartmentalizing" the app. unfortunately I don't
> understand what that means cause I'm not up on the details of an
> activex.exe interacting with acad. so I don't know whether I "should"
> mind "compartmentalizing" or not! obviously I've got a lot of
> research to do.

Only go with the ActiveX executable if a DLL is not desirable.

> If you think of this app as a simple form with a command button on
> it, the only action the entire app does (other than set some
> parameters for the inserted block) is to have the user pick a point,
> and then insert a block at that point, when the user clicks the
> "InsertBlock" button. so it's a pathetically simple application - the
> only other thing it does is decide which block to insert and if it
> doesn't exist, it creates it- big deal!
>
> So in that context, would you recommend an activex.exe or and
> activex.dll.?

DLL.

> and in terms of the "calling client":
> as I understand it, there is no possibility of running a vb or vba
> app in autocad without the calling client being a lisp function. Is
> that incorrect?

Yes, that is incorrect. You can also use VBA to create your client. The
DVB will contain only the code necessary to create an instance of your
class so one Public Sub is all you'd need.

> (sorry if I'm being incredibly obtuse here...as opposed to just my
> normal obtusosity) 🙂

As if I didn't pester folks around just as much five years ago. 😉

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com

[Anonymous]

"Frank Oquendo" wrote in message
news:B863230A3BB594254533BEC622452D9D@in.WebX.maYIadrTaRb...

> A DVB cannot produce either type of file. You'll have to port the code
> to Visual Basic, not VBA if you want an EXE or a DLL.

i *do* realize that much, that's what I meant.

>
> Only go with the ActiveX executable if a DLL is not desirable.

why would it be not desirable?


> DLL.
cool.

>
> > and in terms of the "calling client":
> > as I understand it, there is no possibility of running a vb or vba
> > app in autocad without the calling client being a lisp function. Is
> > that incorrect?
>
> Yes, that is incorrect. You can also use VBA to create your client. The
> DVB will contain only the code necessary to create an instance of your
> class so one Public Sub is all you'd need.

but I can't call the vba dvb without using a lisp function to call it,
that's what I meant in the sentence above.
is that not correct?
so ultimately the lisp is the calling client, is it not?
a lisp client calling a vba client, calling a dll server????
or just eliminate the middle man and have the lisp call the dll with invoke
method
or am i missing something yet again (yeah, I know, I'm missing a whole lot
of somethings)


> As if I didn't pester folks around just as much five years ago. 😉

hmm, I don't remember that!

Thanks again,
Mark

[Anonymous]

Hi Mark,



How did you get on with this? I was away last week and it's taken me until today (Thursday!!) to catch up on all my emails and the discussion group postings and still try and fit some real work in somewhere 😉 so I'm sorry I'm only getting to see your question now.



I can see Ed and Frank have provided you with a lot of info and maybe you've achieved what you were trying to accomplish by now. My interest is due to the fact that we were spurred by the same requirement, ie I wrote a dvb in VBA and then wanted to protect the source code. I dropped the code into a standalone VB exe but the performance was abysmal (as has been alluded) so instead we ported it to an ActiveX DLL. After some experimentation the result was fairly successful. It's initiated from a button in AutoCAD and doesn't require any lisp.



Let me know if you want more details posted.



Regards



Wayne Ivory

IT Analyst Programmer

Wespine Industries Pty Ltd