Purpose of AS EVENT following CLASS classname

[Patrick Mills]

I'm trying to learn how to work with objects in PowerBASIC, and I'm currently trying to learn about event sinks and sources. In the help file, the event example uses a class named EvClass, defined thusly:

CLASS EvClass AS EVENT
  INTERFACE EvStatus AS EVENT
    INHERIT IUNKNOWN

    METHOD Done
      MSGBOX "Done!"
    END METHOD
  END INTERFACE
END CLASS

Here's my question - does omitting the AS EVENT from the CLASS line in the code above potentially create a problem with the class being able to receive events? I have coded my own class, but used a second interface with the AS EVENT clause, leaving me free to omit it from the main interface, but I also had to omit AS EVENT from the CLASS in order to get it to compile.

So far, my AS EVENT interface is receiving and processing events, but I am wondering what the purpose of AS EVENT on the CLASS line is, if it's not strictly necessary. Am I risking some kind of error or creating a problem if I leave the AS EVENT off of my CLASS definition line? Including it as part of the CLASS definition seems to preclude the use of properties or function-methods throughout all interfaces to be used with the class (whether they are defined AS EVENT or not). Omitting it allows these features on interfaces that are defined without the AS EVENT clause.

[Bob Zale]

The PowerBASIC Doc says...

"If a class is an Event Handler (it contains code to handle an event generated by an Event Source), the AS EVENT attribute must appear on the CLASS statement and each Interface statement."

We believe it's prudent to follow this guideline, particularly since there doesn't seem to be much benefit (if any) from combining event and non-event interfaces in one class.

Best regards,

Bob Zale
PowerBASIC Inc.

[Patrick Mills]

Thanks for your comment.

Since I am doing exactly that (combining event and non-event interfaces in one class), I expect that I'm doing something the hard way because I don't see the easy way.

Perhaps I should have first posted a question about the proper design for my example. Before I ask for further help, I think I'll take a second hard look at my design - If there's a better design for what I want to do, I'd kind of like to find it myself, since the whole point of what I'm doing is to learn more about OOP in PB.

[Dominic Mitchell]

...since there doesn't seem to be much benefit (if any) from combining event and non-event interfaces in one class.

It makes it very easy to tell which events belong to which controls in a type library with multiple controls.
How would you know which class(control) implements a certain group of events?

[Patrick Mills]

Dominic - I'm a little embarrassed to say that I am such a newb to objects and events that I'm not really even sure what your comment means.

I am still puzzling over the apparent fact that if you strictly adhere to PB's requirement to declare the class itself "AS EVENT" when any interface used with the class is declared "AS EVENT" that you cannot then implement any properties or method-functions in *any* interface for that class.

When Bob says "there doesn't seem to be much benefit (if any) from combining event and non-event interfaces in one class" I'm still a bit mystified about why the apparent benefit of being able to implement properties and method functions in your non-event interfaces isn't considered to be much of a benefit.

I would be very interested in learning about *why* the PB designers think that the use of events in a Class/Interface might mostly *only* be needed in cases where you *don't* really need properties and function methods. Is it a design principle, where events are such special cases that you shouldn't implement them in a normal class and property-based interface? If so, what is the principle of good OOP design being enforced here?

I'm really not being facetious in the previous paragraph. I am still in such a learning stage that I consider it possible that there really *is* a good reason for Bob's position, and that I just don't know enough to understand it. But I'd really like to.