Prev: Old VB Project doesn't work with New Office or Windows 7
Next: How to autosaving .xps documents
From: BeeJ on 4 Aug 2010 20:48
I have an ActiveX EXE that I wrote.
It is set 5-MultiUse, Thread per Object.
This ActiveX EXE raises events.

I have an array of class that instantiates one each of the ActiveX EXE.
I instantiate the array of this class (0) thru (3).

I was expecting that I would see the same number of ActiveX EXEs in
Process Explorer but I only see one.

All runs but not well. Sometimes images in one class do not appear,
then later it starts working and a different class stops working. I
use .Refresh after each .Picture etc operation.

Am I looking at this wrong or do I have something coded wrong and
should see 4 of the ActiveX EXEs running?
Based on Process Explorer, the ActiveX EXE is using 20% CPU. I would
have expected to see four each running at 5% CPU.
Suggestions please.


From: Tom Shelton on 4 Aug 2010 20:55
BeeJ submitted this idea :
> I have an ActiveX EXE that I wrote.
> It is set 5-MultiUse, Thread per Object.
> This ActiveX EXE raises events.
>
> I have an array of class that instantiates one each of the ActiveX EXE.
> I instantiate the array of this class (0) thru (3).
>
> I was expecting that I would see the same number of ActiveX EXEs in Process
> Explorer but I only see one.
>

And that's all you should see - it's thread per object, not process per
object :)

> All runs but not well. Sometimes images in one class do not appear, then
> later it starts working and a different class stops working. I use .Refresh
> after each .Picture etc operation.
>

I would look at how you are implementing your asyncronous calls... All
calls to other com objects are syncrounous. So, simply putting the
object on separate thread is not enough to get threaded behavior. The
calls sequence is usually something like:

1. exe calls object method
2. object method sets a api timer with some context info and returns
3. api timer message is intercepted, object retrieved and real
implementation called...

This is necessary to detach the callign thread from the execution
thread.

--
Tom Shelton


From: BeeJ on 4 Aug 2010 22:46
It happens that Tom Shelton formulated :
> BeeJ submitted this idea :
>> I have an ActiveX EXE that I wrote.
>> It is set 5-MultiUse, Thread per Object.
>> This ActiveX EXE raises events.
>>
>> I have an array of class that instantiates one each of the ActiveX EXE.
>> I instantiate the array of this class (0) thru (3).
>>
>> I was expecting that I would see the same number of ActiveX EXEs in Process
>> Explorer but I only see one.
>>
>
> And that's all you should see - it's thread per object, not process per
> object :)
>
>> All runs but not well. Sometimes images in one class do not appear, then
>> later it starts working and a different class stops working. I use
>> .Refresh after each .Picture etc operation.
>>
>
> I would look at how you are implementing your asyncronous calls... All calls
> to other com objects are syncrounous. So, simply putting the object on
> separate thread is not enough to get threaded behavior. The calls sequence
> is usually something like:
>
> 1. exe calls object method
> 2. object method sets a api timer with some context info and returns
> 3. api timer message is intercepted, object retrieved and real implementation
> called...
>
> This is necessary to detach the callign thread from the execution thread.

That is what I am doing at the interface.
For param setting, I call and set a param and it returns. No problem.
For a sequence start, I call and enable a timer that runs the code.
That sub returns immediately after enabling the timer. No problem.
Thanks for the reminder.
I think the problem is in the graphics routines.
I am using BitBlt and StretchBlt to manipulate images.
I think I am screwing something up there.
I am using a timing loop based on the system timer and optionally on
CreateWaitableTimer. It is not perfect yet but it seems to function.
I see that in certain graphics routines, the picturebox disappears and
a temp picbox is visible. Other graphic routines run just fine
forever. I need to isolate that and see what the heck is going on.


From: BeeJ on 4 Aug 2010 22:50
Tom Shelton pretended :
> BeeJ submitted this idea :
>> I have an ActiveX EXE that I wrote.
>> It is set 5-MultiUse, Thread per Object.
>> This ActiveX EXE raises events.
>>
>> I have an array of class that instantiates one each of the ActiveX EXE.
>> I instantiate the array of this class (0) thru (3).
>>
>> I was expecting that I would see the same number of ActiveX EXEs in Process
>> Explorer but I only see one.
>>
>
> And that's all you should see - it's thread per object, not process per
> object :)
>
>> All runs but not well. Sometimes images in one class do not appear, then
>> later it starts working and a different class stops working. I use
>> .Refresh after each .Picture etc operation.
>>
>
> I would look at how you are implementing your asyncronous calls... All calls
> to other com objects are syncrounous. So, simply putting the object on
> separate thread is not enough to get threaded behavior. The calls sequence
> is usually something like:
>
> 1. exe calls object method
> 2. object method sets a api timer with some context info and returns
> 3. api timer message is intercepted, object retrieved and real implementation
> called...
>
> This is necessary to detach the callign thread from the execution thread.

Oh yes. I change the Instantiation to 3-SingleUse and now I get an
instantiation of each ActiveX EXE. All four identical ActiveX EXEs
show up in Process Explorer. Hopefully, now each is on its own thread.
Could not prove it in the case of only one showing up that runs in all
for classes as before. Is there a way to see that?


From: Dee Earley on 5 Aug 2010 03:30
On 05/08/2010 03:50, BeeJ wrote:
> Oh yes. I change the Instantiation to 3-SingleUse and now I get an
> instantiation of each ActiveX EXE. All four identical ActiveX EXEs show
> up in Process Explorer. Hopefully, now each is on its own thread.
> Could not prove it in the case of only one showing up that runs in all
> for classes as before. Is there a way to see that?

Log App.ThreadID.
I expect your original problem was handles/timers being shared or
confused between all the objects, but without full code, it's difficult
to say.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
 |  Next  |  Last
Pages: 1 2
Prev: Old VB Project doesn't work with New Office or Windows 7
Next: How to autosaving .xps documents