Consider the case of a separate executable which has to be called from another application, and the console application emits its progress through stdout, stderr outputs. Now, I referred this article on Codeproject, and it allows me to run this application silently. However my main application appears completely frozen as it should since the console application takes its time to finish. Now, it'd be nice to be able to capture the console output and show the progress messages on a 'GUI-like' read-only window as here:
I know it can be done, as they have done for large programs like ffmpeg, etc that are console based. How can it be done in Win32 API?
The obvious way is to create a thread that reads the stdout and stderr of the child process. When there is new content, this thread notifies the UI thread which then displays it.
Related
When I debug my program, which consists of looping over thousands of entries in vectors multiple times, it simply freezes the program but does not provide any error messages whatsoever. Does Visual Studio have some sort of auto-time out that I am experiencing?
Check may be your program is going into infinite loop Or doing some heavy task that makes your UI unresponsive(if you have windows form). Since you are debugging this program then why dont you set breakpoint in code and check where your program is causing issue.
And yes there is no time out for Visual Studio,But for program window.This is known as Hang Status.
When an application (or more accurately, a thread) creates a window on the desktop, it enters into an implicit contract with the Desktop Window Manager (DWM) to process window messages in a timely fashion. The DWM posts messages (keyboard/mouse input and messages from other windows, as well as itself) into the thread-specific message queue. The thread retrieves and dispatches those messages via its message queue. If the thread does not service the queue by calling GetMessage(), messages are not processed, and the window hangs: it can neither redraw nor can it accept input from the user. The operating system detects this state by attaching a timer to pending messages in the message queue. If a message has not been retrieved within 5 seconds, the DWM declares the window to be hung. You can query this particular window state via the IsHungAppWindow() API.
Detection is only the first step. At this point, the user still cannot even terminate the application - clicking the X (Close) button would result in a WM_CLOSE message, which would be stuck in the message queue just like any other message. The Desktop Window Manager assists by seamlessly hiding and then replacing the hung window with a 'ghost' copy displaying a bitmap of the original window's previous client area (and adding "Not Responding" to the title bar). As long as the original window's thread does not retrieve messages, the DWM manages both windows simultaneously, but allows the user to interact only with the ghost copy. Using this ghost window, the user can only move, minimize, and - most importantly - close the unresponsive application, but not change its internal state.
A nice article is written in this following link.
How program window works
I understand that Chrome using re-parenting in order to have child plugins such as Flash render from different processes.
I have experimented with this, and I have got it working using the SetParent Win32 call.
However, when I force the child GUI thread to block, the parent process will also hang as soon as the mouse moves over a the window area owned by the child process. Presumably this is because the message loop in the parent application is calling down to the child and it never responds. How does Chrome get around this?
Flash uses the re-parenting trick. It has its own .exe and renders to its own window. That doesn't prevent hangs, any message that is sent from that window to its owner is going to block when the owner isn't pumping messages. As you found out.
Browsers uses a different trick. They create an invisible helper process for each tab and render to a memory device context. And blits the result to their desktop window. Any input messages are shuttled back to that process. That makes them immune from crashes and hangs in that process, killing that helper process keeps the browser going. Much harder to do yourself.
I am doing a REALBasic project. I want to make code run after the window has loaded automatically.
If I put the code in the Open event handler, the code runs when the window opens, but the window doesn't appear until the code has finished executing.
So I would like to have the Window open and be on the screen, and then the code run automatically without having to click anything.
Is this possible?
Thanks.
Place your code in a Timer with its Mode set to ModeSingle and a short Period (say 10 milliseconds). The Timer will fire once the GUI finishes loading.
Or you can put your code in a thread and start the thread in the Window.Open event. That way if the code takes a while your entire application doesn't 'freeze' on you.
More info on threads in Real Studio at http://docs.realsoftware.com/index.php/Thread
One word of caution though with Threads. Directly updating GUI controls can be a bad thing - especially with Cocoa built applications.
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.
I'm developing an app and I'd like to trigger functions in my app via keystroke combos when it's not in focus.
Because I'm developing my app in AIR, I do not have access to listen to global Keystrokes. However, I can receive STDOUT from an application. So, I'm looking for a utility that can give me this ability. I'm looking for both Windows and OSX (cross-platform baby!)
For Windows, you could write a simple application that installs a keyboard hook and prints information about the key event to stdout. See SetWindowsHookEx.
For Windows:
I don't know of any app off the top of my head, but here are some ideas that might work within 100 lines of code...
I would avoid SetWindowsHook, as that would inject your code into all apps. (Because I've spent good time debugging crash dumps and bugs as a result of poorly written hooks...)
You could write a console app with DirectInput (old gaming keyboard API). I believe you just pass DISCL_BACKGROUND and DISCL_NONEXCLUSIVE into IDirectInputDevice8::SetCooperativeLevel call. Use IDirectInputDevice8::SetEventNotification to set the event handle so you don't have get into a busy wait loop polling for input. And that should do it. I did this once for my app a long time ago on Windows 98 and it worked really well. But DirectInput is very close to being deprecated technology so YMMV.
Another simple hacked up way to do what you are doing is to have your app create a hidden window, call call RegisterHotkey for all the keyboard, and pump window messages. Your wndproc will get a WM_HOTKEY window message that you can use that to generate a message to stdout.
The simplest way, but will be slightly error prone and cpu-expensive is to have your console app get into a loop and call GetKeyboardState. This will return the entire state of the keyboard of all keys that are up and down. You'll have to figure out how translate each poll into a logical keystroke. I'd recommend sleeping a few milliseconds between polls so you don't kill system-wide performance.
Can't help you on OSX.
For windows, here is a utility that will listen to the keyboard.
http://www.dynamicnetservices.com/~will/academic/textinput/keycapture/