I've been trying to get the output handle to my console, but it doesn't seem to work. I got it to set the color of my text, but it's not changing.
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
SetConsoleTextAttribute(hOut, 0x0A)
I tried to debug it and I think I the handle isn't right. Is there any other way to do this, and is it normal that it doesn't work? Any fixes?
Thanks!
EDIT: Let me clarify, the handle that I'm trying to get is invalid. I've no idea how to fix it. I guess I'll start looking for alternatives; maybe something is wrong with my code.
The standard handlers are initialized during process creation, if you call AllocConsole the new console is created far later. AllocConsole can change the standard handles, but it's far too late for them to be used by startup code, such as the C runtime library initialization.
The best thing to do in this case is CreateFileW(L"CONOUT$", ...), which gets a console handle no matter whether you are attached to parent process's console, the OS created one for you because your PE header is /SUBSYSTEM:CONSOLE, or you called AllocConsole. And it gets the console handle even when standard handles are redirected.
And if you think you may call FreeConsole, you should be sure to close any handles returned by CreateFile first. In the general case where the console remains active until process exit, you can let the OS close the handle for you during process cleanup.
Since you specify hOut is INVALID_HANDLE_VALUE (or potentially NULL), try calling GetLastError to find out why. It is likely you don't have console session established.
Is this a win32 Console Application or is it a Windows SubSystem application (does it have WinMain?)
You could try AttachConsole(ATTACH_PARENT_PROCESS) instead of AllocConsole before GetStdHandle.
In either case, AllocConsole and AttachConsole return a BOOL which, if FALSE, indicates you can call GetLastError to find out why.
Make sure you aren't calling hOut = GetStdHandle(STD_OUTPUT_HANDLE) followed by CloseHandle(hOut) prior to the lines listed above. Unlike AllocConsole and FreeConsole, closing the std handle is not a good idea.
Finally, try:
#define _WIN32_WINNT 0x0501 before #include <windows.h>
So much drama for such a small thing... and by the way #Ben's answer is the proper answer is actually right.
For your problem, just do this:
freopen("CONIN$", "r", stdin);
freopen("CONOUT$", "w", stdout);
freopen("CONOUT$", "w", stderr);
This will allow you to get the handle of any console you have. Make sure you put this after AllocConsole();
Enjoy?!
Ok so I found an answer. Seems like a simple edit can fix it
#define setcsattr(clr) SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), clr)
Related
I'm trying to close windows on-screen keyboard (osk.exe) in c++ code, but without any success.
HWND kbIsOpen = FindWindow(TEXT("OSKMainClass"),NULL);
CloseWindow(kbIsOpen);
CloseWindow or SendMessage didn't to anything.
Note that the problem is not in kbIsOpen, and also getLastError returns 5 (ERROR_ACCESS_DENIED).
What I can do to deal with this problem?
Assuming FindWindow returns a valid window handle, SendMessage(kbIsOpen, WM_DESTROY, NULL, NULL); should close it. (Although it's kind of a dangerous way to do it. Try sending WM_CLOSE and WM_QUIT first.)
However, it's possible that the keyboard window throws away destroy messages, and just keeps on going no matter what you throw at it. I'm running Windows 7, so I can't tell you myself.
< unimportant opinion > bkIsOpen sounds like the name of a boolean variable telling you if the window is open, not a handle to the window if it exists. < /unimportant opinion >
I have a C++ Win32 application written using Win32 API and I wish to force it to exit in one of functions. Is there something like Exit() or Destroy() or Abort() something similar that would just terminate it?
Aiiieeeeeeeeeeee. Don't do ANY of these things!
exit() and ExitProcess are the equivalent of taking a gun and shooting the process in the face. I hope I don't have to explain why that isn't nice, especially for processes that are holding shared objects like database handles that might be system-wide. I know that's the norm in Android, but this is Windows and we don't do that 'round here.
Calling PostQuitMessage() directly can cause memory leaks. PostQuitMessage() is intended to be called from WM_DESTROY. It is NOT NOT NOT a message intended to be used to ask a window to close. It's a callback mechanism for applications to post their exit code back to the shell. It is intended to populate WM_QUIT with the application exit code. If you call PostQuitMessage() directly, you will bypass WM_DESTROY entirely. This is problematic because many windows--and child widgets--very correctly perform their clean-up in WM_DESTROY. If you skip this message by lying to the window, you will deny components the chance to clean up.
And since we're on the topic, don't call WM_DESTROY directly either. Raymond Chen of Microsoft has a wonderful article where he explains "Sending a window a WM_DESTROY message is like prank calling somebody pretending to be the police". It's sort of the evil-twin of PostQuitMessage. Instead of exiting without cleaning up, you're asking the window to clean up without exiting. The window manager never knows to remove the components, and you're left with a dead orphan window in memory. Sigh.
The correct answer is to post WM_CLOSE. Anything using the default window procedure will correctly notify the window manager to destroy the window which will cascade on to WM_DESTROY then to WM_QUIT as intended.
If you need different behavior than the standard close, the other alternative is to create a WM_USER or WM_APP message. If your window has a "fancy" WM_CLOSE--say, for example, you give the user a prompt "Are you sure you want to exit?"--and you want to skip that, you may define a custom message with WM_USER or WM_APP and call that in its place. Your app-defined message would implement the default close behavior, and the WM_CLOSE that's tied to the system gadgets performs your fancy behavior.
I hope that helps!
PostQuitMessage() is the standard, graceful way of quitting a windowed application.
It will not immediately quit but rather post a quit message that will get parsed by your main loop (if done correctly) and then quit the application.
If you're using a Win32 application with a proper window procedure, you can use the function PostQuitMessage.
If you're working with visual C++, then use:
PostQuitMessage()
ExitProcess is the function to use, else you can use exit, note that neither insure the integrity of the shutdown (ie: you many leak handles etc and threaded operations will be terminated, even if they are halfway through an operation, like a db commit)
Yes, it's exit()
http://www.cplusplus.com/reference/clibrary/cstdlib/exit/
Just return from the WinMain function. If you have a message loop, use PostQuitMessage to break out. Don't try to exit the process in the middle of execution; it's sloppy.
If my application crashes, I use an ExceptionFilter to catch the crash, perform some final actions, then show a message box to the user that the application has crashed.
Because the application already crashed, there's not much I can (or I dare) to do, because if I do too much, the executed code might access corrupted memory and crash again.
Some of the things I currently can't do (or I don't dare to do) is to close network connections, Oracle database sessions, ...
Problem is that if an application crashes, and the user is out to lunch while the MessageBox is open, other users might be blocked, because of the open database session. Therefore I want:
Either a MessageBox with a time-out. Problem is that you can't do this with the standard MessageBox Win32 API function, and I don't want to make a specific dialog for it (because I want to minimize the executed logic after the crash)
Or the possibility to close the MessageBox from another thread (the other thread can provide the time-out logic).
Did I overlook something in the Win32 API and is there a possibility to have a MessageBox with a time-out?
Or what is the correct way to close an open MessageBox from another thread (how to get the MessageBox handle, how to close it, ...)?
While I agree that spawning a new process to display a fire-and-forget dialog is probably best, FWIW there is actually a timeoutable messagebox function exported from user32 on XP & above; MessageBoxTimeout (as used by things like WShell.Popup())
Quick copy/paste solution:
int DU_MessageBoxTimeout(HWND hWnd, const WCHAR* sText, const WCHAR* sCaption, UINT uType, DWORD dwMilliseconds)
{
// Displays a message box, and dismisses it after the specified timeout.
typedef int(__stdcall *MSGBOXWAPI)(IN HWND hWnd, IN LPCWSTR lpText, IN LPCWSTR lpCaption, IN UINT uType, IN WORD wLanguageId, IN DWORD dwMilliseconds);
int iResult;
HMODULE hUser32 = LoadLibraryA("user32.dll");
if (hUser32)
{
auto MessageBoxTimeoutW = (MSGBOXWAPI)GetProcAddress(hUser32, "MessageBoxTimeoutW");
iResult = MessageBoxTimeoutW(hWnd, sText, sCaption, uType, 0, dwMilliseconds);
FreeLibrary(hUser32);
}
else
iResult = MessageBox(hWnd, sText, sCaption, uType); // oups, fallback to the standard function!
return iResult;
}
You should ask yourself, why you want a messagebox in the first place. When it is OK that the message box is not seen when noone is sitting in front of the computer, why isn't it OK that the user doesn't see a message when his program disappears?
If you really want it, I think the simplest solution is to spawn a new process displaying the message. It can run as long as it wants and does not interfer with your crashing program.
I noticed that if the main thread simply exits the application while the other thread still has the ::MessageBox open, that the MessageBox is being adopted by a process called CSRSS. This solves my problem, since this only requires a time-out on the Event in the main thread (WaitForSingleObject with timeout).
However, this raised another question: https://stackoverflow.com/questions/3091915/explanation-why-messagebox-of-exited-application-is-adopted-by-winsrv.
This does not justify a thread.
The best solution would be to use a modal dialog box that registers a timer for auto-close.
What about just logging the event to a local file (and record memory dumps or whatever information you might need for later debugging)?
You could close your application, close network connections and do your housekeeping stuff.
As soon as the application is started again, you can inform your user (based on local file information) that the application has crashed during last execution.
A Win32 MessageBox really is a dialog, with a dialog message pump. You can therefore rely on standard Win32 timer messages (WM_TIMER). Send one to your own window, and when you do get it, dismiss the MessageBox by sending a WM_COMMAND/BN_CLICKED message to the ID_OK button.
The messagebox, since it's a dialog, will be class "#32770". Since it's the only dialog box you will have open, it's easy to find amongst your child windows.
I would run your original code from inside a wrapper application that does a CreateProcess and then a MsgWaitForMultipleObjects on the process handle (most process launching code samples use WaitForSingleObject, but you need to guard against messaging deadlock scenarios). Your watching process can then detect the failure of the spawned process, pop up its own timed-out dialog, and exit on user response or timeout.
I think that's the cleanest solution which prevents your unstable program having to execute any code.
From the native Win32 API using C++ is there a way to determine whether the window associated with an HWND is still valid?
You could use the Win32 API IsWindow.
It is not recommended to use it though for 2 reasons:
Windows handles can be re-used once the window is destroyed, so you don't know if you have a handle to an entirely different window or not.
The state could change directly after this call and you will think it is valid, but it may really not be valid.
From MSDN (same link as above):
A thread should not use IsWindow for a
window that it did not create because
the window could be destroyed after
this function was called. Further,
because window handles are recycled
the handle could even point to a
different window.
What can be done?
Perhaps your problem can be re-architected so that you do not have the need to check for a valid handle. Maybe for example you can establish a pipe from the client to the server.
You could also create a windows hook to detect when certain messages occur, but this is probably overkill for most needs.
This question is old, but I needed this functionality myself and was a bit disappointed after reading about the caveats. However, after doing a bit more digging it seems that all is well. Unless you're dealing with 16bit programs, IsWindow appears to be the way to go. The problem of handle re-use appears to have been sufficiently addressed according to this:
http://blogs.msdn.com/b/oldnewthing/archive/2007/07/17/3903614.aspx
So, because of the upper 16bit reuse counter, it is highly unlikely that you'll run into a window reuse problem.
You can use IsWindow() or also try to send the window a WM_NULL message with SendMessage(hWnd, WM_NULL) and see if it is successful.
Also, it is true that the window could be destroyed at any time if it isn't under your control. As others have stated the handle could potentially belong to another window as the handles are reused. In reality I don't know how likely that is.
The only solution that I know of the to create a system wide hook that looks for messages indicating a window is destroyed (WM_CLOSE, WM_DESTROY). Then you would compare the message window handle to ones you are holding to see if any of the windows you care about are affected. See here for more information on system wide hooks.
Maybe a combination of IsWindow, FindWindow and GetWindowThreadProcessId will be more accurate
HWND windowHandle = FindWindow(NULL, TEXT("window_title"));
LPDWORD oldpid = 0;
GetWindowThreadProcessId(windowHandle, &oldpid);
//after some time
if (IsWindow(windowHandle))
{
LPDWORD newpid = 0;
GetWindowThreadProcessId(windowHandle, &newpid);
if (newpid == oldpid)
{
//the window is still running
}else
{
//the window exists but has changed
}
}
If the window procedure for the window in question is under your control (or if you can subclass it), then I would suggest registering a custom message that the window responds to with a non-zero result. Sending that message to any other window (or an invalid HWND) will result in 0.
Of course, that only tells you if the HWND refers to one of the windows that you control -- but perhaps given other answers above that might even be advantageous.
Use RegisterWindowMessage to register the message, using a sufficiently unique name.
if(IsWindow(FindWindow(NULL , TEXT("Example Window Name")))){
// do stuff
}
will check if the window exists and has the appropriate name
I have a written a Visual C++ console application (i.e. subsystem:console) that prints useful diagnositic messages to the console.
However, I would like to keep the application minimized most of the time, and instead of minimizing to the taskbar, appear as a nice icon on the system tray. I would also like to restore the console when the system tray icon is clicked.
How should I change my program to do this?
This is going to be an ugly hack.
First, you have to retrieve the hWnd / hInstance of you console application. Right now, I can only come up with one way:
Create a Guid with CoCreateGuid()
Convert it to a string
Set the title of the console window to this guid with SetConsoleTitle()
Find the hWnd of the your window with the Guid as the tile with FindWindow()
And you can do it from the usual way from this point. See http://www.gidforums.com/t-9218.html for more info.
Don't forget the rename your console window to the original title once you're done.
As you can see, even though this is possible to do, it's a horrible and painful solution. Please don't do it. Please do not minimize console applications to the system tray. It is not something you are supposed to be able to do in the Windows API.
You might want to write a separate gui to function as a log reader. You will then find it much easier to make this minimize to the tray. It would also let you do some other stuff you might find useful, such as changing which level of logging messages are visible on the fly.
To learn the console's hWnd you have two choices:
On Windows 2000 or later you can use the GetConsoleWindow() function. Don't forget to define _WIN32_WINNT as 0x0500 or greater before including windows.h to have access to this function.
If you want to run your program on earlier Windows versions as well then you must use something like the GUID trick described above.
Probably your best bet is to create a "Message-only window" (a message queue without a visible window) to receive the Notification Area messages.
The answer with a GUID is completely ridiculous (no sense at all)
The Console hWnd is of course given by GetConsoleWindow() (!)