[AccessD] Message Classe - was Off the wall Events question...

Jim,

And in fact my message class (not sure about the one in the demo but I think
so) has two message methods, one simple and one with all four properties
(To, From, Subj, Msg).  In point of fact of course, just because the message
is "TO" someone doesn't prevent others from seeing the message.  In fact
users have to specifically filter on the to in order to determine that the
message is for them.

I actually started with the simpler message method (just the message param)
but decided it would be helpful to have another method that one could use to
tell the listener who the message was for, who it was from etc.  I did it in
fact precisely for inter-form communication where the receiving form was
going to return a value back to the calling form, but it is generally useful
anyway.  It takes a little more code in the listening event but gives
flexibility.

BTW, I notice that you type the message to a string.  I intentionally left
mine a var so that I could if I so desired pass pointers to objects.  For
example, Drew's calendar could get a message:

To: frmCalendar
From: frmClient
Subj:
Message: PointerToTextBox

Because the message param is a variant, the calendar function can simply use
the value of the text box passed in, manipulate it, then place the value
directly back in text box since it knows what object needs the returned
value.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-admin at databaseadvisors.com
[mailto:accessd-admin at databaseadvisors.com]On Behalf Of Jim DeMarco
Sent: Thursday, February 13, 2003 8:44 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Message Classe - was Off the wall Events
question...


Hi John,

Thanks for sharing the details of your message class.  I put together a
Messenger class when I was first learning about Interfaces that I'll detail
here FYI.  Your class allows an ojbect to send a message "To" another
ojbect.  Mine works in a lister motif where an object that implements the
interface sends a message and anyone listening for messages from that object
can retrieve them and act on them.

The interface class, IMessage, contains two empty methods -
SendMessage(MessageText As String) and GetMessage().  The interface is
implemented by any class that wants to send or receive messages.

The Messenger class contains one public event MessageReceived(), one
property, Sender, that returns the type of object sending the message, a
SendMessage function that creates the message (Sender object and message
text), and calls a private function ActivateListeners that raises the
MessageReceived event so any object listening can determine if they want
this message.

To set up a class to use the Messenger declare a module level Messenger
object and implement the interface:
Private Messenger As Messenger 'need to use for its send function
Implements IMessage

In the class IMessage_SendMessage function call Messenger.SendMessage
passing in the message text and a reference to the class (Me).
IMessage_GetMessage interprets the message and acts on it.  An Init function
where we'll pass in a Messenger object to use to pass messages (this
Messenger object uses WithEvents and is created on the calling form or
module).

To use the class declare a module or global level Messenger object
WithEvents and any objects that will use the Messenger:
Private WithEvents g_oMessenger As Messenger
Private oC1 As Consumer1
Private oC2 As Consumer2

Initialize the consumers to point to the Messenger (you could have more than
one Messenger variable handling different types of message).
    Set g_oMessenger = New Messenger
    'initialize all objects that need to communicate to same messenger
object
    'this causes them all to react to the messenger's MessageReceived event
    'in this case g_oMessenger
    Set oC1 = New Consumer1
    oC1.Init g_oMessenger
    Set oC2 = New Consumer2
    oC2.Init g_oMessenger

Now we just need to listen for the MessageReceived event:
Private Sub g_oMessenger_MessageReceived()
'notify any listeners that there is a message
'route the message to the appropriate listener
    If TypeName(g_oMessenger.Sender) = "Consumer1" Then 'any obj that needs
                                                        'consumer1 messages
            GetMessage oC2
    ElseIf TypeName(g_oMessenger.Sender) = "Consumer2" Then
        GetMessage oC1
    End If
End Sub

The GetMessage function is a wrapper for the interface class:
Private Function GetMessage(obj As IMessage)
    obj.GetMessage
End Function

There is also a SendMessage function to wrap the interface function of the
consumer classes as well.

Anyway, just wanted to run an alternate method by the list.  A planned mod
to this class is to use XML as the message format.

Thanks,

Jim DeMarco
Director of Product Development
HealthSource/Hudson Health Plan


-----Original Message-----
From: John W. Colby [mailto:jcolby at colbyconsulting.com]
Sent: Thursday, February 13, 2003 1:28 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Off the wall Events question...


Drew,

Given your familiarity with VB why don't you create an ocx.  OCXs can raise
events.

