I've been developing a win32 console app and now I'd like it to be able to optionally show a non modal status / notification window. Is there any way I can do this from a console app or will I need to rewrite it as a windows app?
This is for a kiosk system so I'll need to call SetWindowPos() with the topmost flag on the window handle.
As far as I remember the main difference is that you'll need a message pump. This question describes a basic message pump: Why are "TranslateMessage" and "DispatchMessage" separate calls?
This tutorial might also be helpful: Understanding the Message Loop
see a CreateWindow / CreateWindowEx functions
Related
I have a shell extension that needs to reload its configuration when a specific window message (custom message registered with RegisterWindowMessage) is broadcasted by another application.
I tried several approaches to intercept the message:
Installing a window subclass callback on a window of Windows Explorer, using SetWindowSubclass. This works on Window 7, but not on Windows 8, because apparently DllMain is not called on the main thread, and SetWindowSubclass doesn't work from another thread. This is mentioned in the documentation:
You cannot use the subclassing helper functions to subclass a window across threads
Installing a hook for CALLWNDPROC, using SetWindowsHookEx. Because I don't want to slow down the whole system, I install the hook for a specific thread only (the explorer's main thread). This works on Windows 8, but not on Windows 7... I suspect this is because I'm hooking on the wrong thread, but I'm not sure. And anyway, this approach seems overly intrusive.
Creating a message-only window to handle the message. This doesn't work at all, because message-only windows don't receive broadcasted messages.
Is there a reliable way to receive a window message in a shell extension?
A window message initially seemed to be the easiest way to notify the shell extension, but if you think another mechanism would be more appropriate, I'm open to suggestions.
Create a hidden window and listen for the message in its window procedure.
Register a window class that has default values for all the fields apart from the window procedure and class name. You don't need to specify anything else in the window class since the window will never be visible.
When you create the window, pass 0 for the window style. Specifically exclude WS_VISIBLE.
Pass 0 for the WndParent when you create the window. This will make it a top level window and so eligible to receive broadcast messages.
My application is a fullscreen window which is rendering a designated other window (from dwm), for example Google Chrome. I would like to know if it's possible to send events (such as mouse keyboard events) to the specified window.
Of course the designated window has to stay in background, and my current application on the foreground.
My application is written in C++. I'm working on Windows 7/8.
Just to put it into an answer.
Based on this question Does any program/language/library that interacts with windows do it via the WIN32 API? you should be able to use the windows API to send a windows message to any window. All you need to get is that windows handle, or you could do a broadcast to all windows.
The specific function http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx
Though that function will block until the windows responds and processes the message, this could hurt GUI performance. If you notice issues try implementing http://msdn.microsoft.com/en-us/library/windows/desktop/ms644951(v=vs.85).aspx instead.
I am experimenting with a home-grown application hosting framework, and I'd like to abstract the input/output so I can gracefully handle crashes. Chrome uses a very similar model.
Is there any way I can take an arbitrary window handle, and persuaded it to start rendering to a back-buffer? Or should I create my own window first, and then reparent the client app into it?
As the comments said you can do anything if you're willing to dig in and hook the APIs themselves, but according to the remarks in the MSDN WM_PAINT page WM_PRINT is the supported way to force a window to paint on a specific DC.
It sounds like you also need to keep the window from showing up on the desktop - in that case you can use WM_SETREDRAW as described in On Win32, can I disable painting of a window for a period of time?.
Is it possible to use Windows Raw Input API without a window (ie from a console application)?
I've tried using RegisterRawInputDevices but my message loops doesn't seem to get any events from GetMessage and hence just 'hangs' there.
That way I did it (not sure it is the most comfortable way...):
I have started a thread (for the task of filling my input buffer).
In this thread I have created a message-only window (its hidden, and can get input datas) with an appropriate window-class.
Then registered the raw input devices.
This thread has its own message handler loop.
In the WindowProc of the window-class I've handled the inputs.
(For buffer, You can use boost:circular_buffer, it ROCKS! :D)
In this solution You did need have a window, but it looks like You don't. :)
I hope this can help.
Do you mean RegisterRawInputDevices?
Since the RAWINPUTDEVICE structure requires you to specify an HWND to receive the WM_INPUT messages, no it's not possible to do this without a window.
Console applications can create windows, and the window probably can receive WM_INPUT while hidden, but you do need a window.
There is an application written in Java using AWT. And I want to resize its windows by an external program. My OS is Windows XP. Actually this application is an online poker client.
The windows are of "SunAwtFrame" class, so I look for those windows and call MoveWindow/SetWindowPos on them. The result is not the one I expect:
a problem http://savepic.net/1331700.png
As you see, the window did resize, but the content did not. While resizing manually it scales, and I want the same behavior here.
Probably, some additional action are needed to make AWT windows understand it was resized.
How can I fix the problem?
I recommend doing this:
Use Spy++ (available as a tool in Microsoft
Visual Studio) to filter messages sent to the SunAwtFrame window.
Resize window manually.
Figure out which messages are sent to the window during resizing. Use
MoveWindow/SetWindowPos and/or send those messages after you resize.
Take a look at functions InvalidateRect and UpdateWindow.