Short answer or long answer?
Short answer is : NO.
Long answer is : Sort of.
In effect you are asking for something for free. What you
are asking for is a way to have subs or functions in your
runtime objects fired (simultaneously) when some other
event occurs.
But even if there was a black box answer for you, wherein
you do not have to keep an array or collection, SOMETHING
else will have to. This is the nature of things. You can't
get something for nothing...
Hence the short answer of NO.
To work with this, you should forget about Events and
trying to fit in with the RaiseEvent method. Use Interfaces
instead. If you need help on that post another message.
You will still have to parse the message and then you will
be able to call the appropriate Interface method on each of
your objects. At times, your objects will simply have no
implementation or they will have a fast exit in their code
for the given action.
If you envisage thousands of users, and speed is more
important that memory, then have lots of collections or
arrays to hold the appropriate lists of players to perform
the actions on. It is far faster to go through a collection
of 500 "interested" players than to go through all 1000
calling the same method on each (even if they have fast
exits in their code).
Now on to the long answer, which is shorter in text because
I have not had a huge amount of experience in this area.
USing the API, you can create things called Events (see the
CreateEvent API and others). Using this in conjunction
with something called anonymous pipes, you could have your
main app spawn many child processes - each one with a pipe
to the main app. Each of the children are told to
WaitForMultipleObjects which effectively puts them to sleep
until some event wakes them up again.
Now the main app gets something from a player and using the
Event that was created, calls SetEvent to tell the children
that an event has occured. Only those children interested
would wake up because they were waiting for this particular
event.
Upon waking, the children call PeekNamedPipe and WriteFile
to read/write data to the parent.
How this will help you - once you get over the learning
curve - is that it will be more of a true multi-tasking
application so that your OS will be able to handle the load
far better (especially if running on NT). It will mean
that you do not need to have any lists of objects at all
(because the API has done this for you) and it will mean
that only those objects that are truly interested will
respond.
Phew, I hope that was in some way useful..
One final note here is that I would assume you can not get
up to the thousands of users anyhow, because you would run
out of sockets on the server end. How many do you envisage
having?
Cheers