That could be placed on a form (or even in a class which forms a wrapper to
the ocx), then a reference to the ocx itself (not the class that contains
it) could be dimmed in any form that needed it and it's event sunk in the
form (or class).

Something of that nature anyway.

I used an ocx for the comm object from visual basic.  By placing it on a
form I could sink it's events in that form.  I never tried to make the comm
object dim a public object but if you can do that then other forms can set a
reference to the same object by getting it from the open form.  Each form
that gets a pointer to the object should be able to declare it's own
instance of the object withevents thus could sink the calendar's events.  I
don't know how you are going to tell the object what form / control is
requesting a date service so that is a bit muddy.

In a2K (which has RaisEvents) I built a message class for exactly this kind
of situation.  The message class was dimensioned public in a module, thus
any other class that wanted to use it could dim a variable of type dclsMsg
(Deep class!).  The msg class simply had methods that anyone could call with
a mail type of From / To / Subject / Message parameters.

Anyone could send a message simply by referencing the global message class
and calling the method.  The message class then raised an event passing
along the 4 parameters.  Anyone that wanted to receive messages from the
message channel dims a dclsMsg withevents, points to the global msg class,
then sinks the message event.  Thus any message on the channel gets to
everyone watching the channel.  It is up to each watcher to watch the "to"
param for it's name or something that it knows means the message is to it.

I used a form that when opened, grabbed a pointer to the message class, then
watched for it's name in the "To" param.  It performed it's action, then
returned a message to the caller found in the "from" parameter, putting it's
name in it's message's From param.  The caller was watching for a return
message.  Does that make sense?

To: "frmCalendar"
From: "FrmClient"
Subject: "txtCreditAprvdDate"
Msg: #StartDate#

the calendar processes the date, and when the user finishes with the
calendar, returns the message:

To: "FrmClient"
From: "FrmCalendar"
Subject: "txtCreditAprvdDate"
Msg: #ManipulatedDate#

The calendar form has dimmed withevents lclsMsg as dclsMsg and set it =
gdclsMsg.  It then sinks the message event from the message class.

sub ldclsMsg_Msg(strTo as string, strFrom as string, strSubject as string,
varMsg as variant)
	'Do something with the message when it arrives
	if strTo = me.name  then
		'Do something cool with the message
		'Save the strFrom to know what form sent the message
		'Save the strSubject to know what control on the calling form the date is
going back into.
		'manipulate the date
		'When the user is finished manipulating the date...
		ldclsMsg.Msg strFrom, me.name, strSubject, #ManipulatedDate
	endif
end sub


With a message channel like this, anyone can send a message, whether or not
they are watching for a return message.  Anyone can watch for messages
simply by dimming a variable:

dim ldclsMsg as dclsMsg
	set ldclsMsg = gdclsMsg 'this was initialized by the framework

Once dimmed, the class (or form) watching the message channel sinks the
message event

sub ldclsMsg_Msg(strTo as string, strFrom as string, strSubject as string,
varMsg as variant)
	'Do something with the message when it arrives
	if strTo = me.name and strFrom = "frmCalendar" then
		'Do something cool with the message
		if strsubject = "txtCreditAprvdDate" then
			txtCreditAprvdDate.value = varMsg
		endif
	endif
end sub

Notice that you can have as many of these message channels as you want.  Set
up a global message channel just for the calendar.  Only forms wanting to
use the calendar watch the channel.

So... obviously this can only be done using a message class in A2K or above
since only A2K or above can do the RaiseEvent in the message class.  However
in A97 you might be able to build something similar by using an ocx that is
referenced in a variable in a class somewhere.  In fact you might even be
able to implement a "message ocx" that performs the above functionality.
Dim the ocx in a public variable, then anyone that wants to send messages
just calls the ocx's message method passing the params.  Anyone wanting to
listen to the message channel dims a local (to the form or class) variable
to hold a pointer to a message OCX, then sets that pointer to point to the
already initialized global message ocx.  Sink it's events in this class and
form and watch for messages.

Anyway, this is overly long and perhaps not at all interesting, but after
the thread today about withevents I thought I'd throw it out there.

In fact, I just went looking and all of the code for the message class is
available in a demo on our web site.  Click on my last many to many
article - May 2002 - Combining Withevents and RaiseEvents.  At the top of
the article is a link to Demo.  Download the demo and watch three forms send
and receive messages on a message channel using exactly the process
described above.

John W. Colby
Colby Consulting
www.ColbyConsulting.com