Wiki Home

RAISEEVENT


Namespace: People
RAISEEVENT() in VFP8 acts as the pubisher in Loosely Coupled Events.

Questions:

What is the difference between calling the method directly and using RAISEEVENT. RAISEEVENT doesn't appear to actually create a windows event. It feels like it just calls the method. Is this true?

Yes. But it looks different. To developers, thats pretty important. For example, if I'm tooling around in a class, looking for some specific code or hunting down a bug and I see this code:

USE myTable
this.DataOpened()

I would expect to see relevant class code in the DataOpened() method. If there wasn't useful code there, I would either think the method call is either superflous or intended to be some kind of abstract method. (I should note that with BindEvents my use of abstract methods via inheritiance can go way down and I'll still get the desired effects, only this time, it'll be more flexible.)

On the other hand, if I saw code that looked like this:

USE myTable
RaiseEvent(this, "DataOpened")

I would know exactly that DataOpened() is really just an event, and probably doesn't contain the code I want. But it also indicates that whatever I'm looking for might possibly a delegate of that event located in another class. With the normal method syntax, this indication is not clear, and I could be lost for quite some time before I realize what the code is doing.

So, essentially, it's a preference of convention. I'm sticking with using RAISEEVENT() where I'm raising an event, and I'll use the method syntax to call a method.

Also, if you use BindEvent() with bit 0 cleared at the 5th parameter, this.DataOpened() wouldn't call the bound method. -- Peter Crabtree
Has anyone checked out if RAISEEVENT() makes the named method appear in the Event Tracker? If it does, that may be THE important difference.

VFP will only track it's native events, the ones it has listed in "Available Events" in the Event Logging dialog. I think that RAISEEVENT()'s ability to raise custom events is far more important than it's ability to raise standard ones (that can be logged), so I think the important difference has more to do with the conventions class designers follow and not this feature of the debugger.
See Also: Event Binding Sample, Native Event Binding, Loosely Coupled Events
Contributors: Mike Helland Peter Crabtree
Category VFP 8 New Features
( Topic last updated: 2003.04.16 05:40:33 PM )