Ekim wrote:

Hi Ekim:

I'm not sure why, or if, the child must be visible,
but anyway...

I'm assuming if the control is invisible, you also
want it disabled, so nobody clicks an invisible control
they didn't know was there. It might be that invisible
controls are disabled. I don't know. I'm not an expert.

I've created a pair of buttons that were invisible
and inactive. If I want the window to display these
I put the following two lines in the control's parent
window's WM_CREATE, or WM_INITDIALOG traps:

EnableWindow(control_handle, TRUE);
ShowWindow(control_handle, SW_SHOW);

These two statements set set a disabled and invisible
control to enabled and visible.

To go the other way, to set a visible enabled window
to disabled and invisible, try:

EnableWindow(control_handle, FALSE);
ShowWindow(control_handle, SW_HIDE);

Check these functions out on MSDN:

http://msdn.microsoft.com/

Larry

Ekim wrote:

Hi Again Ekim:

I think I might have misunderstood your original question.

My app displays text in a dialog box, which is gray in
Win2K, and beige, or something, when run under XP. So I
need to set the correct background text color.

To get the brush handle for a window, try this:

background_brush_handle =
(HBRUSH)SendMessage(GetParent(hwnd),
WM_CTLCOLORSTATIC,
(WPARAM)hdc,
(LPARAM)hwnd);

This will get a matching brush for the parent dialog.
You might have to change this to find the color of the
window you want to match.

The color can be extracted from the brush handle.

Larry

dear sirs,

I'm currently working on a project that consists partly of implementing a
deskband (that's so to say a toolbar within the taskbar, like the
standard-address-bar).

Inside this toolbar I have got a main-window, and within this main-window
exists an editbox (this is the child-window).
Now I faced the problem, that I want the main-window either to be
transparent/invisible, or it should have exactly the colors of the taskbar
(and that's difficult with windows-xp-themes - I'm simply not able to make
the mainwindow have the some color as let's say the default-blue-theme of
win-xp).
So either I'm looking for a method to get exactly the color of the taskbar
(and this should work on Win 2000, too), or, what is probably the better
solution, I want the main-window to be transparent and only the editbox be
visible (and of normal white windows color).

I thought of not using WS_VISIBLE for the mainwindow, but I guess this
doesn't work because the child must be visible, though.

I hope you got my message and be able to help me,

ekim!

"Larry Lindstrom" <nobody@aracnet.com> wrote in message
news:_6I%c.58549$3l3.19901@attbi_s03...
hy larry,
thx so far!

to clarify things and avoid having articulated complicated, I uploaded a
little picture:
http://members.mcnon.com/mikeatmcn/t...r_mistake2.JPG

in there you can see my toolbar containing the editbox.
I marked my main-window with a red rectangle, and in it is the editbox
placed as a child.
What you see is my desired behaviour, but unfortunately, this picture is not
the way my toolbar works now.
Instead, the main-window is white (or any other color, but not transparent
as it should be or at least the same color as the surrounding taskbar).
Therefore the editbox seems to be as tall as the height of the whole taskbar
(because the mainwindow AND the editbox have the same color), but instead my
editbox shall always be at a fixed size of 22 pix - and all the surrounding
area (especially the mainwindow) shall appear transparent!

I hope now I could describe my problem to you more detailed,
and hope you can give me now appropriate hints,
thx,
ekim!

Ekim wrote:

< Snip >

Hi Again Ekim:

Well, I'm just a beginner, but I thought I'd stumbled
over some things that might help. You would have done
better if I'd never posted, and let someone who knows
what their talking about help you out.

The fact that nobody has come to help on this thread
isn't a good sign.

When I'm out of ideas the last resort is to try to
make a small program that has the same problem.

This requires a lot of time, but I'm asking a lot of
the experts who post advice here.

If you can present a 100 or 200 like program that
exhibits the same problem, start a new thread and ask
for advice again, followed by the code from the program.
Perhaps one of those experts will take the time to look
at it.

Sometimes, when I do this, I find a mistake I've made
and don't have to post.

Good luck. I know how frustrating this can be.

Larry

On Wed, 08 Sep 2004 15:50:35 GMT, Larry Lindstrom <nobody@aracnet.com>
wrote:

clip


That's a reasonable assumption, but not correct. In fact, folks often
create an invisible button so it can intercept OK and Cancel (see
WM_COMMAND) messages so a dialog box doesn't close unexpectedly. This
note is way terser than I would like, but I don't think I can do
better for now. I know it has been discussed in other threads, so
google _will_ provide leads to better explanations, but I can't think
of a good search string.


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

On Wed, 8 Sep 2004 14:08:51 -0700, "Ekim" <the.newsletter@gmx.net>
wrote:

The following might help. The MatchBackground (see code below) is part
of a class I wrote. It sets a data member called m_hBrushBkg. The
setBackground function is another member of the class. It is called in
response to WM_ERASEBKGND messages. ASSERT_EXPLAIN and VERIFY_EXPLAIN
are my macros, modeled on similar MFC macros. ClsPFWindow is another
of my classes. I think the only relevant part of it is the GetHwnd
function, and its purpose should be clear. Everything else is straight
Win 32. These functions work for Windows CE and "big" Windows.

// ----------------------------------------------------------
// MatchBackground
// See 20-23 Mar 03 thread called "COLOR_WINDOW vs COLOR_WINDOW + 1"
in
// comp.os.ms-windows.programmer.win32
// According to article called Color in on-line help (Pocket
PC SDK ->
// Writing Applications for a Pocket PC -> Designing a User
Interface ->
// Functionality Guidelines -> Color), grey (no macro) is
used for dialog box
// backgrounds for Pocket PC, and COLOR_3DFACE is used for
dialog backrounds
// for Win 95.
void ClsPFControl::MatchBackground( const ClsPFWindow &wRef )
{
ASSERT( wRef.IsWindow() );
HWND hWnd = wRef.GetHwnd();
HDC hDc = ::GetDC( hWnd );
ASSERT( hDc != NULL );
#if 0
// Does not work
COLORREF cRef = ::GetBkColor( hDc );
ASSERT( cRef != 0 );
m_hBrushBkg = ::CreateSolidBrush( cRef );
ASSERT( m_hBrushBkg != NULL );
#else
WPARAM wP = reinterpret_cast<WPARAM>(hDc );
LPARAM lP = reinterpret_cast<LPARAM>(hWnd );
LRESULT lR = :efDlgProc( hWnd, WM_CTLCOLORDLG, wP, lP );

m_hBrushBkg = reinterpret_cast<HBRUSH>(lR);
#endif
VERIFY( ::ReleaseDC( hWnd, hDc ) );

} // MatchBackground

//
---------------------------------------------------------------------
// setBackground
static void setBackground( HDC hDc, HWND hWnd, HBRUSH hBrush )
{
#if 0
// This works
RECT rWork;
HBRUSH hBrushOld = reinterpret_cast<HBRUSH>(::SelectObject( hDc,
hBrush ));
ASSERT_EXPLAIN( hBrushOld != NULL );

VERIFY_EXPLAIN( ::GetClientRect( hWnd, &rWork ) );
VERIFY_EXPLAIN( ::Rectangle( hDc, rWork.left, rWork.top,
rWork.right, rWork.bottom ) );
ASSERT_EXPLAIN( hBrush == reinterpret_cast<HBRUSH>(::SelectObject(
hDc, hBrushOld )) );
#else
// But this seems neater
RECT rWork;
VERIFY_EXPLAIN( ::GetClientRect( hWnd, &rWork ) );
VERIFY_EXPLAIN( ::FillRect( hDc, &rWork, hBrush ) );
#endif
}


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com