Colour

Although the console library is under discussion, it is still common for console applications to work with GUI concepts. Typically these functions consist of image processing or conversion, perhaps even manipulating resources. A good example of this type of operation is the generation of a CAPTCHA image. The server machine creates the image, and although the image is never seen on the server, it is rendered on the client. For these reasons the Console module includes the capability to work with image data, even though there is no way of actually rendering it to a display surface.

The colour module encapsulates all of the standard windows GDI objects. These include fonts, pens, brushes, regions and so on. The main object actually encapsulates multiple types of GDI objects. The main aim here is that a GUI application can specify styles for a given drawn object. Perhaps the user is drawing a box on the screen, with some text in it. Perhaps the user has specified a particular line thickness and a particular font. This information is associated with one VGDIObject, which is then associated with the rectangle and the text.

Typically a drawing would include many visual objects, but only a few styles, each of which is applied to multiple visual objects. A caching object specific to the task of storing GDI Objects is provided. This caching object has the capacity to "apply" a GDIObject style to a device context. This method of drawing reduces the programming overhead in the paint routine, and helps to manage the problem of handling default styles, which may overlap active styles where the active style does not specify some parameters. An example might be drawing text in a style which only specifies the line type of the box that surrounds the text. Obviously a default font would have to be used and this is supported.

This group supports an off screen GDI "Scratchpad" buffer, which is always available in an application. The buffer is automatically sizing so the programmer merely asks for a device context of a given size, and he is returned somewhere temporary to render. This module allows a compromise to be made between three problems. The first problem is that it is very slow to keep creating and destroying device contexts. The second problem is that much memory is wasted, if everything that needs a scratchpad maintains one all the time. The scratch pad is available all the time, and the actual GUI would normally run on just one thread. For this reason it is reasonably efficient to simply have one scratchpad that is open all the time. There is only one GUI thread so no two functions can require it simultaneously. The final problem is that there is always one paint routine that requires a huge scratchpad, and it is undesirable to have a huge scratchpad open all the time. The scratchpad looks at the request size, and ensures that a buffer of a "sticky size" is always available. The scratchpad will enlarge the buffer if necessary, but the buffer always returns to the sticky size.

This group supports a class which can convert and contain a colour. The primary function of this module is to convert to/from HSV/RGB. In addition it also supports HTML string formats.