Module skinning

"chris rempel" <jugg-3DLK4WMMzz8LR9k7Rz+ddgC/[email protected]> Thu, 10 Jul 2003 01:06:15 -0500
Newsgroups gmane.comp.windows.shell-shocked.devel
Message-ID <[email protected]>
Hi all,

I looking for input on what the prefered method of skinning modules is now-a-days, the following is what I've come up with...

I've taken Maduin's skinning from systray and label, added my own ingredients and stirred a bit, and created a method for drawing "boxes" which can be implemented either as the background or as sub boxes drawn on the module.  Basically it comes down to this:

; global module setting (unrelated to below box settings)
; If wanted, after all the other skinning and such is done, then one could
; check this setting and create a window region for what we typically call
; "true transparency".
ModuleUseRegionTransparency

; optional user defined. Translated into a RECT. Could be internal values only
; and not user defined, thus allowing for dynamic sizing of boxes.
; These are not part of the below box configuration specifically.
; but are used for the dimmensions to apply the boxskin to the module.
ModuleCaptionX 0
ModuleCaptionY 0
ModuleCaptionWidth 100
ModuleCaptionHeight 20

; The rest of the settings are specific skin box settings
; Typically the settings are prepended with something like "ModuleBox"
; or using the above size/pos names "ModuleCaptionBox"
; so in that case, "Transparent" would be "ModuleCaptionBoxTransparent"

; Transparent is strictly whether we BitBlt() or TransparentBitBltLS()
; to the destination DC and has nothing to do with regions.
Transparent

; these settings are valid only if the below "Skin" setting is defined
; the skin is stored in the skin.bmp size, and then applied to the
; requested Width/Height using the SkinMode bitblt method.
; I added the SkinBorderMode for performance reasons.
Skin skin.bmp
SkinMode "tile" or "stretch" or "tile-horizontal" or "tile-vertical"
SkinBorderMode "same as SkinMode"
SkinBorderLeft 6
SkinBorderTop 6
SkinBorderRight 6
SkinBorderBottom 6

; this block is valid if above "Skin" setting is NOT defined
; if "Image" is not defined, no image is used but the colors will be.
; The purpose of this is to allow for fixed sized implementations for performance
; and none bitmap boxes.
Image image.bmp
BackgroundColor 0x00FF00FF
BorderSize 1
BorderHighlightColor 0x00C0C0C0
BorderShadowColor 0x00000000

Ok, so those are the settings.  Of course it could be expanded or not.  Anyone who is familiar with Maduin's code knows, the Skin portion is basically a rip from that.

Anyway, so I have a couple of functions, one is BoxReadConfig() which fills a structure I created for the box configuration.  And a BoxCreate() function, which takes a pointer to the a HDC, a destination RECT used to paint into the HDC, a box config struct, and a boolean to override useage of transparency or not for the box.

I think the internals looks kind of like this (although it is from memory, not copy and paste)

class CSkinBox
{
public:
    CSkinBox(const char *pszSkin, UINT uLeft, UINT uTop, UINT uRight, UINT uBottom, INT nMode, INT nBorderMode);
    ~CSkinBox();

public:
    void ApplySkin(HDC hDC, RECT &r);

private:
    UINT m_uLeft, m_uTop, m_uRight, m_uBottom;
    INT m_nMode, m_nBorderMode;
    HBITMAP hSkinBmp;
};

typedef struct _DRAWBOX
{
    CSkinBox *pSkinBox;
    HBITMAP hImageBmp;
    UINT uBorderSize;
    COLORREF clrBackground, clrHighlight, clrShadow;
    //
} DRAWBOX, *PDRAWBOX;
typedef const _DRAWBOX *PCDRAWBOX;

With that, I can create any number of skinned boxes to work with.  So as an example, for any box I want, I load a config struct using BoxReadConfig(), I create a HDC and HBITMAP buffer of the final box size that I want skinned.  I select the bitmap into the hdc (obviously) pass it along with the RECT dimensions and box config into my BoxCreate() function.  When that returns I now have an HDC containing my Box.  I keep that around, and anytime I want to paint my box, I simply bitblt it into my screen DC at the location I want.

The whole point of creating this was for a new module I'm creating which has several "box" items in the display.  I use one Box for the background, and other boxes for some subelement backgrounds like a text (caption) boxes, an icon box etc.  So now, every element in the display is skinable.

Ok now that I've sort of explained it all.  Is it overkill?  Do people actually use that much custimization to warrant the overhead created by this (not a whole lot though).  I'm fairly pleased with the result myself, And it allows for quick reconstruction of the display when supporting "states" for the various display elements, as an example, a caption box to take a different look depending on the state of a window.

Has anyone else come up with useful display configuration routines for modules that are fairly generic and be made kind of 'standard'?   I'd like to try to keep module settings differences to a minimum, so if there are other good skinning implementations around, I'd like to check them out.

This turned into quite the long email, I should wrap it up. :)

So the point of it was, to just getting feed back on my methods, and if it is what is useful to users anymore.  I haven't been keeping up too well with what people are doing, and what hoops they are jumping through to get things to look like they want.  So anything to make custimization simpler but verstatile is what I'm trying to achieve.  :)

And yes, I'll share my code when I have a chance to transfer it from the computer I work on to a computer that has internet access.  Not too easy of a feat when traveling.

seeya
chris
 
 
______________________________________________________________
Sent via activatormail.com webmail system.
ActivatorMail(tm) ver.00608031 Scanned for all viruses by 
www.activatormail.com intelligent anti-virus anti-spam service



 
                   
--
ActivatorMail(tm) ver.00608031 Scanned for all viruses by 
www.activatormail.com intelligent anti-virus anti-spam service


__________________________________________________
Subscription options and archive:
http://www.freelists.org/list/shell-coding