Short version:
How do I initialize and use DirectInput if I have no access to the HWND/HINSTANCE?
Background information:
I am currently using SFML for most parts of my program, amongst others for window creation. Works like a charm. But I'm not fully satisfied with SFML's input system (e.g. I want XInput for XBox 360 gamepads) and want to write my own.
I've already written the XInput part, but for other gamepads/joysticks/... I also need DirectInput. Since SFML hides the Windows-related code from the user (and rightly so) I don't have access to the hwnd or hinstance. How can I use DirectInput without it? Maybe catching input all the time, not only when the window is active? (I could then filter it based on the Window's (de)activated event.)
Thanks,
Mr. Wonko
Finding the window back isn't too hard, use EnumThreadWindows() and GetCurrentThreadId().
Note that DirectInput doesn't need a window handle anywhere. It just needs the instance handle in DirectInput8Create(). GetModuleHandle(NULL) is good for an SFML app.
To get HINSTANCE you can call: GetModuleHandle(NULL)
Related
Hi i Want to Add Window(Gui) to my ConsoleApplication in C++
How to do this?? I need something called Hwnd? I tried to use it and it does not work for me
Basically what I want to do is a MessageBox that will be every time somewhere else on the screen .. but I realized that you have to do it with HWND.
I need Tutorial How to create windows with hwnd
I try:
HWND GetWindow(HWND hWnd, UINT uCmd);
Check if the following code meet your requirement:
#include <windows.h>
int main()
{
MessageBox(nullptr, TEXT("Hello World!"), TEXT("Message"), MB_TOPMOST);
}
It will like this:
You've used multiple tags, I have a winapi solution, not a winforms one.
You can use a std. MessageBox by calling the function, but they can't be „evolved“ into your custom windows for any reasonable „price“ so they can only notify user and ask simple yes/no questions. For „real“ windows, let's forget MessageBox.
The simplest custom window is a std. windows Dialog. It uses the pre-defined window class #32770, so you don't have to register your window class, create a message loop etc. The simplest way to open it is DialogBoxParam function. You must make a .rc dialog script (there are lots of visual editors), compile it with a resource compiler, link into your .exe and pass it's name as the parameter for DialogBoxParam.
Here's an example of a window inside a console application (C++ part only), using this DialogBoxParam call
DialogBoxParam(GetModuleHandle(NULL),"EXAMPLE",NULL,ExampleWindowFunction,NULL);
It's here: https://pastebin.com/Crkdy5FB
It also contains image drawing (you probably don't need it yet, it's left from another winapi example). Use it as a sandbox, you'll probably quickly understand how it works and what role the hWnd plays here.
I understand your problems. GUI got so overcomplicated so it's hard to understand what exactly you don't understand. It prevents from asking a good question.
How to know the name/ID of window in focus specifically in OpenCV.
Is there any event handling/callback or windows api that make this possible if it is not possible with OpenCV.
I am working on Windows 7 and 8.1.
I want to do something similar to (but not limited to):
If a window is in focus, and some event like mouse or key press happens,
then update that particular window
.
As suggested by Kris, there exists a solution on window. Use windows api to take handle of active window as using:
HWND WINAPI GetActiveWindow(void);
Now use GetWindowText() function to extract out title, if any. It may not be portable. There should exist similar api for other OS.
first of all, I don't know if windows or any other api can help.
I have an idea to take screen-shot, somehow, and then use opencv itself for image processing. Assumption is that the focused window will be on the top and most focused so we can see the name easily. We can process color to separate focused window from others, if any. And using OCR to extract windows name.
I know how to get and set the handle of another applications window in the code, but I don't know how to set the applications handle at runtime through an edit control. the problem is is that I have to keep compiling my application every time I want to use it, because the handle of the window in application 2 is dynamic.
does anyone have any ideas?
To find current HWND of application window you are interested in, you can enumareate windows using EnumWindows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633497%28v=vs.85%29.aspx
or maybe easier is to use FindWindow, if you know its name/class:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633499%28v=vs.85%29.aspx
you can also use GetWindow to iterate windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633515%28v=vs.85%29.aspx
...lots of possibilities
I want to develop Windows program who can stick into other
window.
I searching fastest-way to do this. I can get by WinAPI all
information about target window and move my window into good location
and after it Sniffing Windows Messages of target window to searching resize or move window and after this doing move my window again. But i don't know what is a simplest good working way (maybe somewhat on .NET? But i don't preffer answers in .NET i like free framework's).
I want to stick on the top, bottom, left, right of the target window, but this maybe never mind.
Can anyone help me something with this problem?
Thanks.
I used DLLInjection to get into target windows process, created some hooks using winapi calls and by XML over Message Pipe transporting this values to other application who stick to this windows.
You basically need to do two things:
Get a list of all windows to which your app is supposed to stick, and their locations/dimensions.
Listen to your application's main window's move event and if at any point your window gets close enough to any of the relevant windows from #1 you move it yourself so that they align.
You can do both in Win32 API or with .Net. You just need a good criterion for #1. Like, for example, all top level visible windows that are within the desktop's boundaries.
Might want to include the desktop itself in the list above, so that your app sticks to the edges of the desktop as well.
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() (!)