ActiveX DLL 
Author Message
 ActiveX DLL

Is an ActiveX DLL (while running in the same address space) running as a
separate thread From the Main Program?


Tue, 13 Mar 2012 22:07:07 GMT  
 ActiveX DLL



Quote:
> Is an ActiveX DLL (while running in the same address space)
> running as a separate thread From the Main Program?

No, not by default.
Though there are situations, where an *debugged*
ActiveX-Dll-project (if not placed within the same
VB-Projectgroup, but in a separate IDE-instance instead)
is running on a separate Process/thread.

But in "binary-mode" an ActiveX-Dll is running as the so
called "InProcess-Server" within the same Process-
Address-space (on the very same, single VB-MainThread).

Just take a look into the Taskmanager, how many threads
are running (not in the IDE, but in the compiled Main.exe-
binary).

For threading-purposes (in case you want to use
Public Classes of your ActiveX-Dll as ThreadClasses
and avoid putting them into an ActiveX-Exe-project)
you can use DirectCOM.dll, to start Class-Instances
directly from ActiveX-Dlls regfree. This alternative
Threading-approach can help settle potential "deployment
and registering-issues" of ActiveX-Exes (for example
on Vista-Targets).

Olaf



Tue, 13 Mar 2012 23:00:12 GMT  
 ActiveX DLL

Olaf:

Thanks for your time and response.

You probably already answered my question
-- last part of response little confusing for me -- but here's my problem.

I have a set of tools that currently are part of a main VB program.
The main program interfaces realtime and because of the amount of CPU clock
ticks available, when I use my tools, I periodically get a conflict.

Since I don't need a user interface I ruled Out an ActiveX control.  This
leaves ActiveX DLL or ActiveX EXE that can be called from within my  main
VB.   Based on your response, since the ActiveX DLL would not be on a
separate thread, that would only leave me with an ActiveX EXE.

 You do however mention DirectCOM.dll (this is where I'm confused):

 > For threading-purposes (in case you want to use

Quote:
> Public Classes of your ActiveX-Dll as ThreadClasses
> and avoid putting them into an ActiveX-Exe-project)
> you can use DirectCOM.dll, to start Class-Instances
> directly from ActiveX-Dlls regfree. This alternative
> Threading-approach can help settle potential "deployment
> and registering-issues" of ActiveX-Exes (for example
> on Vista-Targets).

Can (How do) I create a DirectCOM.dll from VB5??

David


Quote:



>> Is an ActiveX DLL (while running in the same address space)
>> running as a separate thread From the Main Program?

> No, not by default.
> Though there are situations, where an *debugged*
> ActiveX-Dll-project (if not placed within the same
> VB-Projectgroup, but in a separate IDE-instance instead)
> is running on a separate Process/thread.

> But in "binary-mode" an ActiveX-Dll is running as the so
> called "InProcess-Server" within the same Process-
> Address-space (on the very same, single VB-MainThread).

> Just take a look into the Taskmanager, how many threads
> are running (not in the IDE, but in the compiled Main.exe-
> binary).

> For threading-purposes (in case you want to use
> Public Classes of your ActiveX-Dll as ThreadClasses
> and avoid putting them into an ActiveX-Exe-project)
> you can use DirectCOM.dll, to start Class-Instances
> directly from ActiveX-Dlls regfree. This alternative
> Threading-approach can help settle potential "deployment
> and registering-issues" of ActiveX-Exes (for example
> on Vista-Targets).

> Olaf



Tue, 13 Mar 2012 23:37:31 GMT  
 ActiveX DLL


Wed, 18 Jun 1902 08:00:00 GMT  
 ActiveX DLL
Found DirectCOM.dll on your web site.  Will give it a shot.

David


Quote:
> Olaf:

> Thanks for your time and response.

> You probably already answered my question
> -- last part of response little confusing for me -- but here's my problem.

> I have a set of tools that currently are part of a main VB program.
> The main program interfaces realtime and because of the amount of CPU
> clock ticks available, when I use my tools, I periodically get a conflict.

> Since I don't need a user interface I ruled Out an ActiveX control.  This
> leaves ActiveX DLL or ActiveX EXE that can be called from within my  main
> VB.   Based on your response, since the ActiveX DLL would not be on a
> separate thread, that would only leave me with an ActiveX EXE.

> You do however mention DirectCOM.dll (this is where I'm confused):

> > For threading-purposes (in case you want to use
>> Public Classes of your ActiveX-Dll as ThreadClasses
>> and avoid putting them into an ActiveX-Exe-project)
>> you can use DirectCOM.dll, to start Class-Instances
>> directly from ActiveX-Dlls regfree. This alternative
>> Threading-approach can help settle potential "deployment
>> and registering-issues" of ActiveX-Exes (for example
>> on Vista-Targets).

