If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

[RESOLVED] Capture a window

Is there any way of capturing an existing window to a bitmap or at least finding it's size and position on screen. It has to be quick by clicking or hovering the mouse over the window (as in screen capture software.) I think I saw a post some time back but can't find it now...! Think it might have been something in Marshall class or maybe Bitmap but can't see anything obvious there - probably staring me in the face
Thanks.

Re: Capture a window

Like any Windows Forms control, Form features the DrawToBitmap() method that does just what the name suggests and may be useful for you. However, I have never used it on an entire form so I'm not sure whether it also renders the non-client area along with the form contents. Also, it only can be used easily if you want to capture a form owned by the very program that does the capture because of course you need to access the Form derivate instance in order to use it.

And there's Graphics::CopyFromScreen() which can capture an arbitrary rectangular screen area. This can be useful if you want to capture your own form including the non-client area and Form::DrawToBitmap() doesn't do that. But if you intend to capture arbitrary windows not necessarily owned by your program, including Windows owned by non-.NET apps, things get somewhat more complicated. I don't think Windows Forms can do that on it's own, so you'll probably need at least a bit of Win32 API magic to determine the window under the cursor.

Last edited by Eri523; February 26th, 2013 at 03:31 PM.

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

Re: Capture a window

Thanks Eri523.
Sorry I should have made it clearer that by existing window what I meant to say was one pre-existing i.e. not owned by my program. NB Paintshop Pro screen capture can select a range of options including screen, client area and window so I know it "can" be done but I guessed it wouldn't be easy. I'm pretty new to VC and am clueless about Win32 API - any pointers?
The objective BTW is to locate a star's position in an astronomical image displayed in "real-time" by commercial software. The star is centered using telescope controls then mapped to calibrate the drives. Unfortunately the software designer's omitted to include a crosshair or graticule overlay so I need to create some sort of transparent overlay which will automatically locate itself in the image window. That will be another thread I imagine.

Re: Capture a window

To determine the window under the mouse cursor, WindowFromPoint() may be a good place to start researching. Once you got the handle of the subject window, GetWindowRect() will retrieve its screen bounds. All that may be more tricky than it looks like initially, though, for instance because WindowFromPoint() may not instantly get you the handle of the window you're actually interested in. In general, it's probably the Win32 window functions you're primarily interested in. Admittedly, much of that is terra incognita to me as well, in particular when it comes to using it in conjunction with .NET.

I somehow was hoping the .NET NativeWindow class could be helpful in creating a .NET wrapper around a Win32 window handle so you'd be walking on a more familiar terrain, but it looks like that only works for windows your app creates itself.

The rest will be, well, at least one more thread. In particular the image segmentation needed to isolate one particular star on a sky shot bitmap may be another thing that's more tricky than you think.

Sorry for not having better news for you...

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

Re: Capture a window

So how do I use the Win32 functions? A quick try revealed I need to include windows.h where HWND and HANDLE are defined but that throws errors in the standard library files presumably because /clr is enabled. Simply switching off clr throws more errors even on a new project since VC2010 IDE still creates reference types which need clr... Thinks I need to start learning non - .net programming! My guess is I need to add a win32 project maybe dll or lib and link it to my project so I will need to find how to do those things.

BTW the rest of the stuff is not difficult. Once I have a bitmap copy of the image window I can easily place a graticule over it and then it's simply a matter of moving the telescope with the manual controls to centre the star It needs to be quick and automatically updated though. ( that's why I can't use the app's Save function) An alternative would be if I could create a movable graticule by means of a transparent form with a scalable X or + drawn on it but I've not been able to do this either

Re: Capture a window

Originally Posted by RogerD

So how do I use the Win32 functions? A quick try revealed I need to include windows.h where HWND and HANDLE are defined but that throws errors in the standard library files presumably because /clr is enabled. [...]

Where did you include <windows.h> and what was the error message you got? I did that quite a few times im C++/CLI projects and got it to work each time.

[...] Simply switching off clr throws more errors even on a new project since VC2010 IDE still creates reference types which need clr... [...]

That's not really an option I think since what you want to build is a Windows Forms app, isn't it?

