Popup menu closed using DestroyWindow sometimes doesn't repaint correctly
José Sebastián Battig
swtiched from the keybd_event (ESC...) to close them, to DestroyWindow. I
did this before strangely keybd_event was causing a conflict with windows
explorer... wierd... very wierd.
To use this approach first I get the handle of the popup menu using
WindowFromPoint, and check against GetClassName + FindAtom + GetAtomName to
see if the class if really the TPopupMenu class. I found with ws32 that the
classname for PopupMenus is #32768, and that actually is an ATOM created
using the macro MAKEINTATOM, so, I assume it's safe to compare the atom name
against #32768 to ensure I'm destroyin the popup menu.
Ok, now to my problem.
This approach is working fine, is closing the popups exactly as I want, but
my problem now is that in some cases where the popups are destroyed and
another popup is shown very quickly, the portion of the screen that belonged
to the destroyed popup remaing painted with the popup image. This results in
popups that seams to be there, but it's only their image...
I tried extending my code as this:
ShowWindow (FPopupWindowHandle, SW_HIDE);
UpdateWindow (FPopupWindowHandle);
DestroyWindow (FPopupWindowHandle);
Hiding the window before destroying it, the then updating, but doesnt works,
the anoying behavior is still there. I have to clarify that this occurs ONLY
when doing the destroy-show new popup process too quickly, but actually this
can happen oftenly in the component I'm developing.
Now, my question is how to ensure that a window correctly clears i't's draw
area before being destroyed? What do you suggest in my case?
Thanks in advance.
Sebastian
Peter Below (TeamB)
> Hi. I'm my crazy race finding a way to take control over popup menus now I
> swtiched from the keybd_event (ESC...) to close them, to DestroyWindow.
YE GODS! At least have the decency to send a WM_CLOSE message to the window to get
it to close instead of rudely cutting it off at the root. If sending an ESC does not
work (it should if the app showing the menu is active) then use SetCursorPos to
position the mouse outside the menu and fake a mouse click there with:
mouse_event( MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0 );
mouse_event( MOUSEEVENTF_LEFTUP, 0, 0, 0, 0 );
Oh, both keybd_event and mouse_event put messages in the message queue, so you need
to follow them with an Application.ProcessMessages, if the messages are going to
your own app, or get a little rest via Sleep if they are going to another app.
Otherwise the messages will not get processed before you continue with your
mischievous manipulations.
Peter Below (TeamB) 10011...@compuserve.com)
No replies in private e-mail, please, unless explicitly requested!
Jim Kueneman
"Peter Below (TeamB)" wrote:
> In article <39df44ab_2@dnews>, José Sebastián Battig wrote:
> > Hi. I'm my crazy race finding a way to take control over popup menus now I
> > swtiched from the keybd_event (ESC...) to close them, to DestroyWindow.
>
> YE GODS! At least have the decency to send a WM_CLOSE message to the window to get
> it to close instead of rudely cutting it off at the root. If sending an ESC does not
DestroyWiindow sends a WM_CLOSE and WM_NCCLOSE messages to the window as part of its
actions. Why is your way better? I have always thought DestroyWindow is the correct
way to, well, destroy a window <g>.
Jim
José Sebastián Battig
news:39E090A6...@azstarnet00.com...
Thanks both you guys for your tips. Actually, the problem with my
"mischievous manipulations" is the strange side effect when performing this
to quickly. Actually, DestroyWindow closes the window, and if you do it
slow, works fine. I was thinking that probably when I do it to fast, I don't
give time to the window to get correctly painted and they I destroy it.
Probably if I hook CallWndProc and check for the last event a window
received to be sure that it's correctly on screen, and then I continue
processing could be a way to ensure that I destroy it after it's correctly
on screen. Wich is the last event a window receive in it's initialization
process? WM_PAINT?.
TIA
Sebastian
Jim Kueneman
Jim Kueneman wrote:
> DestroyWiindow sends a WM_CLOSE and WM_NCCLOSE messages to the window as part of its
> actions. Why is your way better? I have always thought DestroyWindow is the correct
> way to, well, destroy a window <g>.
Ok, it has been too long since programming the "hard" way. DestroyWindow sends a
WM_DESTROY and WM_NCDESTROY. Sending a WM_CLOSE is the right way to do it. I need to
engage brain before mouth :^)
Jim
Peter Below (TeamB)
> DestroyWiindow sends a WM_CLOSE and WM_NCCLOSE messages to the window as part of its
> actions.
It does not, it sends WM_DESTROY and WM_NCDESTROY. Most window functions do cleanup
operations in response to WM_CLOSE, not WM_DESTROY. In fact API-level programs usually
*call* DestroyWindow in response to WM_CLOSE.
José Sebastián Battig
by they way, I tried the keybd_event (VKey, ScanCode, Flags, 0); with
Application.ProcessMessages approach, and it doesn't works. Actually,
without the Application.ProcessMessages the menus are closed, but as I told
you before, that interference with explorer... Now, the wierd thing is that
a call to application.processmessages after the keybd_event prevents the
menu from being closed.
Sebastian
"Peter Below (TeamB)" <10011...@compuXXserve.com> escribió en el mensaje
news:VA.00005f1...@antispam.compuserve.com...