Re: How best for dll to "report progress"?
- From: "MP" <nospam@xxxxxxxxxx>
- Date: Fri, 10 Nov 2006 00:36:40 -0600
"Ken Halter" <Ken_Halter@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:u6F$kTIBHHA.1220@xxxxxxxxxxxxxxxxxxxxxxx
"MP" <nospam@xxxxxxxxxx> wrote in message
news:u%23FSVFIBHHA.4992@xxxxxxxxxxxxxxxxxxxxxxx
The dll is created, lets say, by a form in a stand alone exe, therefore
"out
of process" to the dll.class and other oApp
DLLs, by design, run 'in process' and have no built in way to communicate
with any other app.
sorry, I don't understand what you mean there, can you elaborate?
In my understanding(lack thereof) <g>
The dll is created by my vb6.exe app "in process" to the external app(acad).
The dll can then "communicate" to the external app(in whose process it is
running) by calling that apps api methods etc.
Then it can return data back to my vb6 exe when I call it's properties,
right?
Sub()
Set oApp = CreateInstanceOfApp
Set cDll = oApp.GetInterfaceObject(mydll.myclass)
Call cDll.GatherInfo (oApp.Document)'dll communicates with app ???
ReturnData = cDll.ReturnInfo'dll communicates with me???
Call UseData (ReturnData) 'or whatever
End Sub
I think of that as my way of "communicating" back and forth from my app to
the "other" app (via the dll inprocess so speed is better)...
what am I missing?
are you just saying a dll can't raise events?
Have you considered an ActiveX EXE instead? They run
'out of process' and several apps can share a single instance.
I know nothing about ActivexExes so maybe I'm missing something but based on
my research so far I've been led to believe I need a dll
Out of process is extremely slow (due to marshalling so I've been told),
that's why I need dll
I only have one app(my vb6 exe) and one external app(autocad) I'm "talking
to" (via my dll)
So I have no need for multiple apps to share an instance.
So unless there's something else about an ActivexExe that I'm missing ???
Are you saying dll's can't raise events back to their creators? I wasn't
aware of that...(have just barely scratched the surface of learning events)
If you want to stick with the DLL, you can probably setup some kind ofwindows
subclassing in that 'other app' and use PostMessage to send info to
in that app. Since PostMessage doesn't wait for a return, it shouldn'thave
much of an effect on performance.
I don't want to communicate with windows in the other app, just gather info
from objects in it.
I don't know anything about subclassing....from what i've read it's
"dangerous" territory :-)
I'm still trying to learn baby steps <g>
From my exe I could "communicate" with acad, get the data I want, etc butthat would be slow due to "cross-process marshalling" right?
Thats' why i'm "delegating" the data mining operation to the Dll "in
process"
...or, you can try one of the many 'communicate with other apps'works.
samples/components. Here's a link to mine (below)... it's very reliable,
when used by sane people <g> iow, it's not designed to allow 1,000 apps to
constantly bombard each other with info (some people..... geez). It uses
SendMessage... you can try changing that to PostMessage and see if it
No subclassing required either.
Communicate with another instance of your app
http://www.vbsight.com/CodeC.htm#CrossCom
I looked at the description of that but from the sound of it I think I'm
trying to do something else???
or i'm just not understanding what you're trying to explain
Thanks
Mark
.
- Follow-Ups:
- Re: How best for dll to "report progress"?
- From: J French
- Re: How best for dll to "report progress"?
- References:
- How best for dll to "report progress"?
- From: MP
- Re: How best for dll to "report progress"?
- From: Ken Halter
- How best for dll to "report progress"?
- Prev by Date: Re: How to select a fax driver?
- Next by Date: Re: Loose coupling, tight cohesion, general confusion <g>
- Previous by thread: Re: How best for dll to "report progress"?
- Next by thread: Re: How best for dll to "report progress"?
- Index(es):
Relevant Pages
|
Loading