Is there a way to tell in code if an event handler is implemented or if a handler has already been added without raising the event?
Thanks,
- karen
No.
Ummm I think I did find a way…
For example this seemed to work:
[code]Function PaintImplemented (theContainer as ContainerControl) As Boolean
Dim ClassInfo As Introspection.TypeInfo = Introspection.GetType(theContainer)
Dim Methods() As Introspection.MethodInfo = ClassInfo.GetMethods
For Each Method as Introspection.MethodInfo In Methods
If Method.Name = “Event_Paint” Then Return true
Next
End Function
[/code]
Am I doing something unsupported that should not be?
This will only ‘work’ for items placed on a layout that implement the event. It won’t work in the case of subclassing or AddHandler. It’s also depending on implementation details that could change in the future.
Not what I wanted to hear, but thanks for letting me know.
- Karen
Couldn’t you try adding a handler and if it doesn’t work then it must be implemented…
try
AddHandler Canvas1.Paint, AddressOf testPaint
RemoveHandler Canvas1.Paint, AddressOf testPaint
MsgBox "Paint is unimplemented"
catch e As RuntimeException
MsgBox "Paint is already implemented"
end
The one gotcha I see is that an event handler with no code gets stripped and AddHandler will be able to add a handler.
A handler with no code is implemented as doing nothing
But it is implemented
When I run that code and the Paint handler is completely empty I get “Paint is unimplemented”, meaning the AddHandler worked. But adding anything, even just a space to the handler then the code produces “Paint is already implemented”.
I’ll have to discuss with Joe
This seems like a bug more than anything that its not being flagged as already implemented (since it is - I can see what gets passed to the compiler)
Yup - its a bug
Just out of curiosity, why do you need this?
Because of what Joe said I decided on a different solution.
What I was trying to do is write flexible reusable generic control that allows a lot of flexibility for specific implementations. Here is a high level simplified overview of what I wanted to do:
I was planning to have a class that can be subclassed who’s events may or may not be implemented in a subclass. Subclasses of it would be contained by a different container class. There could be any number of these contained class instances and they could all be the same or different subclasses of the base class.
I wanted to have to have the option (without having to code it specifically for each use) to transfer unimplemented base class events for those contained subclasses to the container class. So in this case some instances of the contained class (because they may be different subclasses) may have events implemented and some not.
The inner subclass implemeted events should always take precedence over any event code/settings on the containing class.
I did not want to have a lot of booleans/properties which someone may forget to set for all of this to work smoothly together. That is why I wanted to detect if an event was already implemented.
BTW It seems to me one SHOULD be able to do that through introspection as events really are just methods in the compiled app and one would expect to be able to do it.
- Karen
Main class implements ALL the events
Those just call methods which the subclass can override selectively
The main class also has a default implementation
Anything not override by the subclass will use the main class implementation
[quote=147230:@Norman Palardy]Main class implements ALL the events
Those just call methods which the subclass can override selectively
The main class also has a default implementation
Anything not override by the subclass will use the main class implementation
[/quote]
Something like that was my first thought, but that means all the events have to get implemented and methods that call the. That introduces more overhead when the events are not needed… also overriding would be needed which is not very discoverable without looking at documentation.
I wanted to keep things simple and more discoverable for the end user. To me that means setting up as much as possible by using only events in the way, from the outside at least, the rest of the framework does.
To that end I would DEFINE all the events I MAY want implemented on the container for the contained classes. In the container class’s open event, I would check which of those events were implemented. If any were I would use Addhandler to add implementations for those events to the contained classes, unless they already had the events implemented.
That makes the contained subclasses more flexible and reusable (they can be either generic or specific), and have the Container class act as one would expect for the framework, and eliminate potentially significant unnecessary method call overhead.
Anyway those were my thoughts… of course there would be a lot more implementation detail but that was the general outline
You could do what sections of our framework do… Have the user return True in the event. Like MouseDown and KeyDown.