BS_OWNERDRAW / button problem...

[.rhavin grobert]

the following codefragment fills a Static Window with a Buttonbar and
runs fine.
My problem is that when i change the Buttons to Ownerdraw-style-buttons
(e.g. adding BS_OWNERDRAW to styles), they simply vanish. Digging into
this, i noticed that the DrawItem()-func of my ownerdrawbuttons is not
executed... what could cause this problem?

i dont think that the problem is in my ownerdraw-buttons, because they
run well in other places - so i dont post their code here directly ...
if you think the problem is in them, you can find their code here:
http://q-pool.de/t5xv/GlassButton.cpp
http://q-pool.de/t5xv/GlassButton.h

__________________________
// header:

#define AUXBTN_X 80
#define AUXBTN_Y 20
#define AUXBTN_MAX 50

class MyClass {
/.../
void SetActionBar(HWND hActionBar);
CButton BtnAux[AUXBTN_MAX];
/.../
}

__________________________
// implementation:

void MyClass::SetActionBar(HWND hActionBar) {
m_hActionBar = hActionBar;
RECT rc;
HWND hParent = GetParent(m_hActionBar);
GetWindowRect(m_hActionBar,&rc);

UINT xDim = rc.right - rc.left;
UINT yDim = rc.bottom - rc.top;
UINT xCnt = xDim / AUXBTN_X;
UINT yCnt = yDim / AUXBTN_Y;
UINT xBtn = (xDim / xCnt) - 2;
UINT yBtn = (yDim / yCnt) - 2;

ScreenToClient(hParent,(POINT *) &rc);

short Cnt =0;
UINT xPos, yPos;
short x, y;
for (y = 0; (y < yCnt) && (Cnt < AUXBTN_MAX); y++) {
for (x = 0; (x < xCnt) && (Cnt < AUXBTN_MAX); x++) {
xPos = rc.left + ((xDim * x ) / xCnt);
yPos = rc.top + ((yDim * y ) / yCnt);
BtnAux[Cnt++].CreateEx(NULL, _T("BUTTON"), _T("*"),
WS_CHILD | WS_VISIBLE | WS_TABSTOP,
xPos, yPos , xBtn, yBtn, hParent, 0, 0 );
}
}
}

[.rhavin grobert]

i should also add that i tried something like

std::vector<CGlassButton *>

and filling it in the ctor with button-pointers, but the result is the
same, that is:
using a CButton and no BS_OWNERDRAW -> runs fine
using a CGlassButton and BS_OWNERDRAW -> there is no button
as i mentioned, my CGlassButton-Class runs fine in other places ?!
please help :-\

[Scott McPhillips [MVP]]

.rhavin grobert wrote:
> the following codefragment fills a Static Window with a Buttonbar and
> runs fine.
> My problem is that when i change the Buttons to Ownerdraw-style-buttons
> (e.g. adding BS_OWNERDRAW to styles), they simply vanish. Digging into
> this, i noticed that the DrawItem()-func of my ownerdrawbuttons is not
> executed... what could cause this problem?
>
> i dont think that the problem is in my ownerdraw-buttons, because they
> run well in other places - so i dont post their code here directly ...
> if you think the problem is in them, you can find their code here:
> http://q-pool.de/t5xv/GlassButton.cpp
> http://q-pool.de/t5xv/GlassButton.h
>
> __________________________
> // header:
>
> #define AUXBTN_X 80
> #define AUXBTN_Y 20
> #define AUXBTN_MAX 50
>
> class MyClass {
> /.../
> void SetActionBar(HWND hActionBar);
> CButton BtnAux[AUXBTN_MAX];
> /.../
> }

What you've done here is to create a CButton, but CButton does not
handle DrawItem. You have to change the above declaration from CButton
to your button class, which presumably overrides DrawItem.

--
Scott McPhillips [VC++ MVP]

[.rhavin grobert]

> What you've done here is to create a CButton, but CButton does not
> handle DrawItem. You have to change the above declaration from CButton
> to your button class, which presumably overrides DrawItem.

As i told, it runs with CButton but not with CGlassButton .. of course
i did change it in the header, too, but i didnt want to post booth
versions.

[Jeff Partch]

".rhavin grobert" <cl...@yahoo.de> wrote in message
news:1158457309.3...@i3g2000cwc.googlegroups.com...

In addition to what Scott said, I think your problem might be here...

int CGlassButton::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
lpCreateStruct->dwExStyle |= BS_OWNERDRAW;

...BS_OWNERDRAW is a style not an extended style.

--
Jeff Partch [VC++ MVP]

[.rhavin grobert]

