No announcement yet.

Purpose of AS EVENT following CLASS classname

  • Filter
  • Time
  • Show
Clear All
new posts

  • Purpose of AS EVENT following CLASS classname

    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:

        METHOD Done
          MSGBOX "Done!"
        END METHOD
    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.
    Last edited by Patrick Mills; 15 Jan 2009, 03:05 PM. Reason: Corrected title

  • #2
    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.


    • #3
      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.


      • #4
        ...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?
        Dominic Mitchell
        Phoenix Visual Designer


        • #5
          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.