by Philippe DesRosiers (1 Submission)
Category: OLE/COM/DCOM/Active-X
Compatability: Visual Basic 3.0
Difficulty: Intermediate
Date Added: Wed 3rd February 2021
Rating: 
(6 Votes)
Using DCOM? Remote instantiation? well now you can respond to events from a remote component without freezing the server app!
VBcoders
Implementing an event stack
Implementing an Event Stack in VB
applications are fast becoming, indeed, have already become, a major focus for
new development tactics. It's just not enough anymore to write a puny little Access
database application and hope you won't need to implement it in a network
environment. More and more distributed applications are relying on an n-tier
model to get the job done. If you haven't yet had to deal with the increasing
demands of LAN, WAN and intranet-deployed apps, you might as well get ready,
because you'll have to eventually.
can run as a standalone EXE on a remote machine. Because they run
out-of-process, unlike DLLs, multiple instances of the same class (perhaps
called by multiple applications on many different machines) can be accessed all
within the same process on the server machine. The EXE loads once, supplies the
class interface to whoever needs it, and when it's no longer needed, the EXE
unloads. Actually, it's much more complex than this, but if you want to learn
DCOM, read a book.
So what's the problem?
revolution in computing, a watershed in distributed blah blah blah… with one
major drawback (at least for those ActiveX servers developed in VB). It's not
asynchronous.
through multithreading or some other trickiness executes at the same time as
your application code. Instead of calling a method of your class to, say,
retrieve ten thousand records from an SQL database, then waiting while it
executes, then proceeding with your code, asynchronous execution would allow
you to call the method, which would return immediately, allowing you to
continue execution. In this example, when the class instance had completed
fetching the SQL result set, it would, say, raise an event to let your app know
that it was finished. If you use ADO with events, you know what I'm talking
about.
or class raises an event trapped by the parent application, before the control
code can continue executing, the application has to execute its event code. For
example, when the Click event is raised, all the event code executes before
returning execution flow control to the ActiveX control. If you don't believe
me, try it yourself. You'll never receive a MouseUp event before you finish
processing the MouseDown event.
code runs in-process, i.e.: your app is the only one using it, so it doesn't
really matter if the control code stops execution while it waits for the event
to return. In fact, this is probably for the best. Who wants to receive the
MouseUp Event before you finish processing the MouseDown event? But with a DCOM
server component, running on a remote machine, that code can be executed by
hundreds of users at once, could be raising dozens of events at any one time,
from any number of classes.
to your app, then has to wait (while the application executes ten thousand
lines of code) before regaining execution flow control, the server is sitting
there, waiting for you to return flow control. While you're processing the
event code in your app, your preventing the server component from doing it's
job.
An event stack.
What the heck is an event stack?
Shades of linked lists and other murky memories from OOP theory courses you
slept through at school, right? Not so, my skittish friend. It's actually a
piece of cake to implement.
start sending me e-mails, what we're doing here is not technically a stack.
Since a stack uses a Last In First Out (LIFO) implementation, it's unsuitable
for processing events in the order that they arrive (unless you're into that
sort of thing). Technically, I guess you could call this an event pipe, or
list, or funnel, but stack sounds cooler. Say it with me. Stack.
store them for later processing. It's sort of like the transmission on your
car. Your transmission allows the engine and drive shaft to spin at two
different speeds without killing you and destroying your car. An event stack
allows your app to run and receive events from the remote DCOM component,
without taking execution flow away from that component. All right, so think of
your app as the wheels, and the DCOM component as the engine. Make more sense
now? No? Well I'm a VB geek, not a mechanic. Just stay tuned and you'll get it
eventually.
Okay, so what do I need?
timer control? If so, you've got all the knowledge you need to implement an
event stack. If not, well... I guess you're out of luck.
Get to the point, already.
event stack. Obviously there are any number of improvements and changes you
could make. Among others:
Define a cEvent
class with a parameters collection instead of a UDT to hold your event
information.
Define an EventStack
collection with Push and Pop methods to contain the various events.
Use the SetTimer API
instead of the VB Timer control to trigger stack processing.
the information we're going to be receiving as parameters from the event. Let's
take a grossly simplified example. I've created an ActiveX DCOM component
that's running on a server machine. It exposes a class called Xchat,
whose purpose in life is to receive information via a Post method:
Public Sub (Info1 _
Info2
As String, _
Info3
As String)
module which will pass this information to all the instances of the Xchat
class, by raising the Dookie event:
Public Event
Dookie (Info1
As Long, _
Info2
As String, _
)
of ways; allowing a machine to poll the server to see how many connections are
active, as a component in a simple chat program, or a low-tech communications
protocol between apps running on different PCs. You get the idea.
parameters we know, so let's create a User-defined type (UDT) in a regular .BAS
module, to hold the event parameters.
As Long
As String
As String
stack (let's say a Timer event and an Error event), you might want to add an EventID
member to your UDT so the eventual processor of the events knows which event
it's processing. Likewise, you could add a ControlID if you want to trap
events from different controls, etc.
contain the same parameters?", I hear you ask. Good question. Like I said,
this is the simplest way to create an event stack. If you don't know
what parameters you'll be receiving, you could implement a Parameters
collection as a member of an Event class, which in turn would be
contained in an EventStack collection, etc., etc.
Step 2: Creating the stack
to hold all of our event information:
t_Event
information. We'll add events to the array, one at a time, as we receive them.
Step 3: Trapping the event
app. If you want to receive events from this component, you need to declare it
using the WithEvents keyword. So create a form in VB. In the code view for
the form, right after the
Explicit, don't you? Good.) type the following:
Xchat
As Boolean
remote component type libraries, configured it with Dcomcnfg.exe, and a
whole bunch of other stuff that is beyond the scope of this article.
the code view window, you should see xc_Remote show up in the list of available
objects. Click on it, and like magic, we're transported to the Dookie
event.
to become apparent. In the normal course of things, if this were a regular
class, a DLL, or an ActiveX control, you would do something like this:
As Long, Info3As String)
'.
'.
'.
'Execute
ten thousand lines of
'time-consuming, processor intensive code
'.
'.
'.
events per second, possibly to multiple clients, each of which wants to execute
its ten thousand lines of code before returning control to the server. See a
problem?
traditional event code with something like this:
Private Sub xc_Remote_Dookie(Info1 As String, Info3
Dim
If
Exit Sub
End If
On Error GoTo
)
ReDim Preserve
+ 1)
err_Reentry:
On Error GoTo
Info1
Info2
Info3
Exit Sub
err_EmptyArray:
ReDim
Resume
End Sub
information and slap it into our event stack, and then returns control to the
component that raised the event. Since this code will execute in a fraction of
the time it would take to actually fully process the event, it doesn't take
control away from the server component for too long, and allows the
server to continue doing its job.
Step 4: Processing the event
form, and set the interval property to some suitably small period, say 200 milliseconds.
The Timer event is where we'll process all the events we've trapped in
our stack, so we want to process the stack often enough to stay abreast of the
events being raised by the server, but not so often that we're constantly
interrupting client execution to handle the stack. After all, presumably this
application has other things to do.
to the Timer event:
Private Sub
Static
Dim
Dim
If
Exit Sub
End If
On Error Goto
)
On Error Goto
'.
'At this point, we
can execute some
'code to process
a_EventStack(0), since it is
'the oldest event in
the stack.
'.
'.
'.
'Remove the oldest
event.
b_LockStackProcessing = True
If
Erase
Else
For
a_EventStack(i + 1)
Next
Redim Preserve
End If
err_EmptyArray:
End Sub
procedure with the b_Reentry variable, since the timer might tick ten
times before we finish processing the event stack, and we don't want to process
events out of turn.
protection, I've also added a global stack protection variable b_LockStackProcessing.
I use this so that no events can be added to stack while I'm resizing it. Since
the server component is running asynchronously to the application, it is
possible (though unlikely) to receive server events while resizing the stack. I
don't mind receiving events while I'm processing the stack, but I don't want to
overwrite existing events while I'm resizing, so I lock the stack.
the stack every time the timer ticks. Obviously if you plan on receiving more
than one event between timer ticks, you may want to process the entire stack
every time the timer ticks. Also, since the stack is an array, it takes some
time to shuffle all the events up one slot. You may want to implement a
collection instead, which, though it takes more memory and resources to handle,
can allow you to remove the event from the stack with one line of code.
here, which I leave you to implement, is a flexible timer. Every couple of
times you process the stack, you check to see if there are a large number of
events in the stack. If there are, you decrease the timer interval. If there
are very few events in the stack, you increase the timer interval. This means
that when the server is flipping out and flooding you with events, your app can
devote more time to handling those events, and when the server component is
twiddling its thumbs, your app can devote more processing time to other tasks.
That's it?
was? While an event stack may not be necessary for small client-server
applications, it sure can save your bacon if you're deploying on an
Enterprise-wide scale. It can also be of enormous value if you want to dispatch
events asynchronously, just for the heck of it. Best of all, this technique can
be used in reverse, within your ActiveX server components, as a method stack,
processing method calls asynchronously so that the server component interface
is always available to clients.