Window that contains a menu
Harland
drawn?
I'd like to draw in the non-client area of the menu. Any pointers?
TIA
William DePalo [MVP]
news:GLCt6.12213$Im6.1...@newsread1.prod.itd.earthlink.net...
> Does anyone know how to get the handle to a menu BEFORE it is actually
> drawn?
Do you know about owner-drawn menus? With an owner-drawn menu you'll be
given a device context in which to do your drawing. Once upon a time it was
possible to call WindowFromDC() to turn a device context into a window.
Since 98 however, with "animated" menus it is not so simple. That's because
you may be given a memory device context which Windows uses until the menu
is fully visible.
Regards,
Will
Harland
Yes, I'm drawing the menu. All is cool except the non-client area. I've
tried selecting a null region with mixed results depending upon the
platform. WindowFromDC returns null, also depending upon the platform.
WM_ENTERIDLE seems to give me the handle to the window that bounds the menu,
but only after it is drawn. I figured if I could grab the window that
contains the menu I could trap WM_NC* to shape & draw the NC area.
I figure if Bookshelf, Office/Win2000, et al., can do it, we should be able
to do it. With a little help, of course.
Many thanks in advance...
Harland
"William DePalo [MVP]" <depalow...@compuserve.com> wrote in message
news:eV42WNjsAHA.1408@tkmsftngp05...
William DePalo [MVP]
> Yes, I'm drawing the menu. All is cool except the non-client area. I've
> tried selecting a null region with mixed results depending upon the
> platform. WindowFromDC returns null, also depending upon the platform.
So I guess we have two problems here:
1) determining the window handle
2) being able to draw in the non-client area
#2 is the easier to deal with. If you have a window handle then
GetWindowDC() will get you a device context that permits drawing in the
non-client area. I haven't tried drawing the nonclient area of a window but
if a menu is a window and if a window is a window then all we need to do is
get the window handle.
In an app of mine that has an owner-drawn I found that WindowFromDC() will
get me a window handle on 95 and NT4. If I remember correctly, this would
work on 98 if I turned off menu animation. There the DC you get is a memory
DC until the menu has slid into its final position. It would be nice if
there were some way to turn off menu animation on a menu or an application
basis. If such a way exists, I couldn't find it when I searched.
I deal with that problem by enumerating all the windows of my UI thread, and
searching for the one whose class name is "#32768" and whose size is almost
they way I sized it while processing the WM_MEASUREITEM message. <g> I say
almost because I think that one of us (Windows or I) is off by one pixel in
width.
Regards,
Will
lie...@us.ibm.com
David
Paul Baker
Paul :)
<lie...@us.ibm.com> wrote in message news:uvPzZNysAHA.488@tkmsftngp05...
William DePalo [MVP]
Of course. What we are discussing is retrieving the handle to the window
that displays a menu.
Regards,
Will
Harland
I spy'd on the UI thread and the results were like so:
WM_INIITPOPUP [parent]
WM_NCCREATE [child]
WM_NCCALCRECT [child]
WM_CREATE [child]
WM_MEASUREITEM's [parent]
WM_PRINT [child]
WM_ERASEBACKGROUND [child]
WM_DRAWITEM's [parent]
WM_WINDOWPOSCHANGED [child]
WM_MOVE [child]
WM_ENTERIDLE [parent]
....
Unfortunately, no WM_PARENTNOTIFY (and parent doesn't have
WS_EX_NOPARENTNOTIFY ex style). : (
I figured it would be easier to SPI_SETMENUANIMATION to false in
WM_ENTERMENULOOP and restore it in WM_EXITMENULOOP. This way WindowFromDC
might work. Problem is, I'll be damned if I can get it to "stick".
SystemParametersInfo returns success on the SPI_SET*, but a call to SPI_GET*
immediately following still returns true.
I'm developing on Win2K Server & Win2KPro. Any other ideas?
Thanks,
Harland
"William DePalo [MVP]" <depalow...@compuserve.com> wrote in message
news:#iG02hvsAHA.684@tkmsftngp04...
lie...@us.ibm.com
There were comments from others about WindowFromDC and WM_NC messages.
These comments seemed to imply that one might be able to intercept these
message in order to draw parts of the menu.
My point was that since menus are not windows, these approaches might not
make sense.
Am I missing something? Are WM_NC messages sent to menus?
David Liebtag
IBM APL Products and Services
Paul Baker
Yes, one of us is totally missing the point.
I thought the point was that you want an owner-drawn menu (and obviously you
want it to work in all cases, even animated menus).
This is all documented at
http://msdn.microsoft.com/library/psdk/winui/menus_9dwl.htm.
The WM_DRAWITEM message contains a DC in it that you can use that will work
in all cases. WM_NCPAINT and GetWindowFromDC are not irrelevant.
<lie...@us.ibm.com> wrote in message news:eTSHJk8sAHA.320@tkmsftngp05...
William DePalo [MVP]
> My point was that since menus are not windows, these approaches might not
> make sense.
Menus are windows. They belong to the window class whose name is "#32768".
That is not to say that menu handles and window handles are the same thing.
> Am I missing something?
Yes.
>Are WM_NC messages sent to menus?
Yes. Launch SPY++. Select non-client messages for observation. Spy on _all_
the windows in the system. Move the mouse over a menu. Watch spy report on
non-client messages.
Regards,
Will
William DePalo [MVP]
> I figured it would be easier to SPI_SETMENUANIMATION to false in
> WM_ENTERMENULOOP and restore it in WM_EXITMENULOOP. This way WindowFromDC
> might work. Problem is, I'll be damned if I can get it to "stick".
> SystemParametersInfo returns success on the SPI_SET*, but a call to
SPI_GET*
> immediately following still returns true.
There is always brute force - seraching for the window by class name and
size. :-)
Failing that, maybe you could hack something up with TrackPopupMenu(). It
takes a parameter which, the docs say, may be used to turn off animation.
Regards,
Will