I hate ColourPicker
nemo (145) 2546 posts |
ColourPicker is very badly designed. Awful. Anyone who has tried to integrate it into an existing application will attest to the mess it makes of the rest of your program. At the very least its terrible behaviour ought to be documented because it causes pain. ColourPicker was a kind of proto-Toolbox module that, like a parasite, attaches itself to your task via FilterManager and manages the picker window on your behalf. Trouble is, it leaks Wimp events like a sieve. Every Wimp event that relates to the picker window – every redraw, drag, keypress, click etc, gets picked up via a PostFilter and handled by ColourPicker… and then gets passed on to your application anyway. Even though it knows it was its event; its window; its drag. Even the redraw event for its window (which is passed on after it has redrawn the window, so there aren’t any Rectangles to Get even if you tried). So if you try to add ColourPicker to your app, you are going to have to explicitly check for, and ignore, redraw requests, mouse clicks and keypresses if they relate to the picker window, and drags and nulls for which you have no context other than your own app management. The nulls are especially annoying, as even if you have called PollIdle with a nice long delay, ColourPicker insists on getting instantaneous nulls even when the pointer isn’t in its window (never mind dragging anything) and then helpfully passes them on to you. It’s also big, ugly, stupid, supposedly extensible but no one ever has, and I hate it. But I especially hate it when it passes me events it has already handled. Message ends. |
Clive Semmens (2335) 3276 posts |
Oh good. I’m glad I’m not the only one with a bone to pick in this regard. |