|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
InstantiationIt 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. BeeJ submitted this idea :
> I have an ActiveX EXE that I wrote. And that's all you should see - it's thread per object, not process per > 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. > object :) > All runs but not well. Sometimes images in one class do not appear, then I would look at how you are implementing your asyncronous calls... All > later it starts working and a different class stops working. I use .Refresh > after each .Picture etc operation. > 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 It happens that Tom Shelton formulated :
Show quoteHide quote > BeeJ submitted this idea : That is what I am doing at the interface.>> 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. 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. Tom Shelton pretended :
Show quoteHide quote > BeeJ submitted this idea : Oh yes. I change the Instantiation to 3-SingleUse and now I get an >> 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. 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? On 05/08/2010 03:50, BeeJ wrote:
> Oh yes. I change the Instantiation to 3-SingleUse and now I get an Log App.ThreadID.> 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? 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.ear***@icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.) Dee Earley was thinking very hard :
> On 05/08/2010 03:50, BeeJ wrote: Thanks.>> 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. This app has over 80,000 lines of source. I really like the off the wall suggestions because it makes me think. It's nice to be handed a solution, but nicer to figure it out myself with usually very helpful inputs from others. 
Other interesting topics
Get Selected Path From Explorer
How to save a picturebox's image to a .PNG file? (VB6) Unicode API RegClean create user on AD server System Timer Callback? Form Z order across the divide Old VB Project doesn't work with New Office or Windows 7 Reconnection issue between Winsock Server(VB6) and TCP Client (VB.NET) Are PDB files used by VB6 |
|||||||||||||||||||||||
