Well, there is no color library as such. The color commands are woven into the gadget library and I think that the team have done a pretty good job here as, with Windows at least, there is no standard way of coloring the various types of gadget. That is, the method employed to color a string gadget, for example, is different to the methods employed to color an editor gadget and so on, and many of these require parent controls to be subclassed etc. It's a minefield - just the Windows way of it all!
This would have resulted in a heck of a lot of work for Fred and/or Freak.
Personally, I don't go too much for colors with my GUI's anyhow.
Of course, depending on what I am doing, I will occasionally color a gadget using pure API methods. It just depends. Other people use Gnozal's PureColor library etc.
As for the color commands being poorly implemented? Well for the reasons you cite, I would have to disagree with you completely here. In mixing PB library commands with native API, you are, if you are not very careful, asking for trouble. Take a tree gadget for example; native API deals with handles to individual items which is a pain in the arse (to put it bluntly!) Now, the PB gadget library wraps this up very nicely and offers us, instead of these esoteric handles, the use of nice indexes for each item added to the tree gadget. This, as I'm sure you'll agree, makes things a hell of a lot easier when dealing with tree gadgets. And here's my point; if you start mixing the ease of the PB gadget library (with tree gadgets) with native API, you'd better be very careful because Windows will not recognise the item indexes which PB allows us to use. You mix PB gadget commands and API tree commands and you should expect pain! Much pain!
(srod does his Mr T. impression - very badly!) And who takes the blame for any problems resulting from mixing PB gadget commands and native api in this way?
In my opinion, it is the programmer and not the PB team. Since the gadget library sits atop the native common controls library and offers ease of use as well as a lot of flexibility, you must accept that there is a trade off between this ease of use and compatibility with the API. If the two were 100% compatible, then there would be no point having a PB gadget library in the first place.
No, it is the individual programmer's job to balance a use of the gadget lib with the api and to work around the inevitable compatibility issues. Personally, and with a lot of experience with working with the Window's common controls, I can mix the PB gadget lib and API quite freely, but only through a hell of a lot of trial and error and much trawling through MSDN etc. With this kind of experience, you do get to know, in advance, where problems may occur and with this knowledge comes a real appreciation of just how good the PB gadget library is.
END OF RANT!
)
