Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ActiveX EXE being forced to Single Threaded ? Help please ?

Status
Not open for further replies.

Nimroduk

Programmer
Aug 10, 2006
77
GB
Hi all,

I have searched hi and low, here and the I cannot find even a small hint as to the source of this problem :eek:

I have an application that creates references to a multiuse object contained within a thread-per-object ActiveX EXE. The multiuse class utilises a timer to provide a pseudo-async/multi-threaded execution model.

The application has installed and worked perfectly in over 100 instances, across just about every OS and service pack combination you can think of. However, I now have 2 sites where the application just will not run as expected :(
In both instances the application is installed on a Windows2000 Server.

What appears to be happening is that the timer control (used to generate a pseudo-thread) is only raising its event into the last object created. e.g.

Instance1 - working fine
add Instance 2 and Instance1 stops working ?!

I have found that I can workaround the problem by changing the multiuse interface on the ActiveX EXE to singleuse and recompiling. Thus a completely seperate process is spawned for each instance of the object that uses the timer.

Can anyone tell me why a change from multiuse to single use should effect the ability to receive events from a timer control ?

I don't want to rollout singleuse-thread-per-object everywhere as the machine resource requirements go through the roof !
 
Well, first off, singleuse has only one thread per process, since each client spawns a single process of the instance. So yes, that should constitute a workaround, since you are abandoning the idea of multithreading entirely.

So, obviously, that's not why you got into this in the first place.

You might like to have a look at which provides an overview of sample code covering event based and callback based asynchronous interaction, using the metaphor of a coffee pot. The actual code used to be available on the internet, but it may be gone now as part of Microsoft's ongoing conspiracy to get people to use .Net by making it more and more difficult to find VB6 documentation on their site. In any case, the sample code should be available on the VS6 disk.

HTH

Bob
 
Cheers for the links but I'm not going to learn anything new tbh. I've been developing multi-threaded VB6 systems for close to 10 years now, I'd like to think that I've got the basics down :)

This is definatly a system configuration issue but as I do not have direct access to the Machines or their owner domain configurations it is difficult to know where to look.

I was hoping that someone might have come across a similar issue. It does seem a little strange that in 10 years I have only had this happen twice and both have been inside a couple of months :/
 
Well the problem is now occuring one development machine in the office...

...the only problem is that as far as we know nothing has been installed (or changed) on this PC. Something fishy is a foot :s
 
Please close this.
I am creating a new question/thread with a more defined title.
 
Actually, changed my mind as it is impossible to make a sensible question out of my findings.

I have discovered that the problem in the test lab is being caused by DPAgnt.exe; part of the DigitalPersonal software suite (Fingerprint scanning).
If I kill the DPAgnt.exe process from Task Manager and run my application everything works fine. As soon as DPAgnt.exe is started again, my application fails.

As far as I can tell the only shared resources are the common window's controls.

Now the problem gets worse as the production site having this issue do not have the DP suite installed and there is no DPAgnt.exe process running, which obviously means another process is causing me problems.

Can anyone suggest anyway of debugging what is happening within COM/RPC such that my application loses its internal reference's to its out-of-process interfaces ?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top