Hiding Command Window and minimizing to system tray

I was wondering if there’s a way to easily hide the command window on windows that is part of all the OF applications.

Also, how hard would it be to have the ability to minimize an application to the system tray (showing just an icon)? I’ve found some various code for doing it (example here:, but I’m not sure if it’d require hacking the core of OF where windows are setup or something since I’m sitll new to c++.


1 Like

it’s been a while since i used Windows, so i might be talking nonsense, but from the sound of it i imagine that if you edit the shortcut that launches the openFrameworks application to just launch openFrameworks.exe, rather than launching cmd.exe /something blahblah openFrameworks.exe, this should get rid of the command shell.

as to being able to minimize to taskbarl: oF is built on GLUT, which doesn’t provide this functionality. hopefully coming with 0.06 you will be able to swap something else in to replace GLUT but this will probably require some high level programming skills. GLUT takes care of all the horrible HINSTANCE rubbish (and the equivalent rubbish on OSX/Linux), but it also means you lose access/control of it.

Thanks for the reply damian. I’ll have to look into the cmd window like you said. Is that a compile option to remove the command shell? There’s no shortcut when compiling so it’s not as simple as launching the exe since that’s already what I’m doing.

If anyone knows a way around the system tray issue and GLUT, that’d be great.

Is that a compile option to remove the command shell? There’s no shortcut when compiling so it’s not as simple as launching the exe since that’s already what I’m doing.

hrm. i think the command shall you’re talking about when compiling is being launched by the IDE. if you just double-click the exe from Explorer, the app should run without a command shell. if not, then something weird is happening at a deeper level, and i don’t have an answer (and probably again, it’s a GLUT thing, so there is no answer…)

I think the console you see when you double click the app in the explorer can be removed by :


damians right, when you run the app in the compiler, as I understand it, it’s running a special cmd prompt to run the app, so that will always be there.

take care!

1 Like

you can hide the console in windows by adding the following to your main.cpp:

#pragma comment(linker, "/subsystem:\"windows\" /entry:\"mainCRTStartup\"")   

I just started playing with OF on windows, and I too would prefer if the command window didn’t show up.

Using FreeConsole() as zach suggested seems to pop up the command window for a second and then closes it before the glut windows appears, which is alright, but not ideal.

Using the #pragma preprocessor directive that pkmital suggested seems to work the way I would want it to, only the glut window shows up.

However both of these methods seem to have a pretty nasty side effect: they both hide the command window, but when the user closes the glut window the command window process is still running invisibly in the background.

Is there any way to check if the window is closed (or even better have an event fired), and if so exit the program? I’m guessing there probably is if you dig down into the glut code, but OF doesn’t seem to provide an easy way to do this.

Just throwing one more technique into the ring:

HWND handleWindow;  
handleWindow = FindWindowA("ConsoleWindowClass", NULL);  
ShowWindow(handleWindow, 0);  

Doesn’t deal with the issue mentioned immediately above, but it does hude the console that’s generated by the compiler.

Even easier:

  1. in CodeBlocks right click on the project in the sidebar.
  2. select the Properties option
  3. In Build Targets tab set Type: to GUI Application

Now rebuild and you should have an app with no console window.


1 Like

Thanks Theo, it worked!

However, even if I close the GLUT window, the process is still running on the background.

Has anyone solved the issue?


I just found this info…


3.070 I have a GLUT program that allocates memory at startup. How do I deallocate this memory when the program exits?

If the user exits your program through some input that you can catch, such as a key press or menu selection, the answer is trivial. Simply free the resources in the appropriate input event handler.

Usually, this question comes up because the user has killed the program through window frame controls, such as the Microsoft Windows Close Window icon in the upper right corner of the title bar. In this case, your program won’t get a GLUT event indicating the program is exiting. In fact, when the window is destroyed, glutMainLoop() simply calls exit(0).

For simple resources such as memory deallocation, this should not be a problem. The OS will free any memory that the process was using.

Of greater concern is prompting the user to save work or flushing data held in software buffers to files.

When using C++, the simplest solution to this problem is to wrap your GLUT application inside of a C++ class and create it with global scope. The C++ language guarantees that the class’ destructor is called when the object goes out of scope.

Another option is to use the ANSI C/C++ atexit() call to specify the address of a function to execute when the program exits. You need to declare your buffers and data pointers with global scope so they’re acccessible to the atexit() callback routine. More information can be found in any ANSI C/C++ reference. atexit() is only available with C/C++.
3.080 How can I make my GLUT program detect that the user has closed the window?

The same way as the previous section 3.070 shows.

this should be fixed in latest OF ( 0.061 ) - we made it so the [x] button stops the app.

Thanks Theo…

In case you still need to work in OF (0.06) take a look into ofAppGlutWindow.cpp from the OF version 0.061

this is what you need to add in the ofAppGlutWindow.cpp before the constructor ofAppGlutWindow::ofAppGlutWindow()

#ifdef TARGET_WIN32  
// this is to fix a bug with glut that doesn't properly close the app  
// with window closing.  we grab the window procedure, store it, and parse windows messages,  
// using the close and destroy messages and passing on the others...  
static WNDPROC currentWndProc;  
static HWND handle  = NULL;  
static LRESULT CALLBACK winProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam){  
   //we catch close and destroy messages  
   //and send them to OF  
      case WM_CLOSE:  
      case WM_DESTROY:  
         return CallWindowProc(currentWndProc, handle, Msg, wParam, lParam);  
    return 0;  
static void fixCloseWindowOnWin32(){  
	//get the HWND  
	handle = WindowFromDC(wglGetCurrentDC());  
	//store the current message event handler for the window  
	currentWndProc = (WNDPROC)GetWindowLongPtr(handle, GWL_WNDPROC);  
	//tell the window to now use our event handler!  
	SetWindowLongPtr(handle, GWL_WNDPROC, (long)winProc);  

Also add in the function initializeWindow() the following code:

 #ifdef TARGET_WIN32  
        // this is specific to windows (respond properly to close / destroy)  

It runs great!!!

[quote author=“theo”]Even easier:

  1. in CodeBlocks right click on the project in the sidebar.
  2. select the Properties option
  3. In Build Targets tab set Type: to GUI Application

Now rebuild and you should have an app with no console window.


Is there any solution like this for compiling with Visual Studio?


I was fighting with the same issue, and there are a pair of things.

To avoid the console to apppear in Visual Studio (2010), right-button over the project, click “properties”, and in the subsystem option change “Console (/SUBSYSTEM:CONSOLE)” to “Console (/SUBSYSTEM:WINDOWS)”.

Try to compile like this. If it works, perfect.
But I also got a compilation error:
“MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup”
It is related to the “int main()” function. It is like VS does not get properly this function. I found a way to solve although I did not go deeper into the reason this works. But the solution is simple. Change in “main.cpp” the function "

int main(){  

" to “int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd){” and hopefully it will compile properly.

Hope it is helpful for sb.


thank knote, thats a good solution.
i found the subsystem switch under the linker folder:

  1. Open the project’s Property Pages dialog box.
  2. Click the Linker folder.
  3. Click the System property page.
  4. Modify the SubSystem property.

Thanks for this solution, it’s work for me with Visual Studio Express 2012.

  • Edit Linker (switch CONSOLE to WINDOWS)
  • Edit main.cpp

Just have another trouble. Is it possible to add a ico to the window ? I’m able to edit the Console ico (who is no hide), but not the app window ico. I have found a way with CodeBlocks (simply edit ico.rc) but not with Visual Studio…

1 Like

thanks Its working