[...] My guess is I need to add a win32 project maybe dll or lib and link it to my project so I will need to find how to do those things.

I don't think that's really needed, and in fact it may even raise some extra problems as can be seen in another recent thread.

[...] An alternative would be if I could create a movable graticule by means of a transparent form with a scalable X or + drawn on it but I've not been able to do this either

Attached is a demo project that creates a draggable (though not yet scalable) crosshair:

(Note: As the usual window state controls aren't reachable in the demo, it can only be closed using the context menu of its task bar entry or by hitting Alt+F4 when it's focused, i.e. after dragging it.)

Neither the form's Opacity property does the trick (it applies a flat transparency to the entire form including anything that's displayed on it), nor does a partially transparent crosshair bitmap displayed on the form (it merely lets the form's background shine through, not what's behind the form). What does work is setting up the form's Region property to constrain the actual area taken up by the form on the screen, where the resulting area can practically assume any shape.

Re: Capture a window

Thanks for that - the demo is almost perfect as it is - even the right colour!
I have adapted it slightly and using your example discovered the GraphicsPath class which should be more efficient. The problem is it's difficult getting it to create single pixel diagonal lines especially on non-45 degree co-ords which is what I need. WIP.

I have yet to re-create the Windows.h problem although I have discovered this in another of your examples (BringMeUp.) The syntax seems pretty obscure to me!

Re: Capture a window

My choice of color was based on the assumption that few apps have windows containing large red areas, so the crosshair would almost always remain clearly visible.

The problem is it's difficult getting it to create single pixel diagonal lines especially on non-45 degree co-ords which is what I need.

Do you mean when drawing the path or when constructing a region from it? If it's about drawing, turning off anti-aliasing may help.

Avoiding problems of that kind was my reason to use a pre-painted bitmap in the crosshair demo instead of having the demo itself draw the crosshair. This approach becomes impractical, though, if you want the crosshair to be freely sizable.

In one of my apps I use a path-based form region which is strictly circular, and even that was slightly problematic until I changed the bitmap background making up the static content of the form into a metafile that I pre-render into a background bitmap upon form size changes. (IIRC it was possible to simply set up the metafile as the background as well; the pre-rendering is a cache thing meant to reduce CPU load created by repainting.)

[...] The syntax seems pretty obscure to me!

Code:

#pragma comment(lib, "user32.lib")

This is just an equivalent to adding user32.lib to the additional dependencies in the linker input project properties. I prefer it that way in code intended for forum posts, since it's much shorter than explaining that this dependency needs to be added in case someone wants to compile my code separately from the provided demo project.

Last edited by Eri523; March 7th, 2013 at 06:00 PM.

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

Re: Capture a window

Next step will most probably be implementing picking up information about the window under the crosshair using native Win32 API functions.

Ok, so here we go... (The new demo project supercedes the one from post #6, so I removed that.)

The new version features a tool tip displaying some information about the window targetted by the crosshair. Here are the relevant changed/added parts of the main form implementation file (but that's not the really thrilling stuff):

The Win32 interop is encapsulated in the class Win32, which, unlike WndMessageHolder from the BringUpTest demo project you already referred to yourself, is an entirely stateless static-methods-only class, so there's no point in instantiating it. Another difference is that the Win32 API is encapsulated completely, so the client code doesn't need to #include <Windows.h> (nor does Win32.h contain that #include), preventing potential name conflicts.

Re: Capture a window

You have practically written the whole thing for me! Just left the bit that gets the window size and repo's to the centre of it (NO I'm not hinting you should have done that also - leave me something to do for myself!) So profuse thanks for your help once more.
Added this method to Win32:-

This works well but if the target app/window is moved the crosshair stays put until "nudged". Is there any way of getting a callback/notification of the move so it can track the moves?
NB *Long* time since I did this native stuff in my Windows programming course (early 90's and Windows 3.11!) so very deja-vu. Would appreciate any constructive crits.

From a quick look (only just downloaded the demo early hours this a.m.) there are some really valuable principles there worthy of study in detail - especially the win32 encapsulation. Some time back when I was converting some old apps (from Borland builder) I had used the user32.lib stuff mixed in with the new code and of course got loads of messages about switching between managed and unmanaged code so quickly forgot about doing anything like that in new projects. This demo looks to have solved that issue so I need to re-visit them but the question remains how do you know when you have exhausted the search for a managed solution and use win32 libs?

Re: Capture a window

@Eri523: Nice work!

@OP:
About that last question: well, generally, you try to find a way to do it using framework library, hoping that the specific functionality is exposed in some way. If you can't find anything that suits your needs, then you consider other options. For example, there might be open source (even cross-platform) libraries that are of a good quality and can solve your problem nicely, or there could be commercial solutions, if that's an option. If you aren't interested in those, or simply can't find what you're looking for, you have to turn to native libraries. You can then try PInvoke, or write a wrapper in C++/CLI, or choose to write an entirely native app.

@Eri523:
About the NativeWindow class - I didn't really try it out, but why do you think it won't work with a preexisting native window? Based on the existence of this method, it appears to me that it could accept any window handle?

Re: Capture a window

Originally Posted by RogerD

You have practically written the whole thing for me! Just left the bit that gets the window size and repo's to the centre of it (NO I'm not hinting you should have done that also - leave me something to do for myself!) So profuse thanks for your help once more.

Originally Posted by TheGreatCthulhu

@Eri523: Nice work!

Yo, thanks!

Originally Posted by RogerD

This works well but if the target app/window is moved the crosshair stays put until "nudged". Is there any way of getting a callback/notification of the move so it can track the moves?

I think it's well possible to automate that, but it would require hooking the subject window's messages, which is rather advanced even in a pure native environment.

[...] but the question remains how do you know when you have exhausted the search for a managed solution and use win32 libs?

IMO that mainly - and simply - demands experience in working with the .NET framework, so you readily have an idea where to look for the things you want. And things aren't always where at least I would have expected them. My pet example of this is System::Diagnostics::Process: Although the class has plenty of diagnostic feaures, justifying to put it into that namespace, like me many developers probably spawn child processes mostly for non-diagnostic purposes, so I initially failed to look for it there. In fact it literally took me weeks to find it - by accident.

There also are a few cases where support for some features is implemented in framework classes where I wouldn't have expected them. That's probably even harder to find.

In fact there have been at least two or so cases in which I first implemented things in terms of Win32 API and then, after more or less time had passed, discovered that there actually is support for that feaure in the .NET framework.

Originally Posted by TheGreatCthulhu

@Eri523:
About the NativeWindow class - I didn't really try it out, but why do you think it won't work with a preexisting native window? Based on the existence of this method, it appears to me that it could accept any window handle?

When I initally read that paragraph of yours, I was seriously considering this may be the time for another "d'oh!" for overlooking something obvious. Then I followed your link and recalled that I actually had considered and inspected that method. The reason why I dropped it as a candidate was this Note in the Remarks section (and I was really disappointed when reading it):

Originally Posted by MSDN

The handle to assign cannot be in a different application process.

Phew...

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

Re: Capture a window

Oh, I didn't mean to say you overlooked something, I just didn't have time to take more than a quick look, so I missed that note; I was just interested in how you came to that conclusion. You'd think they'd put info like that somewhere on the main page for the class as well...

Re: Capture a window

Actually, I didn't perceive it that way. Chances are I'm my own sharpest critic, and I always suspect I may have done something silly unless I'm entirely convinced of the opposite.

[...] You'd think they'd put info like that somewhere on the main page for the class as well...

Yeah, d'accord. And I even found this one relatively clear since they stated that in the doc of the relevant method which more or less obviously is non-trivial. I've already seen important information like this not before I, mostly by accident, read the description of a method that, by it's name and one-line description in the table of methods, appeared so trivial that I probably would never have looked into the actual description page (don't remember why, actually, I still did).

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

The dynamically allocated rect is never released. Actually, there's no need to dynamically allocate it anyway. The reason why I dynamically allocated lpNativeText in Win32::GetWindowText_() was that I couldn'd know its size in advance, which is not the case with the fixed-size RECT structure. Here's a fixed version:

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.