Advantage of #4 is that you're not hardwiring objects together. This means that your objects don't need to be global (=potentially messy), and one object doesn't need to contain a reference to another object (=hardwiring).
btw, if we split your RGB changer into 3 components (r,g and b) then each 'thing' you need is a composite of resetbutton, slider and editbox. Why not make that composite into a new object reacting on unique new events?
You eventually create 3 such components, or you don't bother and create 1 big RGB component with 3 resets, 3 sliders and 3 editboxes. Either way: such a big complete 'rgb machine' has these methods:
- Changevalue(component,value) ' component: 0:r, 1:g, 2:b
It sends out these events:
- Colorchanged (an event sent whenever you change the color, other objects elsewhere will hear this event and update according to the new rgb settings, you could add Self to the extra field of the tevent object to actually send the rgb values to the listening objects via the event system, which is not hardwiring, yet the listener does have access to the source!)
- Colorchanging (an event sent when you are moving sliders but haven't released these sliders, afaik this is not possible with native sliders, but it is possible with canvas-based new sliders. This may be useful, you could change a palette overview with this event and update a picture (which is more heavy to update) when you send out a Colorchanged event)
- Colorstartchange (an event sent out when you first touch the sliders, this may not really be needed, but you could signal a heavy section (like an image) to not listen to Colorchanging events until a Colorchanged event has been sent, to prevent timeconsuming updates while changing colors)
It can listen to these events:
- Changecolor (for instance, you colorpick somewhere in an image, and the resulting RGB values should be sent back to your RGB sliders, the event.extra field should then contain the object that handled the colorpicking OR simply contain an int containing the RGB value, which could as well be stored in the .x, .y, .data fields for all I care)
The nice bit is that you can have as many RGB sliders as you want, you only need to create them and place them, and they will work instantly, without connecting anything. Because it sends out events, it'll work right out of the box.
Also nice: you can take them away and your program won't be buggy, it just lacks features, but it won't give errors. It will send out events, but when no-one listens, nothing happens. If however you hardwire things, you will get errors!
btw, if we split your RGB changer into 3 components (r,g and b) then each 'thing' you need is a composite of resetbutton, slider and editbox. Why not make that composite into a new object reacting on unique new events?
You eventually create 3 such components, or you don't bother and create 1 big RGB component with 3 resets, 3 sliders and 3 editboxes. Either way: such a big complete 'rgb machine' has these methods:
- Changevalue(component,value) ' component: 0:r, 1:g, 2:b
It sends out these events:
- Colorchanged (an event sent whenever you change the color, other objects elsewhere will hear this event and update according to the new rgb settings, you could add Self to the extra field of the tevent object to actually send the rgb values to the listening objects via the event system, which is not hardwiring, yet the listener does have access to the source!)
- Colorchanging (an event sent when you are moving sliders but haven't released these sliders, afaik this is not possible with native sliders, but it is possible with canvas-based new sliders. This may be useful, you could change a palette overview with this event and update a picture (which is more heavy to update) when you send out a Colorchanged event)
- Colorstartchange (an event sent out when you first touch the sliders, this may not really be needed, but you could signal a heavy section (like an image) to not listen to Colorchanging events until a Colorchanged event has been sent, to prevent timeconsuming updates while changing colors)
It can listen to these events:
- Changecolor (for instance, you colorpick somewhere in an image, and the resulting RGB values should be sent back to your RGB sliders, the event.extra field should then contain the object that handled the colorpicking OR simply contain an int containing the RGB value, which could as well be stored in the .x, .y, .data fields for all I care)
The nice bit is that you can have as many RGB sliders as you want, you only need to create them and place them, and they will work instantly, without connecting anything. Because it sends out events, it'll work right out of the box.
Also nice: you can take them away and your program won't be buggy, it just lacks features, but it won't give errors. It will send out events, but when no-one listens, nothing happens. If however you hardwire things, you will get errors!