> Can (How do) I create a DirectCOM.dll from VB5??

> David





>>> Is an ActiveX DLL (while running in the same address space)
>>> running as a separate thread From the Main Program?

>> No, not by default.
>> Though there are situations, where an *debugged*
>> ActiveX-Dll-project (if not placed within the same
>> VB-Projectgroup, but in a separate IDE-instance instead)
>> is running on a separate Process/thread.

>> But in "binary-mode" an ActiveX-Dll is running as the so
>> called "InProcess-Server" within the same Process-
>> Address-space (on the very same, single VB-MainThread).

>> Just take a look into the Taskmanager, how many threads
>> are running (not in the IDE, but in the compiled Main.exe-
>> binary).

>> For threading-purposes (in case you want to use
>> Public Classes of your ActiveX-Dll as ThreadClasses
>> and avoid putting them into an ActiveX-Exe-project)
>> you can use DirectCOM.dll, to start Class-Instances
>> directly from ActiveX-Dlls regfree. This alternative
>> Threading-approach can help settle potential "deployment
>> and registering-issues" of ActiveX-Exes (for example
>> on Vista-Targets).

>> Olaf



Wed, 14 Mar 2012 00:03:50 GMT  
 ActiveX DLL



Quote:
> Found DirectCOM.dll on your web site.  Will give it a shot.

Since you were talking about "realtime", you probably want
to place the "device-interaction" within a separate
ThreadClass.

This usually involves a highfrequent "WaitLoop", constantly
asking the "realtime-device" for new data in short (1-3msec)
intervals.
The retrieved Device-Data should then (usually) also be
visible/reachable within the MainThread (your MainApp-GUI).

In that case DirectCOM.dll can be of help, since it exports a:
StartCOMObject call, which is able to start a Public Class
regfree on a new Thread.

There's a convention in that case - the Public ThreadClass
must have a:
Public Function ThreadMain(Byval UserData as Long)

End Function

The Thread (hosting that ThreadClass) remains then alive,
as long as you remain "looping" or "waiting" in the Public
ThreadMain-Procedure.

So your ThreadMain should be filled with something like this
(regarding "Realtime-Device-interaction"):

Public Function ThreadMain(Byval UserData as Long)
    1. SetUp a shared memory Area (usually an UDT-Array)
    2. InitYourDevice
    3. EnterDeviceLoop (placing new Data within the shared Array)
      The above loop should check cyclically not only for new
      DeviceData, but also for something like an "ExitCondition"
      usually done with a Flag of the SaredMem-Area (the UDT-Array)
End Function '<--Thread-Exit (also terminating this ThreadClass)

If you want an example, you could write some simulation-code,
that somehow mimicks (mocks) your Device (principically).
Working singlethreaded in a small TestApp, involving DoEvents
if you want, just that the principle can be seen.

I could then expand this small Demo of yours into a threaded
solution, involving DirectCOM and a separated AX-Dll,
containing your "Device-Class", just that you get an impression
how all that stuff works.

Olaf



Wed, 14 Mar 2012 00:46:12 GMT  
 ActiveX DLL
Olaf:

Thanks for the offer.

My initial idea was to move all tool functions (methods) to a separate dll
thread.

For initial tool placement I don't seem to have any problems.
Only issues when moving the tool after intial placement (more clock ticks).

My thoughts were that I can set the tool properties in the main thread
(handled both by menu selection and / or format using a separate model
form).  All other tool execution (moving or form refresh) would be a call to
the tool functions contained in DirectCOM.dll from the main thread Paint
event.

This would move all tool code processing into a separate thread, --  
but --not sure whether the main thread will still have problems since it may
be waiting on the callback from DirectCOM.dll to go to the next code line??

Am I wasting my time with above or is an example (per your kind offer)
needed to work this out??


Quote:



>> Found DirectCOM.dll on your web site.  Will give it a shot.

> Since you were talking about "realtime", you probably want
> to place the "device-interaction" within a separate
> ThreadClass.

> This usually involves a highfrequent "WaitLoop", constantly
> asking the "realtime-device" for new data in short (1-3msec)
> intervals.
> The retrieved Device-Data should then (usually) also be
> visible/reachable within the MainThread (your MainApp-GUI).

> In that case DirectCOM.dll can be of help, since it exports a:
> StartCOMObject call, which is able to start a Public Class
> regfree on a new Thread.

> There's a convention in that case - the Public ThreadClass
> must have a:
> Public Function ThreadMain(Byval UserData as Long)

