Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to use GetConsoleWindow ??

501 views
Skip to first unread message

Emmanuel Soden

unread,
Sep 11, 2000, 11:54:19 AM9/11/00
to
Hi,
In the MSDN library of July 2000, a function named GetConsoleWindow ()
is described. But I'm unable to use it. I cant find information about
this function.

<----------- FROM MSDN ---------------->
GetConsoleWindow
The GetConsoleWindow function retrieves the window handle used by the
console associated with the calling process.

HWND GetConsoleWindow (VOID);
Parameters None.

Return Values
The return value is a handle to the window used by the console
associated with the calling process or NULL if there is no such
associated console.
/<----------- FROM MSDN ---------------->

If somebody can help me....

Regards,

--
Emmanuel Soden - e...@4js.com
Four J's Development Tools

As an old man said ...
If it happens once, it's a bug.
If it happens twice, it's a feature.
If it happens more than twice, it's a design philosophy.....


Joe Delekto

unread,
Sep 11, 2000, 7:18:32 PM9/11/00
to

Greets,

Guess what, I can't find this function either, even in the latest
Platform SDK! Interestingly enough as well, the MSDN documentation that I
have doesn't even list a header or a .LIB in which this function can be
found.

If you really need to get an HWND to a console, there is an interesting
trick that you can try. You can use SetConsoleTitle() to modify the title
of the window for the console, then call FindWindow() with the (hopefully
unique) window name they have chosen and set the title back once again.

Regards,

Joe

"Emmanuel Soden" <e...@4js.com> wrote in message
news:39BD002B...@4js.com...

Vincent Fatica

unread,
Sep 11, 2000, 7:57:58 PM9/11/00
to
Hmmm! It's in my KERNEL32.LIB (the VC6SP3 one) but not in any header files.
It does seem unusable. I have a fairly recent PSDK; it's not to be found
there.

- Vince

On Mon, 11 Sep 2000 19:18:32 -0400, "Joe Delekto" <jdel...@netvillage.com>
wrote:

Vincent Fatica
vefa...@syr.edu
Syracuse University Mathematics
http://barnyard.syr.edu/~vefatica/

Quixote

unread,
Sep 11, 2000, 9:51:45 PM9/11/00
to

"Joe Delekto" <jdel...@netvillage.com> wrote in message
news:u1SvGaEHAHA.286@cppssbbsa04...

>
> Greets,
>
> Guess what, I can't find this function either, even in the latest
> Platform SDK! Interestingly enough as well, the MSDN documentation that I
> have doesn't even list a header or a .LIB in which this function can be
> found.
>
> If you really need to get an HWND to a console, there is an
interesting
> trick that you can try. You can use SetConsoleTitle() to modify the title
> of the window for the console, then call FindWindow() with the (hopefully
> unique) window name they have chosen and set the title back once again.
>
> Regards,
>

This can be tricky. Under NT 4 it seems to work without a problem but under
Win98 there is a lag before SetConsoleTitle() takes effect and the two
commands do not seem to be appropriately queued, with the consequence that
FindWindow() can be completed before the console title is actually changed.
I use the following code:

HWND FindConsoleWindow(void)
{
HWND hwnd;
char setTitle[101];
char getTitle[101];
int i=0;

sprintf(setTitle, "Console_!*!_TempTitle%ul", GetTickCount());

SetConsoleTitle(setTitle);

do
{
Sleep(10);
hwnd = FindWindow(NULL, setTitle);
GetWindowText(hwnd, getTitle, 100);
}
while(strcmp(setTitle, getTitle)!=0 && ++i < 100);

if(i==100)
hwnd = NULL;

return hwnd;
}

Owing to the Sleep(10) command, a single iteration is usually sufficient.


--

Quixote
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)


Joe Delekto

unread,
Sep 11, 2000, 11:35:57 PM9/11/00
to

Greets,

