Instance Handle in Console Application

[garyscott]

Hi, I'm trying to get an instance handle for a console application. Can I use getmodulefilename and getmodulehandle? Is that handle the same thing as the "instance" handle? I've found conflicting data on whether it is or isn't. CreateWindow seems to like it, but I want to be sure what handle I have.

[garyscott]

Apparently getmodulehandle(null) works. Why does when you query MSDN with this question, they describe about 6 different ways to get the instance handle (all requiring an existing handle to something else that hasn't been created yet or a winmain), and this isn't one of them??? And why does it not make it clear somewhere that hmodule and hinstance are the same thing (at least usually)?(rhetorical) Sheesh.

[g_f_thomas]

Get the console's title via GetConsoleTitle and pass it to FindWindow to find the HWND.

HTH,
Gerry T.

[garyscott]

Thanks, that is helpful too. You'd think I'dremember this stuff, but I've been using GINO for so long, I haven't needed it in about 6 years.

[Steven_L_Intel1]

Would GetForegroundWindow be of any use here?

[g_f_thomas]

I forgot to mention that the hwnd of the console is what you pass to SetCtrlHandler to set a Ctrl handler for things like CTRL_SHUTDOWN_EVENT etc., and not hInstance or the equivalent module handle. If this is what you're up to then you might want to do it from C/C++ as I've found that while it once worked from CVF it no longer does. I'm not sure about CVF 6.6C but my guess is that it's broken for good.

HTH,
Gerry T.

[Steven_L_Intel1]

I can't imagine what would have changed in CVF to "break" this.

GetForegroundWindow will get the hwnd of a console app.

[Jugoslav_Dujic]

Ah, no, Gerry, now it's your time to be confused :smileywink:. Arguments to SetConsoleXXX (CursorInfo, Mode, etc)functions are HANDLEs (not HWNDs). These can be retrieved/set by Get/SetStdHandle. These refer to "console screen buffer", which is actually a stream (and many file routines are applicable to it).

Messing with console window (the thing that has a HWND) is deliberately made difficult under Windows -- I guess to ensure that console routines are operable in a non-windowed environment. Console window is not quite a normal Win32 window: although it does have a HWND responding to MoveWindow and like, you can't subclass it for example, as it's burried deep into Windows code. As you found out yourself, you have to GetConsoleTitle+FindWindow to find out what it is (there is GetConsoleWindow, but that's kind of late addition/not quite documented).

I don't see any relationship with SetConsoleCtrlHandler?

Jugoslav

[Jugoslav_Dujic]

Hmm, Steve, AFAIK GetForegroundWindow returns the handle of window belonging to any process, not just the calling (console) process -- I don't see how it could be reliably used in the context you mention?

Jugoslav

[Steven_L_Intel1]

Yeah, GetForegroundWindow returns whatever window happens to be in the foreground. Typically that would be the console app you're running, but not necessarily. I tend to use that in my own code in place of NULL, as it seems to have better results (especially with code that could be called from QuickWin.)

I'm just a dabbler here, so don't take my comments with any great weight.

[g_f_thomas]

It could be that I have things mixed up, but :-)... this snippet
:
:
extern void SetCtrlHandler(HANDLE hConOut);
:
INT iret;
BOOL statConsole;
HWND hwnd;
HANDLE hStdOut;
CHAR ConsoleTitle[128];
DWORD dwCharsRead;
:
:
statConsole = SetConsoleTitle("My App Log");
dwCharsRead = GetConsoleTitle(ConsoleTitle, sizeof(ConsoleTitle));
hwnd = FindWindow(NULL,ConsoleTitle);

uses this hwind and not hInstance to

// post messages for the console
PostMessage(hwnd,...);
// customize its event handler
SetCtrlHandler(hwnd);
// customize its startup position
iret=SetWindowPos(hwnd,NULL,0,0,0,0,SWP_NOSIZE | SWP_NOZORDER);
//Show or hide the console
statConsole = ShowWindow(hwnd,SW_NORMAL);
//statConsole = ShowWindow(hwnd,SW_HIDE);

BOOL WINAPI handler(DWORD dwCtrlType)
{
// CHAR szTemp[64];

//The handler masks all console events via return(TRUE)

switch(dwCtrlType)
{
case CTRL_C_EVENT:
//strcpy(szTemp, "CTRL_C_EVENT");
break;
case CTRL_BREAK_EVENT:
//strcpy(szTemp, "CTRL_BREAK_EVENT");
break;
case CTRL_CLOSE_EVENT:
//strcpy(szTemp, "CTRL_CLOSE_EVENT");
Sleep(10000);
break;
case CTRL_LOGOFF_EVENT:
//strcpy(szTemp, "CTRL_LOGOFF_EVENT");
return(FALSE);
break;
case CTRL_SHUTDOWN_EVENT:
//strcpy(szTemp, "CTRL_SHUTDOWN_EVENT");
return(FALSE);
break;

default:
//strcpy(szTemp, "Unknown event");
break;
}
/_cputs(strcat(szTemp, " detected "));
return(TRUE);
}

void SetCtrlHandler(HANDLE hConOut)
{
BOOL status;

// Set custom handler for process
status = SetConsoleCtrlHandler(handler, TRUE);
//_cputs("Handler set ");

return;
}

Jugo, how do you insert smileys in messages?

Steve, I have no idea why writing a console handler in CVF is problematic but I vaguely recall some discussion on this issue. Can it be done in IVF?

Ciao,
Gerry T.

[Steven_L_Intel1]

I have no idea. But the general run-time environments of the two products are very similar. I don't know what the issues are.

[g_f_thomas]

Here's a little Win32 API fuzzy math:

1. HINSTANCE = HMODULE

being the base address at which a module is loaded. Handy for finding a console's HINSTANCE.

2. HANDLE = HWND

ie, generic and window handles are identical.

However, with STRICT type checking in VC++ .NET ( >98% ISO compliant according to the propaganda folks at MS), a distinction between HINSTANCE and HMODULE is to be maintained and WHND is to be used in preference to HANDLE.


HTH,
Gerry T.

[Jugoslav_Dujic]

Part 1) is true. Part 2) is not.

