So I moved all the code to a different PC.
I made zero progress getting anything to work on the other PC.
Now the ActiveX stuff all instantiates and I can talk to all of them.
However, now some new ? related / unrelated ? problems.
1)
At unload all ActiveX close properly except one.
If I step it through ActiveX EXE Class_Terminate using the .vbp from
the main app IDE I get no errors.
If I run the main in the IDE and the ActiveX exe compiled, then when I
set AxX10 = Nothing I get an error (on ActiceX only).
But there is an error handler in the routine and it does not go to the
error handler.  The error message just pops up.
Error message:
---------------------------
DDE Server Window: AxX10.exe - Application Error
---------------------------
The exception unknown software exception (0x0eedfade) occurred in the
application at location 0x7c812afb.
---------------------------
OK   Cancel
---------------------------

2)
When I start the main app in the IDE I get the error message
   Object library not registered
But what object library?
I get this before any line of code is shown to execute.
The main app compiles or starts with Ctrl-F5 without errors.
The second time I start the code I get no message.
When I reload the IDE and app, I get the error again on the first run.
What is this?

[fighting with ActiveX-Exes]

BeeJ, could you encapsulate the Basic-Principle
of your Threading-approach in a schematic and
relative simple Demo for us, and then upload it
somewhere in a Zip-File?

Or better describe your background and the
problem that needs to be solved, using threads?

What happens further in the Main-App (the final
Drawing or Rendering should) - and what's
the main-purpose of your App (rendering multiple
WebCams?) ... and exactly what tasks take
place within the ActiveX-Exe-based Threadclasses
(decoding of compressed stream-chunks?)...

Is Threading needed at all? - see, in our sports-video
systems we do not need threading at all, all the
decoding/rendering of up to 6 simultaneous PAL-
camera-streams (720x576 MJPG) takes place in a
normal singlethreaded VB-Standard-Project.
Decoding-Time per cam (MJPG->YUY2): 3msec
Upload of the YUY2-Data into a DX-Surface: 3msec

So, this does take (for 6 CamStreams) 36msec in total.
All this fits nicely into a 40msec Timer-Interval, which
plays all 6 Streams with a frequency of 25Hz (FPS).

As said, all singlethreaded (the second core of the
CPU is also "at work", binding CPU-resources whilst
keeping up the GBit-network-traffic at the same time.

So, maybe your problem (the reasons for your threading)
can be solved another way - maybe by choosing a
different codec - or other optimizations (e.g. stretched
Rendering per DirectX in "no time"), so that you can
throw out all your ActiveX-Exes and threads.

Hope this sounds not too harsh - but we're "surfing
the mists" regarding your problem over the last weeks/
months, so please post some more details (timing-infos,
in case this is indeed a Stream-Decoding-problem) - and
ideally a small demo, which basically covers your current
threading approach with some mock-routines.

Personally would be glad to help you (maybe also,
to get rid of your ActiveX-Exes for threading with some
alternative approaches), but without any code-input
or more details this would be difficult.


Olaf

Error Object library not registered
This error is gone but I do not understand why?
Instead of double-clicking on the Ax.EXEs to register them all again, I
recompiled all five of them.
Maybe double-clicking is not a real full registration???
Maybe something else???
I am still on my second PC since I cannot resolve anything on the first
PC where none of the Set will work.  They all work on this PC.  Same
code.

I think the
DDE Server Window: AxX10.exe - Application Error
May be related to clean up when closing the Ax.EXE.
I am trying to rewrite it but running into the old problem of
referencing the main entry class for access from other subs in modules
and other classes.  This is where events can get raised back to the
main app.
If I use the method previously suggested, the class gets instantiated
again and this is probably why it errors on closing because I cannot
figure out how to close that instance.  e.g. I have a log message sub
that resides in a .bas.  It wants to write to a file (easy) but also
raise an event back to the main app.  So I need to reference the entry
class where the event can be raised.  Of it I put the log message in
the entry class then I have to reference the entry class so the .bas
can also call this message log routine.  I am now trying to write a
message log class but fighting a circular reference problem.

Anyway, it is difficult to answer your question.
I am manipulating images so timing is on the order of 5 to 50 mSecs for
each iteration.  These are constantly running using system timers. 
This is happening on multiple images each in there own AxEXE.  I may
have to set a max when I figure out what it might be related to the
processor speed etc. Right now four run smoothly together (one Ax EXE
instantiated four times). At the same time other system CPU intensive
things are going on that I have started.  They are all on there own
threads.  I have found that I cannot get stable time intervals if I run
all on one thread for all the things I am doing.  If I use AxEXEs then
everything is time stable and things appear smooth.  On top of that
there are hardware AxEXEs that interface external hardware.  Several of
these require smooth timing as they ramp devices sometimes with 2 mSec
steps.

I have a skeleton for an ActiveX EXE that I am working with however it
deviates over the five AxEXEs that I need.
The only place I know of to publish this is on planet source code.
Is this an OK place?

Me?  Well I am a retired electronics design engineer.  42+ years behind
the mast.
I designed hardware for hand held electronics all the way up to
multimillion dollar systems.  I wrote code in assembly language (back
in the old days of 8080) wrote PLM86 (Intel language) for embedded
computers, BASIC, C and assembly for PCs, assembly drivers for CP/M and
wrote simple operating systems for Altair and IMSAI before there was
CP/M and DOS.  Watched Bill Gates grow up and loaded Bill's first BASIC
interpreter from paper tape into my CP/M system using the hardware
interface I designed and the assembly language drivers for I wrote for
CP/M interfacing a REMEX paper tape reader/punch.  I also published
many articles in the national magazines of the time.  but no more. 
things change too fast now and especially then.
I am not a Windows fan or Windows person but that is what I am stuck
with.  I am struck by the shortcomings of VB6 but find it to be nearly
complete and very useful and much easier to get the job done than any
other language.  Too bad M$ is so blind and money grubbing.  VB.net is
really C#.net in disguise.
The code I am writing now is the most challenging, and I like it.

Where do these Images come from - from a Video-
Source? ... if yes, how many of these Videosources
are there - what's the Frame-Rate, the Frame-Dimension,
the Frame-Format (already RGB?).
As to your Image-processing - let's take for example
this 50msec-thingy - do you want us to take a look?
I'm sure we can bring that timing down significantly,
if you just "want to talk about it" (and post the code here
for example).

Yep, that much is clear - my question was, why you
felt the need to span these threads? ;-)
You're probably using a multicore-cpu - but will
all your users have one of these?

Ok, so is each of these AX-Exe-instances handling
a different Video-Stream-Source?
Where does the "timing-pressure" come from?

What are these "other things" - CPU-intensive
things, "waiting-intensive" things?

So you mean, you span even more threads aside from
the ones you've just described above (for the incoming
video-streams, as I've only guessed)?
So, what do these additional threads do (in relation
to the other threads you roughly described above)?

That may be, especially if "waiting" for device-responses
is involved.

Oh my - you cannot get enough of them, do you? ;-)

Are these cameras, or yet other devices? And yes, for
such hardware-related stuff, which involves waiting for
constantly incoming data in fixed time-intervals, threads
(or alternatively dedicated processes, which can be
normal VB6-Standard-Exes) are a good idea.

But seriously, and not surprising anymore, you are in
"AX-Exe-Interface-Hell" here. <g>

What about replacing (at least some of) these AX-Exes
with normal Standard-Exes in a first step - would
you want to go there to get rid of the Interface- and
Registration Problems?

I would seriously start working on that, at least for
the AX-Exes, which are interfacing with Hardware.

Maybe let's start with one of your devices, which
has a relative low "datarate" - generally the best
approach for such hardware-bindings which
provide you with constant data-streams is, to
develop a RingBuffer-approach with a certain
"depth" - maybe starting with one that offers
5seconds data-depth.
This way you can write a wrapping Standard-Exe,
which is selfcontained and does not initiate
communication - it will only be responsible to
fill in its RingBuffer-Slots.

All other participants in your scheme (other
Processes/Threads which want to consume this data)
will only need access to this RingBuffers memory-
area.

Not anymore, because I wasn't aware, just how
*many* of these AX-Exes you're handling - really
would recommend, to get rid at least of some of them
in a first step.

So let's just start somewhere, with one of the simpler
ones, and re-implement the "external stuff" it does
in a RingBuffer-approach in a normal VB-StandardExe.

So we're roughly the same age - but my question regarding
more of "your background" was really only a technical
one - perhaps I should further use the term Ralph is
occasionally throwing in (but which at least in german
conversational contexts I do not like): "problem-domain"

Olaf

Show quote Hide quote Throwing my 2 cents in here ... <g>

I've never worked on a multi-threading design controlled by a single
process, that I didn't have to stop - go back - and remove about half
of them.

This iteration process usually occurs about 3 or 4 times before
release.

There is nothing wrong with simple signalling between processes.

-ralph

[Excessive usage of AX-Exes]

Not sure, what you say exactly with the above statements...;-)

But, yeah - it seems that you mean this as an encouragment
for BeeJ (as my posting was meant also), to start working
on a simpler communication-structure, between "well-isolated
sub-problems" (encapsulated in VB-Standard-Processes first).

Cross-Process/Thread communication per OLE (as AX-Exes
do) is "nice and well" for simpler Threading- (Backgroundworker-)
stuff, but there are other mechanisms with more control
(and without blocking-issues) and also better performance,
as e.g. simple shelled VB-Standard-Exes, which take their
Init-Settings (Ports to listen on, or whatever) per Command-
String - and then do the Hardware-communication and place
the incoming data in a Shared-Memory-Area (the already
mentioned Ringbuffer-approach).

Such a shared Memory-Area can be spanned under a single
given "StringKey" (no matter which of the participants
comes first) - and the communication can then either
be a constant polling from the Main-App (checking for
"DoAction-Flags", or "some current RingBuffer-Index"
inside the shared-memory-area) ... or (avoiding the polling)
simple PostMessage-Calls, which can inform the Main-
App "to look and take action now" at the shared-mem-area
(thereby posting the latest RingBuffer-index for example).

These dedicated "satellite-hardware-capturing-processes"
can in the first run even have a simple GUI, to show information
about the locally incoming data in a simple Form...but later
they can either be "elevated" into real system-services
for example - or simply reintegrated over a "non-ActiveX-
Exe-Threading" - as soon as they run "proven stable" (without
larger changes on the already established codebase and the
shared-memory-code, simply omitting their "Info-Form").

Olaf

Show quote Hide quote Yes, that is what I meant to do. <g>

We are both suggesting to go back to basics. You from a mechanical
view - I from a practical design view.

There is a general KISS Rule in programming which I found to be as
'Golden' as such rules get.

Whether, chewing on threads, signals, timers, states, or interfaces,
if you start accumulating AND herding a 'bunch' of them (very
scientific quantification term) - especially to the point that odd
things starts happening - something is wrong on how you are going
about it.

-ralph
<g>

A web cam is used but not while the Ax stuff is running.
There is no video being processed by the Ax.
The external hardware is generating async random events.
The Ax is outputting async data (from the main app) to the external
devices.
He image processing at this time when other Ax things are happening is
that images are being slid around or otherwise manipulated.  this needs
to be smooth.

On Tue, 31 Aug 2010 20:01:53 -0700, BeeJ <nospam@live.com> wrote:

I have no clue what your problem domain looks like. I really have no
clue as to the exact cause for the errors you are getting.

However, I do know that you had us chasing down what appeared to be a
simple registry problem - that frankly shouldn't be happening, and
should have been easily repaired. We then learned there are a ton of
other stuff going on. Then we learn the DDE server is erroring out. To
me that smacks of a too complicated, over engineered, design.

To paraphrase McKinney - "It doesn't matter how smooth it is, if it
doesn't work".

-ralph

Regarding the first PC (non-working PC) not being able to Set an AxEXE
object.
What VB6 or system .dll would be involved?
I have turned off virus scanning but am wondering if other protection
apps might be involved.
I cleaned out the registry as best i could then recompiled.
The registry scan showed no related (as far as i can tell) problems.

Something new is happening on the second PC (working PC) that I have
never seen before.  When I start the main app, is see two windows pop
open and close quickly, one after the other.  Too fast to see what they
are, just the outline of a window.  I am going to try to isolate what
is causing this.  Probably unrelated.  The main app is working and so
are the AxEXEs (except for the close problem of one of them).  Images
are smooth.

Why doesn't this work (sendmessage)
Radio Button Bug?
file and folder permissions
Google is the new AntiChrist
Re: VB5 Runtime on Windows 7
PAUL CLEMENT (MVP) IS A TROLL
Fastest (best) way to Extract Daily Figures
Lockup
Create Shortcut
Showing/Using Sort arrows on vb6 listviews?