[shell-coding] Module skinning

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

Other related posts: