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
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!
"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
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 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
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.
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...