> End Function

> The Thread (hosting that ThreadClass) remains then alive,
> as long as you remain "looping" or "waiting" in the Public
> ThreadMain-Procedure.

> So your ThreadMain should be filled with something like this
> (regarding "Realtime-Device-interaction"):

> Public Function ThreadMain(Byval UserData as Long)
>    1. SetUp a shared memory Area (usually an UDT-Array)
>    2. InitYourDevice
>    3. EnterDeviceLoop (placing new Data within the shared Array)
>      The above loop should check cyclically not only for new
>      DeviceData, but also for something like an "ExitCondition"
>      usually done with a Flag of the SaredMem-Area (the UDT-Array)
> End Function '<--Thread-Exit (also terminating this ThreadClass)

> If you want an example, you could write some simulation-code,
> that somehow mimicks (mocks) your Device (principically).
> Working singlethreaded in a small TestApp, involving DoEvents
> if you want, just that the principle can be seen.

> I could then expand this small Demo of yours into a threaded
> solution, involving DirectCOM and a separated AX-Dll,
> containing your "Device-Class", just that you get an impression
> how all that stuff works.

> Olaf



Wed, 14 Mar 2012 02:03:45 GMT  
 ActiveX DLL



Quote:
> My initial idea was to move all tool functions (methods) to a separate dll
> thread.

> For initial tool placement I don't seem to have any problems.
> Only issues when moving the tool after intial placement (more clock
ticks).

> My thoughts were that I can set the tool properties in the main thread
> (handled both by menu selection and / or format using a separate model
> form).  All other tool execution (moving or form refresh) would be a call
to
> the tool functions contained in DirectCOM.dll from the main thread Paint
> event.
> This would move all tool code processing into a separate thread, --
> but --not sure whether the main thread will still have problems since it
may
> be waiting on the callback from DirectCOM.dll to go to the next code
line??

DirectCOM.dll is more or less a mere instantiation-helper -
It can instantiate COM-Classes regfree in the same thread
with its exportet GetInstance-Call - and it can do the same
regfree instancing for Public Classes on their own (STA-)
threads with the StartCOMObject-Call.

The latter mode needs the already described "entry-function"
(ThreadMain) within the Public Class - and offers then
something like "low-level-threading" support.

If you want an easier solution (simply moving your MainProject-
Classes into Threads), then you should try an ActiveX-Exe,
which should be more "straight-forward" (class-movement +
adding async-decoupling code for the critical routines).

The DirectCOM.dll threading-support requires some
experience, it differs from the way you work with ActiveX-
Exe-threading (e.g. you will have to deal with SafeArrays, to
establish a shared-memory-area  - use critical-sections etc.)
Thought you are targeting a hardware-device - and want to move
only a smaller part (the critical "realtime-code") into a thread.
For such purposes this low-level-efforts would make sense -
but not for something like your planned "sweeping blow". ;-)

Quote:
> Am I wasting my time with above or is an example (per your
>  kind offer) needed to work this out??

It would make sense, if you can identify clearly, what (smaller)
part is currently causing some delays.
For example I don't understand yet, what you mean with:
"moving the tool after placement" and with "clockticks".

If your solution suffers more with regards to "fast drawing"
(no realtime-hardware-devices anywhere), then you should
shade some more light on your problem.

What codepart does not work "fluently" or fast enough for
you ... in either case it would be good, if you could come
up with a small example (if possible).
To write such an example, you will have to identify the
culprit first - try some profiling (using "Highres-Stopwatch-
code" for example), to see which codeparts cause the
largest delays - then try to isolate these codeparts in a
separate (smaller) Demo-project - and ask again then,
how to make such parts faster.
Only if they cannot be implemented in a more speedy
fashion, then it's time to think about threading.

Olaf



Wed, 14 Mar 2012 07:33:36 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. ActiveX.exe or ActiveX DLL or ActiveX Control?????????????

2. ActiveX DLL, ActiveX EXE & ActiveX OCX version

3. ActiveX DLL, ActiveX EXE & ActiveX OCX version

4. Building ActiveX controls that will access activex.dll running on PWS

5. ActiveX exe vs ActiveX dll

6. ActiveX DLL to ActiveX EXE

7. ActiveX dll vs ActiveX control - Whats the difference

8. ActiveX Exe Using ActiveX Dll?

9. Accessing IE5 DOM from inside my clientside activex obj in a activex dll

10. ActiveX DLL vs ActiveX EXE

11. Why DCOM ActiveX Exe is Working and ActiveX Dll is not working

12. Passing ActiveX control as a parrameter to ActiveX.dll

 

 
Powered by phpBB® Forum Software