I'm trying to make a Windows app that checks some things in the background, and inform the user via a systray icon.
The app is made with Not managed C++ and there is no option to switch to .net or Java.
If the user wants to stop the app, he will use the tray icon.
The app can't be a Service because of the systray side and because it must run without installing anything on the user computer ( it's a single .exe )
Using the typical Win32 program structure ( RegisterClass, WndProc and so on ) i dont know how can i place some code to run apart the window message loop.
Maybe i have to use CreateProcess() or CreateThread()? Is It the correct way to handle the Multithreading environment?
If i have to use CreateProcess()/CreateThread(), how can i comunicate between the two threads?
Thanks ;)
As for the system tray icon, you'll need Shell_NotifyIcon.
See http://msdn.microsoft.com/en-us/library/bb762159.aspx
I doubt you want to create new processes to do this, you want to create a thread in your application. The API to do this is CreateThread. But if you are using C++, you should really be investigating the use of frameworks and class libraries to do this, not writing what will effectively be C code from scratch.
All threads belonging to an application share the global variables of the application, which can thus be used for communication. You will need to protect such multi-threaded access with something like a critical section.
Related
Good day,
I have the following issue:
I have one exe application that writes text files to the disk, and that exe source is unavailable.
Customer has asked that, when users press numpad 5, a new window pops up, and does some operations with some files.
Problem is, numpad 5 + new application popup MUST only work when the application is running and has focus (they use numpad 5 for other operations).
I thought about this
create a dll with a form and buttons that do the required actions
inject the dll in the process
But I'm struggling to understand if there is a way to create a "keypress loop" in the dll.
Please note that I'm a beginner in c++ and forms, but I just need a feasibility check and a direction.
Is it possible to create a window application that waits for a keypress in an injected dll?
Is it there any simple example of this? Using google like a madman I was unable to find references to this so I think I have a problem with the proper terms.
My main issue is that the dllmain is obviously a one shot routine, and I don't understand how to create an "event loop".
Thanks for any information provided.
If you have successfully managed to inject your DLL in the traget process, use the _beginthread API in DllMain to start a new thread, and in that thread you can create a Dialog Box and have a message loop in the usal way.
I'm writing an editor and I have a problem which means calling native file save/open dialog from my opengl app. The editor is written with my in-game opengl gui. So i came up with idea that when user press "load" or "save", I will create a thread which will create required (non-visible) wx window and it will call wxFileDialog and after the job is done I will delete that thread. Is it possible or maybe there are better aproaches to acces file open/save dialog in cross platform way from an opengl app?
wxWidget has a OpenGL widget. Put your OpenGL stuff into this one, forward the event received by the widget to your GUI system, then you'll not have to battle for the event loop.
As others have already said, the simplest solution is to use wxWidgets for the main loop and wxGLCanvas for OpenGL stuff.
But if this is impossible, for some reason, you should indeed be able to use wxWidgets from another thread. Just remember that wxWidgets GUI functionality can only be used from a single thread so you need to initialize it from that thread too. And, of course, you'll need to handle thread synchronization yourself as wxWidgets won't know anything about the rest of your program.
If you are using GLUT, or equivalent, then you do NOT have a cross-platform framework. If you want a cross-platform app, then your will have to choose a framework ( e.g wxWidgets or Qt or whatever ) and proceed from there. Otherwise, you can use the native calls to the windows API if you are on windows, and the equivalent on other platforms.
GLUT only gives you a console style application. If you want a GUI, then you have to choose a GUI framework, even if you do not want cross-platform. There as many to choose from, the choice mostly depends on which you are most familiar with. Then you add the calls to the OpenGL library from you GUI application, however built. This way, you do not have to muck around with multiple threads.
It may be that you have a massive investment in your GLUT application, and do not wish to discard it merely to get a few GUI capabilities. In this case, I recommend building a new GUI app, separate from your GLUT application, which communicates with your existing app using a socket ( or other interprocess com system ) but runs in a separate process. This way you will not encounter all the ghastly, hard to fix bugs, created by multithreaded apps.
I would like to have the ability to process Win32 messages in a console app and/or inside a standalone DLL.
I have been able to do it in .NET with the following article and it works great in C# inside a console app and standalone DLL
http://msdn.microsoft.com/en-us/magazine/cc163417.aspx
Is there a way to do the equivalent with C/C++ Win32 APIs? I have tried doing RegisterClassEx(...) and CreateWindow(...) even passing in HWND_MESSAGE to hWndParent but the trouble is that after the "invisible" window is created messages are not being processed probably due to the lack of a message pump.
Where would the message pump go if you had a DLL entry point? I have tried creating another thread in a DLL and put while(GetMesage(..)) there but that did not work either.
Any ideas?
You need a message pump yes. The window also has thread affinity so it needs to be created on the same thread that you're running the message pump on. The basic approach is sound, if you include more code it may become clear what the problem is.
In addition to what Logan Capaldo said, you also have the problem that, as a DLL, you don't know at compile time what kind of process is going to be loading you at runtime.
If you are being loaded by a console application (/SUBSYSTEM:CONSOLE), then creating a hidden window of your own and setting up a message pump on that same thread will work fine (as long as you are the first window created).
If you are being loaded by a windows app (/SUBSYSTEM:WINDOWS) then you might run into problems getting messages. They will be sent to the top-level window in the hierarchy, which you didn't create. You'll need to get the hWnd of the main process and subclass it (if you aren't already).
If you are being loaded by a service, then you aren't going to get window messages at all. You instead need to use the RegisterServiceCtrlHandlerEx Function
I want to add a wrapper to the MFC WinMain in order to be able to make a MFC application be able run as GUI application or as a service.
Can I add a wrapper to WinMail from MFC without modifying MFC source code?
It is possible, just check the command line parameters in order to change the behavior. Check http://msdn.microsoft.com/en-us/library/ms687414(VS.85).aspx
In case you will want to make it work as console remember that it is not possible to make an application that is running as both console and GUI on Windows. Still there is not limitation for services, a service application can be a GUI one or a command line one.
i got to do a task that is to find out process /exe/application running in the background.
ie:the process is running but do not have any UI/ Window visible although its an windows GUI application . i thot of reading EXEheader. The header contains a field called 'Subsystem'and application is to run under and the type of interface it requires.
but it returns Windows GUI and it is so. but i want teo detect if that application haves any window or not. also this application is not a service as if it is a service i can easily read the info.
i will be glad if any of you genious put some light on the pronblem stated.
Warm Greetings..
Sarfu
If I understand your question correctly, you want to know if a running application has any visible windows.
To do this, you can call EnumWindows to get all top-level windows. For each window, call GetWindowThreadProcessId to get the process ID and GetWindowLong(hwnd, GWL_STYLE) to get the window style. Test the style for WS_VISIBLE to see if the window is visible. Run through all the windows and see if your process owns a visible one. If you don't have the process ID, you can get them all with EnumProcesses.
The "subssytem" GUI doesn't tell you that the application has a window. In fact, the opposite is closer to the truth. A console application gets a console window. A GUI app is responsible for creating its own windows, if and when it needs them. A GUI process that hasn't called CreateWindow() won't have any windows.
Apparently, you do know the executable you're looking for. In that case, call EnumProcesses() to find all processes, and for each process call EnumProcessModules(). On Windows, "modules" are DLLs and EXEs. Each process will have exactly one EXE module. So, if the one EXE module of any process is the executable you're looking for, then your application is running.