Capturing GUI Screen of Child

This is my current problem:
I have a service which starts console app's just fine (in the
background)
NOW, I want to add gui applications.
a) can i prevent a gui app to appear on the screen ?
b) can i capture the gui of the child and send it somewhere
where it can be assembled again (e.g via sockets)?
c) how can i interact with the hidden gui (send mouse clicks to it, etc)
where do i have to look at (msdn references, www pages ...)
thanks !
boyracerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nietodCommented:
You might try positioning the window of the GUI app  off display (beyond the edges of the display).  Then you can get the image on the GUI app window by sending it WM_PRINT or WM_PRINTCLIENT messages.
0
nietodCommented:
To "interact" with the GUI window, you woudl just send in mouse mewssages (WM_LBUTTONDOWN etc.) and keyboard messages WM_CHAR etc.)
0
jkrCommented:
>>can i prevent a gui app to appear on the screen ?

On NT: yes
Win9x: no

The 'SW_HIDE' flag passed in the STARTUPINFO struct used in the call to 'CreateProcess()' or 'ShellExecute()' may be ignored by the created process. On NT, you could start the application on an invisible desktop.
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

tonpCommented:
I'm assuming that you're talking about a Windows environment.

a) yes. Using the CreateProcess call you can specify that the window must not be shown (STARTF_USESHOWWINDOW).

b) yes. Hook all relevant GDI functions, and for each call determine if it's done in the context of the application you started. If so, send it over the network and don't call the actual GDI function.

c) Use keybd_event and mouse_event.

Obviously, the tricky part is the capturing of the gdi calls. In your case it's perhaps an option to implement your own GDI32.dll, cantaining wrappers for all GDI functions. Rename the original gdi32.dll and call the functions from this dll.

Ton
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jkrCommented:
>>Using the CreateProcess call you can specify that the
>>window must not be shown

That's incorrect. As I stated above, the started application can ignore this value.

>>Hook all relevant GDI functions, and for each call
>>determine if it's done in the context of the application
>>you started.

When you've chosen to hide a process and it does not ignore this flag, what GDI activities do you expect to take place? ;-)
0
tonpCommented:
JKR is right. This entire part (hiding the window) can be skipped (instead, the window _must_ be showed, either directly at startup or by doing a ShowWindow later).
Because of the GDI stubs (that filter out all activity for this application) nothing will show up anyway.

Ton
0
boyracerAuthor Commented:
hm,
i do not want to hook functions.
jkr's proposal of an invisible desktop seems better
if i still can capture the gui.
FYI: i am trying to implement something like VNC,
however i only want a single application to be
viewn
0
tonpCommented:

I _think_ that when the application is not visible (moved outside the desktop or placed in an invisible desktop) it will receive no screen updates and/or drawing actions will fail (that makes sense anyway). Therefore it will never draw itself and you can't do what you want.

When you don't want to hook GDI functions, a different approach is the following:
 
- monitor updates by setting keyboard, mouse and messages hooks (for example, when the hook detects that a WM_PAINT messages is sent to the application you know that an update will take place)
- grab the application screen (bitblt it into a bitmap) and send the graphical data over the network.

Ton

0
nietodCommented:
>>  _think_ that when the application is not visible (moved
>> outside the desktop or placed in an invisible desktop) it
>> will receive no screen updates and/or drawing actions
>> will fail
No, only the OS will not draw it automatically (won't send it WM_PAINT messages).  Which is good, because you don't want it to!

Then you can obtain the program's current appearance using WM_PRINT.

>> when the hook detects that a WM_PAINT messages
>> is sent to the application you know that an update will
>> take place) - grab the application screen (bitblt it into
>> a bitmap) and send the graphical data over the network.
But the application must not be visible on the computer that is running it!  so the screen doesn't contain the image you want to send.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.