a) I have subclassed a Canvas call it MYCANVAS
b) this canvas has a custom event, call it MYEVENT with an argument of MYCOLOR
c) when a particular action happens within MYCANVAS, it raises MYEVENT
Now the user code external to MYCANVAS, can see this event…
What I would LIKE to happen is have the user be able to call their own code to manipulate MYCOLOR, and then have MYCANVAS respond based on what the user returned.
<do some stuff>
mycolor=&cff0000
MYEVENT(myCOLOR)
// would like myColor to be what ever the user altered it to be with THEIR code.....
// OR return the passed color unchanged, if they did not implement the event response on their side
What I want is for the user to decide what (if any) color selector they want to implement…
kinda like a plugin… but not a plugin if that makes sense
When the canvas needs a color it raises the event, the users does whatever they want to provide a color selection and that can be returned to the canvas
Basically the canvas has
event def GetColor() as Color
which the user implements and returns a color from
But you also want the user to have a “method” like way to set the color ?
You’ll have to have a different name - like SetColor that the using code can call when they want.
So I raise the event just like any other custom event…
and the user in their response code would call “setcolor” (or a name of my choice)
which would be a public method in my subclass canvas…
and if they Don’t want to do anything, they simply don’t do anything…
Ok… now… is there a WAY to know they didn’t implement a custom response, so I can implement a DEFAULT response?
Say I want a color, they don’t code the external event… I want to call the system color picker… So something happens when the event is raised even if the developer doesn’t implement a custom response
[quote=165236:@Dave S]So I raise the event just like any other custom event…
and the user in their response code would call “setcolor” (or a name of my choice)
which would be a public method in my subclass canvas…
and if they Don’t want to do anything, they simply don’t do anything…
[/quote]
Pretty much
except that … if you raise the event
the person throws up a dialog & grabs a color & returns “FALSE” you really still dont know
there’s no definitive way
this is a “by convention” mechanism
its the same as forgetting to return true from mouse down key down etc when you HAVE handled it
NP
This design pattern where the EVENT acts like a “request” is really useful
It lets you design reusable controls / components that can use events to get information back about their working environment without having to know about it or reach around inside other controls / windows etc
Yup
I don’t know if you saw/read the other topic about the “spreadsheet/listbox” control I am working on… but that is exactly where this is going to be used… By default the color cell type will use the “system” color picker, unless the user assigns another method, the same for the Date/Time cell types, they can supply a date picker, or it will default to “type it in”… This way they are not constrained by the type of color or date picker that I like.