Your sample is (appears to be, didn't check carefully) correct, but it never uses a HANDLE? It usesconsole window HWND --as I said, such techniques are discouraged -- I'm not sure what would ShowWindow(SW_HIDE) do if you run it from full-screen console session.

But no, HANDLE and HWND are not interchangeable in any context that I know of. The former is usually used in context of a stream (file, pipe, console etc.) handle, while the latter is used in context of windows -- and you did not mix them in your sample.

STRICT C++ define enforces that every "atomic" handle type is typedef-ed to a named structure (winnt.h):

#ifdef STRICT
typedef void *HANDLE;
#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef struct name##__ *name

HANDLE is actualy typedef for void*. Windef.h actually defines various handle types:

DECLARE_HANDLE(HINSTANCE);
typedef HINSTANCE HMODULE; /* HMODULEs can be used in place of HINSTANCEs */
...
DECLARE_HANDLE (HWND);

as you can see, HMODULE and HINSTANCE are typedef-ed as pointer to same structure (struct HINSTANCE__*), while HWND is typedef-ed to (struct HWND__*), while HANDLE is (void*) -- and these are not interchangeable under C++ without explicit cast.

Jugoslav

[g_f_thomas]

>Part 1) is true. Part 2) is not.

They're both right.

>Your sample is (appears to be, didn't check carefully) >correct,

It is assuredly correct.

> but it never uses a HANDLE?

It does, look more carefully.

>It uses console window HWND

As per part 2.

>-- as I said, such techniques are discouraged --

Says who? MSDN, VC++7 say otherwise and that's who I go by and so ought you.

>I'm not sure what would ShowWindow(SW_HIDE) do if you run
>it from full-screen console session.

I'm not sure that ShowWindow(SW_HIDE) does much but
ShowWindow(hwnd,SW_HIDE) does exactly what it's supposed to do: it hides the console.

>But no, HANDLE and HWND are not interchangeable in any >context that I know of.

Well now you do.

>The former is usually used in context of a stream (file,
>pipe, console etc.) handle, while the latter is used in
>context of windows -- and you did not mix them in your
>sample.

Did too, :-). Look more carefully.


This topic has gone beyond the point of usefulness. So lets agree to differ.

HTH,
Gerry T.

[Jugoslav_Dujic]

| > but it never uses a HANDLE?

| It does, look more carefully.

I did -- the only HANDLEs are hConOut and hStdOut but they aren't used anywhere except as unused dummy arguments. I understand the sample is snipped from a bigger code. You do pass hwnd to SetCtrlHandler, which expects a HANDLE, but you don't do anything with it there.

You certainly may interchange HANDLE and HWND for your own purposes and cast one to another. Even C++ will let you do that if STRICT is not #defined. My point is, you cannot use a HWND returned by e.g. FindWindow and use that variable for an API which expects a HANDLE (e.g. SetConsoleMode). Even if types happen tobe the same(in Fortran or in C++ without STRICT checking) their semantics is different. That is not the case with HINSTANCE and HMODULE, which started the argument -- they're aliases for the same thing and can be freely interchanged (e.g. GetModuleHandle -> LoadImage). That's the sameprinciple as EQUIVALENCEing (literally or e.g. via Cray pointer, or perhaps TRANSFERing one to another) an INTEGER and a REAL -- you may use the same storage but same operationsdon't apply.

| >-- as I said, such techniques are discouraged --

| Says who? MSDN, VC++7 say otherwise and that's who I go by
| and so ought you.

I did not say they were illegal, justthat they were discouraged. And it's my opinion. I offered an argument that it's not easy to get console's HWND -- you have to use SetConsoleTitle/FindWindow cludge. You may agree or not...

| I'm not sure that ShowWindow(SW_HIDE) does much but
| ShowWindow(hwnd,SW_HIDE) does exactly what it's supposed to do:

| it hides the console.

No need to be bitter Gerry. I just abbreviated for sake of brevity.

...my point is, user does not expect to run a console application from command prompt and have the prompt suddenly hidden, or moved, or resized. It's probably fine to hide the console when it's started from GUI, but some users prefer command line. And I believe that is the reason MS made getting console's HWND deliberately difficult...

| This topic has gone beyond the point of usefulness. So lets agree to differ.

If you like -- but we're discussing more or less exact technical matters, not music or politics. And I don't see any reason tomake itpersonal :smileysurprised:.

Jugoslav

[g_f_thomas]

My involvement in this thread was to bring to Gary's attention the fact that the HWND of a console is at times more useful than its HINSTANCE. I hope that that was helpful to Gary and others.

Engaging in pedantic and bloviating dialogs on the inners of Windows is of no interest to me and makes no useful contribution to forum discussion.

Ciao,
Gerry T.

[garyscott]

You've all been very helpful. Thanks very much. :smileyvery-happy: