In 2019r3 Xojo added something that a lot of people have been asking for for a very long time. A way for a class that exposes events to know IF an instance implements the event.

Its literally called IsEventImplemented (see

But it remains undocumented

Previously if you wrote a class that could have some default behaviour IF an instance did not implemnent the event to alter the behaviour you had no way to know if you should operate in whatever way was the default or not.

You could never have your superclass do something like

If IsEventImplemented("Action") then
   // call the instance' code
   raiseEvent Action
   // do nothing
end if

In this case its not so bad and you could probably just use RaiseEvent without any impact. But if you wanted to do something more, like know if you should use a default color or not you had a much more difficult task

// if we had an event ChooseColor that instances could implement or not

defaultBackGroundColor = raiseEvent ChooseColor

// if setColor IS implemented we'd get a color 
// if setColor is NOT implemented we still get a color - its just all 0's
// and we have no way to know which is the case 

But now with IsEventImplemented we could know

// if we had an event ChooseColor that instances could implement or not

if IsEventImplemented("ChooseColor") then
   defaultBackGroundColor = raiseEvent ChooseColor
   defaultBackgroundColor = &cFF00FF // or whatever
end if

// now we can use defaultBackgroundColor knowing whether 
// it did or did not come from the instance

However, Xojo has chosen to not document this (see

The comment almost makes it seem as if this method might disappear despite its usefulness whether API 2.0 event have or have not been reverted.

Use it carefully !

2 Replies to “IsEventImplemented”

  1. Not knowing if a subclass has implemented an event has never been an issue for me…

    I just use the RB/Xojo convention of returning true if the event handles things.

    For cases where the superclass code needs more info back I pass in a variable ByRef. That way after the superclass calls the event it has the value.

    That makes things the interactions well defined and pretty explicit and I have never felt the need for anything more..

    1. I’ve run into this need a couple times mostly when I was working on the IDE and it would have been very handy to have known this.

      There are often ways to work around it BUT when you are trying to NOT alter the event signature in a subclass for something like Cut, Copy, Paste, Paint etc you might need to know this

Comments are closed.