If it's in the .LIB, then only one needs to do is provide a declaration
for such in their app as it appears in the documentation. It should be
linked properly. I've not tested such, but I would certainly like to see a
success story. (Why did you not follow through out of curiousity?)

Regards,

Joe

"Vincent Fatica" <vefa...@syr.edu> wrote in message
news:39bd7201$1...@drh2-458.twcny.rr.com...

Joe Delekto

unread,
Sep 11, 2000, 11:38:27 PM9/11/00
to

Greets,

Well, I can certainly state I know nothing about threading under Win98.
However, why is Sleep(10) sufficient? Do you think perhaps Sleep(0) would
work instead? Perhaps is has less to do with the message queue and the
thread that services the dispatching. Can you tell me what Sleep(0) does?
:)

Regards,

Joe

"Quixote" <donald...@bigpond.com> wrote in message
news:jRfv5.49101$c5.1...@newsfeeds.bigpond.com...

Quixote

unread,
Sep 12, 2000, 4:01:52 PM9/12/00
to

"Joe Delekto" <jdel...@netvillage.com> wrote in message
news:ewf3WrG...@cppssbbsa02.microsoft.com...

>
> Greets,
>
> Well, I can certainly state I know nothing about threading under
Win98.
> However, why is Sleep(10) sufficient? Do you think perhaps Sleep(0) would
> work instead? Perhaps is has less to do with the message queue and the
> thread that services the dispatching. Can you tell me what Sleep(0) does?
> :)
>
> Regards,
>
> Joe

I use Sleep(10) simply because it works on my computer. There is a MSDN
Knowledge Base article on this (number Q124103) called "Obtaining a Console
Window Handle (HWND)". The sample code in that article uses Sleep(40).
However, that code only tries to retrieve the handle once, whereas mine
tries up to 100 times. This means that the cumulative Sleep period resulting
from my code can be anywhere from 10 to 1000 milliseconds. Moreover, if the
system is busy, then this will tend to slow down the processing of the
iterations in line with the rest of the system. Of course, you can increase
the maximum number of iterations to any number you want. If you think that
it is reasonable for your application to try to get a handle for up to 5
minutes, then you can set the maximum number of iterations accordingly.

As for what Sleep(0) does, the MSDN documentation says: "A value of zero
causes the thread to relinquish the remainder of its time slice to any other
thread of equal priority that is ready to run. If there are no other threads
of equal priority ready to run, the function returns immediately, and the
thread continues execution." Note the reference to threads of "equal
priority". Sleep(0) will not suspend a thread if only lower priority threads
are ready to run. On the other hand, regardless of whether or not Sleep is
called, the thread will automatically be suspended if there is a higher
priority thread that is ready to run.

The potential hazards of Sleep(0) would therefore seem to be:

(a) that the function may return too quickly for the window handle to be
retrieved successfully (in the case where there are no other threads of
equal priority ready to run),
(b) that the function may return too slowly to satisfy users (in the case of
other threads of equal priority being ready to run and taking a long time
doing it).

Whether either of these hazards will cause a problem depends on the priority
of your thread and on what else is happening on your system. I ran a couple
of quick tests on my computer under Windows 98 with no other significant
programs running. Specifically, I tried each of the Sleep(0) and Sleep(10)
options about 20 times, using a maximum of 100 iterations each time. The
Sleep(0) option failed twice, i.e., it failed on all 100 iterations on two
occasions. The Sleep(10) option never failed overall. Its worst performance
was to fail on the first iteration and succeed on the second. It thus seems
that "potential hazard" (a) is quite real.

Regards

Joe Delekto

unread,
Sep 12, 2000, 4:34:26 PM9/12/00
to

Greets,

