• Home
 · 
• OLE/COM/DCOM/Active-X
 · 
• Implementing an event stack

Implementing an event stack

Using DCOM? Remote instantiation? well now you can respond to events from a remote component without freezing the server app!

Rate Implementing an event stack

• 1
• 2
• 3
• 4
• 5

(7(7 Vote))

Implementing an Event Stack in VB
 
With the advent of COM, DCOM and COM+, distributed
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.
 
DCOM allows VB programmers to create ActiveX servers that
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?
 
This remote instantiation is all well and good, a
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. 
 
What does this mean? Asynchronous code is code that,
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.
 
The same system works in reverse. That is, when a control
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.
 
Now, normally, with an ActiveX control or DLL, all the
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. 
 
If the DCOM server component raises each of those events
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.
 
This is, obviously, not a good thing.
 
What's the answer to this dilemma? You got it, smart guy.
An event stack.
 
What the heck is an event stack?
 
Oooo. A "Stack". Scary word. Pointers.
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. 
 
Disclaimer: Before you hard-core coders out there
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.
 
An event stack exists for one purpose: to trap events and
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?
 
Know anything about arrays? User-defined types? The VB
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.
 
What follows is the most basic way I know to create an
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.
 
Step 1: Creating the event
 
First, we need to create a variable to hold
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 Post (Optional Info1 As Long, _
                 Optional Info2
As String, _
                 Optional Info3
As String)
 
And call an underlying function in a public
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, _
                     Info3 As String)
 
This kind of DCOM server could be useful in hundreds
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.
 
In this case we only want to trap one event, whose
parameters we know, so let's create a User-defined type (UDT) in a regular .BAS
module, to hold the event parameters.
 
Public Type t_Event
   FirstParam As Long
   SecondParam As String
   ThirdParam As String
End Type
 
If you want to hold different events in your
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.
 
"But what if we don't know that all the events will
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.
 
Easy enough, right? Wait. It gets even easier. 
 
Step 2: Creating the stack
 
Now we need to create a global variable in the same module
to hold all of our event information:
 
Public a_EventStack() As t_Event
 
This array will hold all of our miscellaneous event
information. We'll add events to the array, one at a time, as we receive them.
 
Step 3: Trapping the event
 
Let's assume you're using the Xchat class in your
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 Option Explicit statement (you do use Option
Explicit, don't you? Good.) type the following:
 
Dim WithEvents xc_Remote As Xchat
Dim b_LockStackProcessing
As Boolean
 
This, of course assumes you've correctly referenced the
remote component type libraries, configured it with Dcomcnfg.exe, and a
whole bunch of other stuff that is beyond the scope of this article.
 
Now, if you click on the object combo box at the top of
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.
 
Here is where the major advantage of an event stack starts
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:
 
Private Sub xc_Remote_Dookie (Info1 As Long, Info2 As String, Info3 As String)
   '.
   '.
   '.
   'Execute
ten thousand lines of 
  
'time-consuming, processor intensive code
   '.
   '.
   '.
End Sub
 
However, it's not. This component is raising dozens of
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?
 
In order to get around this dilemma, we'll replace the
traditional event code with something like this:
 
    Private Sub xc_Remote_Dookie(Info1 As Long, Info2 As String, Info3 As String)
       Dim l_Count As Long
    
       If b_LockStackProcessing Then
           Exit Sub
       End If
    
       On Error GoTo err_EmptyArray
       l_Count = UBound(a_EventStack)
       ReDim Preserve a_EventStack(l_Count
+ 1)
    
    err_Reentry:
       On Error GoTo 0
       a_EventStack(l_Count + 1).FirstParam =
Info1
       a_EventStack(l_Count + 1).SecondParam =
Info2
       a_EventStack(l_Count + 1).ThirdParam =
Info3
       Exit Sub
    
    err_EmptyArray:
       l_Count = 0
       ReDim a_EventStack(l_Count)
       Resume err_Reentry
    End Sub
 
All this really does is grab the event
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
 
Now let's add a timer control tmr_Event to the
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.
 
Back into the code view for the form, let's add some code
to the Timer event:
 
    Private Sub tmr_Event_Timer()
       Static b_Reentry As Boolean
       Dim l_Count As long
       Dim i As Integer
    
       If b_Reentry Then
          
Exit Sub
       End If
    
       On Error Goto err_EmptyArray
       l_Count = UBound(a_EventStack)
       On Error Goto 0
    
       b_Reentry = True
    
       '.
       '.
       '.
       '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 l_Count = 0 Then
         
Erase a_EventStack
       Else
    
          For i = 0 To l_Count - 1
              a_EventStack(i) =
a_EventStack(i + 1)
          Next
         
Redim Preserve a_EventStack(l_Count + 1)
    
       End If
       b_LockStackProcessing = False
    
    err_EmptyArray:
       b_Reentry = False
        
    End Sub
    
As you can see, we implement reentrancy protection on this
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. 
 
In addition to the standard reentrancy
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. 
 
In this particular example, I only process one event off
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.
 
Note: Another possible improvement on the 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?
 
That's all she wrote, boys and girls. See how easy that
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.
 
Now go forth and multiply. Asynchronously.
 
Philippe DesRosiers
e: [email protected]