Hi all,

Is there anyone who is having problems calling the DestroyWindow API
command?  For some reason when I call it, it has absolutely no effect.
Other API calls work fine ... for example if I call CloseWindow, the window
will minimize.  It's just the DestroyWindow that has absolutely no effect.

Anyone have any ideas on this?

Charles

Michael

I'm trying to destroy a Help Window called from my program using the API's
WinHelp call.  I use FindWindow call to determine the hWnd handle, then pass
that handle to the DestroyWindow call.  As I said before, the handle is
correct, because CloseWindow is working properly (minimizing properly) --
it's just DestroyWindow that has no effects ... !

Charles

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please post/reply to the newsgroup(s) so
that everyone can benefit from the discussion.

Regards,

Klaus H. Probst, MCP


       ICQ: 22454937
      The VB Box: http://www.*-*-*.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

FWIW, I agree with Klaus's post that a WM_CLOSE would be more elegant than
DestroyWindow.  Actually, I think if you want to be really safe, you might
want to consider calling WinHelp with HELP_QUIT, since according to MSDN, it
"Informs Windows Help that it is no longer needed. If no other applications
have asked for Help, Windows closes Windows Help."

HTH
--
Dev Ashish (Just my $.001)
---------------
The Access Web ( http://home.att.net/~dashish )
---------------

:
: I'm trying to destroy a Help Window called from my program using the API's
: WinHelp call.  I use FindWindow call to determine the hWnd handle, then
pass
: that handle to the DestroyWindow call.  As I said before, the handle is
: correct, because CloseWindow is working properly (minimizing properly) --
: it's just DestroyWindow that has no effects ... !
:
: Charles
:
:
: >What window are you trying to destroy? That is likely where you problem
is.
:
:
:

DestroyWindow() API can destroy only windows created by the same thread that is
calling it. The Help window has its own thread and process.
In general, its a bad idea to use DestroyWindow() when you want to close an
application. Instead send it a WM_CLOSE message as was suggested. This will
allow for graceful closing without possible losing of data.

Regards,
                Stoil

Thanks to all for your helpful comments!  I've tried the suggested, but the
behavior is not exactly what I need ....

I've tried calling SendMessage WM_CLOSE, as well as WinHelp HELP_QUIT, and
both of them successfully close the window (thanks for your help).  However,
the problem is right after I'm closing the Help window, my code requires
that I open up another Help window immediately again afterward -- same .HLP
file, but different style of window.  So, my pseudo-code might look like
this:

SendMessage WM_CLOSE        ' close the already open help window
                                                          ' can use WinHelp
HELP_QUIT; results identical
WinHelp HELP_TOPIC                 ' open the help window, with a particular
topic file

(In case you're wondering, the reason I need to close the help window and
open it again is because I need to open it up in a different "style" ...
WinHelp and .HLP allow defining different "styles" of help windows, such as
background color, text color, etc.  So what I'm doing is closing one help
window, which was in one particular style, and opening up another one, in
another style.)

At any rate, the problem now seems to be one of synchronization(?), or order
of commands ... what's happening is that sometimes when I run the code,
WinHelp HELP_TOPIC seems to finish executing before SendMessage or WinHelp
HELP_QUIT.  So what happens is that WinHelp will display the new topic file
and THEN the help window closes!  So what ends up happening is that after I
run this code, NO help window is open at all.  I'm not even sure that my
analysis of the problem is correct, but I do know that sometimes (it is
inconsistent, but it is reproducible) after running the code, help windows
are all closed, whereas you would expect that one should be open.

If I insert a little pause, like 0.5 seconds, between the SendMessage
WM_CLOSE command, and the new WinHelp HELP_TOPIC command, then the problem
is fixed!  However, I'm reluctant to use an absolute number for pause,
because this number can vary on different machine speeds, and also, because
for machines that are fast enough, it represents an unnecessary wait time
for the user.

Any other ideas?

Charles

SendMessage(), actually, does not return until the message is removed from the
message queue of the receiving application.
To make sure the program has been terminated you might want to try the
following:

1. Find the Process Id of the program by a call to GetWindowThreadProcessId()
API. You pass it the hWnd of the Help window.

Declare Function GetWindowThreadProcessId Lib "user32" Alias
"GetWindowThreadProcessId" (ByVal hWnd As Long, lpdwProcessId As Long) As Long

2. Get a handle of the process by a call to OpenProcess() API. You pass it the
Process ID from 1. as the third parameter.

Declare Function OpenProcess Lib "kernel32" Alias "OpenProcess" (ByVal
dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As
Long) As Long

3. You close the program by sending it a  WM_CLOSE message

4. Then you can use the handle from 2. in a call to GetExitCodeProcess() API
which if the process is still running will return value of STILL_ACTIVE.

'API constants used
        Const PROCESS_QUERY_INFORMATION = &H400
        Const STILL_ACTIVE = &H103

        'API functions declarations
        Declare Function GetExitCodeProcess Lib "kernel32" Alias
"GetExitCodeProcess" (ByVal hProcess As Long, lpExitCode As Long) As
Long

    Here is the waiting loop:

    GetExitCodeProcess hProcess, lResult

        'Loop until process is terminated
        While lResult=STILL_ACTIVE
                GetExitCodeProcess hProcess, lResult
                DoEvents
        Wend

    'Program has finished

Regards,
               Stoil

So,