Jeff Partch wrote:
> In addition to what Scott said, I think your problem might be here...
>
> int CGlassButton::OnCreate(LPCREATESTRUCT lpCreateStruct) {
> lpCreateStruct->dwExStyle |= BS_OWNERDRAW;
>
> ...BS_OWNERDRAW is a style not an extended style.

Ok, i changed that, but it didnt solve my problem....
strangely, a

lpCreateStruct->style |= BS_OWNERDRAW;

seems to have no effect at all, and a

m_BtnAux[Cnt++]->CreateEx(NULL, _T("BUTTON"), _T("*"),
BS_OWNERDRAW | WS_CHILD | WS_VISIBLE | WS_TABSTOP,

xPos, yPos , xBtn, yBtn, hParent, 0, 0 );

let my buttons vanish. I put a MessageBox in CGlassButton::OnCreate()
and in CGlassButton::DrawItem(), just to see that DrawItem is not
called. But as i mentioned, the source in GlassButton runs fine in
other places:-\

[Scott McPhillips [MVP]]

.rhavin grobert wrote:
> Ok, i changed that, but it didnt solve my problem....
> strangely, a
>
> lpCreateStruct->style |= BS_OWNERDRAW;
>
> seems to have no effect at all, and a
>
> m_BtnAux[Cnt++]->CreateEx(NULL, _T("BUTTON"), _T("*"),
> BS_OWNERDRAW | WS_CHILD | WS_VISIBLE | WS_TABSTOP,
> xPos, yPos , xBtn, yBtn, hParent, 0, 0 );
>
> let my buttons vanish. I put a MessageBox in CGlassButton::OnCreate()
> and in CGlassButton::DrawItem(), just to see that DrawItem is not
> called. But as i mentioned, the source in GlassButton runs fine in
> other places:-\
>

Is there anything unusual about the button's parent window? Draw item
is called by MFC code in the parent window, so it's not going to work if
you're working with some non-MFC dialog or out-of-process dialog etc.

[.rhavin grobert]

Scott McPhillips [MVP] wrote:
> Is there anything unusual about the button's parent window? Draw item
> is called by MFC code in the parent window, so it's not going to work if
> you're working with some non-MFC dialog or out-of-process dialog etc.

the parent is a PropertyPage derived class with a member-variable
(pointer) to an object commonly used by all my dialogs. SetActionBar()
is one of its methods.
without ownerdraw-style, the buttons will be drawn. So it seems that
some drawing routine has to be called. do i have the chance to subclass
that drawing routine with my own somehow? at least, it is still a
CGlassButton and not a CButton, even if its derived from it, so there
should be a possibility...?

[Vipin]

OnCreate is a bit late in the game to modify the style. The style should be
modified in PreSubClassWindow using ModifyStyle(...)

--
Vipin Aravind
http://www.explorewindows.com/Blogs
http://www.explorewindows.com

"Jeff Partch" <je...@mvps.org> wrote in message
news:%23DyQZyf...@TK2MSFTNGP06.phx.gbl...

[.rhavin grobert]

Scott McPhillips [MVP] schrieb:

> Draw item is called by MFC code in the parent window, so it's not
> going to work if you're working with some non-MFC dialog or
> out-of-process dialog etc.

if i do it without BS_OWNERDRAW, the button is drawn like a
common-control-button and still is a button of my class. so i only need
to tell the system: dont call the standard-drawing, instead of it call
mine, but how can i do it? what is called instead of DrawItem() for
standart-buttons? whatever it is, it seems to not care if my dialog is
out-of-process or non-mfc and i want to have the same functionality.

so what can i do?

[Scott McPhillips [MVP]]

.rhavin grobert wrote:
> if i do it without BS_OWNERDRAW, the button is drawn like a
> common-control-button and still is a button of my class. so i only need
> to tell the system: dont call the standard-drawing, instead of it call
> mine, but how can i do it? what is called instead of DrawItem() for
> standart-buttons? whatever it is, it seems to not care if my dialog is
> out-of-process or non-mfc and i want to have the same functionality.
>
> so what can i do?

From MSDN BS_OWNERDRAW: "The owner window receives a WM_DRAWITEM
message when a visual aspect of the button has changed. Do not combine
the BS_OWNERDRAW style with any other button styles."

First, make sure you are obeying that restriction. Then see if the
WM_DRAWITEM message is being received by the parent. (You can use Spy++
or find an appropriate breakpoint in the MFC source code.) You can also
use Spy++ to check the actual styles of your button.

I don't know what's wrong, but there are lots of ways you can
investigate to get more clues.