Ah, thank you much for the detailed explanation, references and
extensive experimentation. Sorry to have asked a slew of questions, but I
was certainly curious as to why Win98 would require such a delay. I was
fairly certain that Sleep(0) would have caused the thread to give up its
remaining scheduled time, however, I am trying to avoid making assumptions
about the task scheduler on Win98. I don't have a Win98 machine to play
with either. :(

It would seem that the API call to change the console title must go
through the motions of sending a message (I am guessing a PostMessage() with
WM_SETTEXT) and that its asynchronous operation is what is causing the need
for the Sleep(). What are your thoughts?

Actually, if you are willing, would you be so kind as to test the
GetConsoleWindow() approach? In reference to the original poster's
question, I found that the latest Platform SDK does not have
GetConsoleWindow() available in the KERNEL32.LIB, however, it is still in
the KERNEL32.DLL I have on Windows 2000. (I'd like to know if Win98 has it
as well). The export is in the original LIBs that shipped with VC++ 6.0, so
I'm questioning as to if it had become deprecated.

I've used the following code snippet to get the export from
KERNEL32.DLL, I would be interested in seeing if this works as expected on
Windows 98. I tried it on Windows 2000 and was able to get the same HWND
that the SetConsoleTitle()/FindWindow() approach had given.

-----------
typedef HWND (WINAPI * GETCONSOLEWINDOW)(void);

HMODULE hMod=::LoadLibrary("kernel32.dll");
GETCONSOLEWINDOW
GetConsoleWindow=reinterpret_cast<GETCONSOLEWINDOW>(::GetProcAddress(hMod,"G
etConsoleWindow"));

-----------

Regards,

Joe

"Quixote" <donald...@bigpond.com> wrote in message

news:_Svv5.49584$c5.1...@newsfeeds.bigpond.com...

Quixote

unread,
Sep 13, 2000, 10:30:46 AM9/13/00
to

"Joe Delekto" <jdel...@netvillage.com> wrote in message
news:OtrRkmPHAHA.65@cppssbbsa04...

>
> Greets,
>
> Ah, thank you much for the detailed explanation, references and
> extensive experimentation. Sorry to have asked a slew of questions, but I
> was certainly curious as to why Win98 would require such a delay. I was
> fairly certain that Sleep(0) would have caused the thread to give up its
> remaining scheduled time, however, I am trying to avoid making assumptions
> about the task scheduler on Win98. I don't have a Win98 machine to play
> with either. :(
>
> It would seem that the API call to change the console title must go
> through the motions of sending a message (I am guessing a PostMessage()
with
> WM_SETTEXT) and that its asynchronous operation is what is causing the
need
> for the Sleep(). What are your thoughts?

The console implementation under Window 98 is apparently completely
different from that under NT, being MSDOS based. I have no idea how it works
(but don't think it works very well). Incidentally, I am not confident that
there are no similar problems under Windows NT. It may just be that NT is
faster, so I haven't noticed the problem.

>
> Actually, if you are willing, would you be so kind as to test the
> GetConsoleWindow() approach? In reference to the original poster's
> question, I found that the latest Platform SDK does not have
> GetConsoleWindow() available in the KERNEL32.LIB, however, it is still in
> the KERNEL32.DLL I have on Windows 2000. (I'd like to know if Win98 has
it
> as well). The export is in the original LIBs that shipped with VC++ 6.0,
so
> I'm questioning as to if it had become deprecated.
>
> I've used the following code snippet to get the export from
> KERNEL32.DLL, I would be interested in seeing if this works as expected on
> Windows 98. I tried it on Windows 2000 and was able to get the same HWND
> that the SetConsoleTitle()/FindWindow() approach had given.
>
> -----------
> typedef HWND (WINAPI * GETCONSOLEWINDOW)(void);
>
> HMODULE hMod=::LoadLibrary("kernel32.dll");
> GETCONSOLEWINDOW
>
GetConsoleWindow=reinterpret_cast<GETCONSOLEWINDOW>(::GetProcAddress(hMod,"G
> etConsoleWindow"));
>
> -----------
>
> Regards,
>
> Joe
>

I tried this under Windows 98. No success, alas. It seems that the function
is only available under Windows 2000.

0 new messages