Get hidden IvideoWindow Image - c#

i need to get Image of hidden IvideoWindow ("ActiveMovie Window"), which shows webcam preview. As far as i can tell preview isn't overlay, it doesn't have overlay features, i can use printscreen on it, but i need window to stay hidden all the time, so that won't help. Also PrintWindow() api function returns me black screen.
Programming languages: c#, c, c++, java, pascal.
Operating system: Windows XP.
Any ideas?

The trick is to show the window but outside the desktop. Set the left position at the desktop.width+1 (not screen.width, because users may have multiple screens) and then make it visible.
That way normal functions like printscreen work and users still won't see it.

Related

Prevent screen capturing softwares to capture an application screen

I am working on examination system, as a security part of the system I don't want anyone should leak the paper by screen recording or by giving remote using so many free applications for desktop sharing.
First I searched for can I block such applications? But I don't think so, as there so many ways to record/share a screen. Then I got to know about HDCP but I guess it will only application to videos and not to HTML (correct me if I am wrong). SO I want something like HDCP or VLC player's "directx video output" so that content doesn't get captured by printscreen or other screen capture techniques.
I guess D3D9/DDraw overlays are only for video content can I use this for HTML content/in a c# based windows application?
I have achieved this by using SetWindowDisplayAffinity, as per MSDN
The display affinity setting. This setting specifies where the window's contents are can be displayed. Set this value to WDA_MONITOR to display the window's contents only on a monitor. Set this value to WDA_NONE to remove the monitor-only affinity.
So setting WDA_MONITOR to handle of WinForm makes it black when print screen or desktop recording or in desktop sharing application.
Image captured through mobile:
However, I am open for any other (better) answer for this.

Windows 8 and C#: what technology is needed to move windows programatically, even in the z direction?

I'm interested in begin able to manipulate windows programmatically. Perhaps by clicking on a window so it has focus, then by using some key combination, I can move the windows. Also, I'd like to move the windows in the z-direction, which would mean that it would appear to get smaller as it went deeper into the screen and bigger as it was moved toward me.
I would like this to apply to any existing window, being a text editor window, a browser window, or even the calculator program window.
The problem is that I have no idea what technology would be needed to accomplish that.
Any ideas?
You'd need to use the Win32 API (using P/Invoke).
"Manipulating" a window would need several different API functions depending on what you want to do... these are a few:
FindWindow (pinvoke.net link) will allow you to find the window handle so you feed it into the other functions (there are more ways to find a window handle depending on your needs, but this one is by far the easiest)
MoveWindow(pinvoke.net link) allows you to set position and size
SetWindowPos (pinvoke.net link) to set the z-order of top-level windows
etc.
Use http://pinvoke.net to find out how to call Win32 API functions from c#, and use the MSDN (this link: http://msdn.microsoft.com/en-us/library/windows/desktop/ff468919(v=vs.85).aspx in particular) for a reference of all functions to handle Windows.
Update
Rereading your question it looks like you want to "simulate" a 3D-like effect in your windows. This is not in the API and there's no standarized way to do it as far as I know (the modern accelerated DWM does it, but I don't think you can access any functions to do that via its API).
You could research into capturing the window contents to a bitmap, and render that bitmap scaled into your own window. It's not impossible, but it's not precisely easy and would be WAY too long to explain how to do this here.
Update 2
There's actually a DWM API (link to MSDN), but even with it, I doubt you can do what you want in a practical manner with it

Non-Square Icon on Windows Form?

Is it possible to display an icon in the top left corner of a Windows Form that is a different shape than the standard 16X16 pixel icon?
It appears that Skype has an icon that is much wider than standard:
Is it possible in a Windows Forms app?
You can do this but it's probably more effort than it's worth just to have a larger icon.
Hans has posted an article that roughly points to the information needed to figure out an answer this question, but hasn't posted an answer itself and so I'll clarify.
The old (pre Vista) way to do this is to override the WndProc method on your form and handle the WM_NCPAINT message. Note that this means that you are now responsible for drawing the entire window frame (the window border, title, close / restore icons etc...), not just the icon - i.e. this is a lot of effort to do a relatively minor thing.
The newer (post Vista) way to do this is to use the DWM API - note that this API is not directly exposed through the .Net Framework and so you need to use P/Invoke for this in C#. The bit that you want to do is the section titled "Drawing in the Extended Frame Window", where you extend the area that you are responsible for drawing outside of the normal client area and into the window frame. This is less hassle than it used to be (you don't have to draw things like the close buttons), however still means that you take responsibility for a lot of things that you wouldn't normally, like hit-box testing for resizing and moving.
Basically its nowhere near as simple as providing a larger icon and for most applications its probably way more effort than its worth, however you can do this in C# and that article should get you started if you really want to give it a try.
I know your looking for a plain code way to do this, but I invite you to check out DevExpress manged (yes it's third party forgive me), just google it.. I seen this thread and I started asking questions at devexpress with support and got some impressive results that you might be interested in.
Here is the ticket I put in... http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q399941
Here is the result... http://www.devexpress.com/Support/Center/GetSCAttachment.ashx?id=684270b5-faed-415e-9010-64338523f8cf
So Far I used this on Xp, Vista and Windows 7 without problems using winforms only.
I hope this helps or gives you another option if the windows API don't pan out like you want on different versions of windows.
Thanks,
David
Don't think it's an icon, if you mean precisely the ICO image format.
Considering the Skype window is definitely ownerdraw window, that image can potentially be whatever you want format.
The trick is, basically, render an image skipping the pixels of some color (background color) of the "icon", so render it in "transparency".
This article can give you a hint:
Drawing Transparent Images and Shapes using Alpha Blending
It's old, but always a good one.
Yes. Override WndProc and implement WM_NCPAINT.

C# drawing disappears (actually more system question)

OK, I am sure some of you already know whats happening just by my title, since I get this is very common question. But my question is in fact little deeper, so please be patient wíth me.
All my programing I have done in past years were in Assembler, mainly 8051 and AVR as weel as in C, but also for microcontrollers. I was more fascinated by HW than SW. But I am also fascinated with function of OS, its APIs and so on. Few days later I told my friend that to create a very simple program to plot a function graph should be very easy, if you had math parser. He doesent believed me so I tried to make one.
I decided to go with C#, even I have no knowledge of OOP. But I thought that if I get everything done in one buttons action it would be like good old C.
So I get math parser to work, and than started to draw using Pen object. My first attempt was to draw simple line. After reading one tutorial a managed to do so, and I created simple axis for my plot.
But than I noticed something strange, when I minimalised my program, drawing dissapears. This made me think a bit about how this all drawing is done on system level.
I thought that system hold image of active window untill its changed. So when you move your windows it just changes its position in famebuffer. And when you minimase it, it just skips it during drawind to framebuffer.
But I saw its not like this. So, please, could you tell me why is this happening? I can read how to prevent it in many tutorials, but I would want to know more why. More, wheather this is becouse of how system API works, or becouse how C# drawing class works.
Also, this made me think what in C# and .NET libraries is function thats just a call for WinAPI function that works exactly the same way, and how many libraries and function do something more. Like if there was no function to draw line in GDI, and you could only draw dot, than C# would add function to draw line from this dots. I hope you understand me.
Thank you.
This is how it works in the Win32 API. When the window is minimized, the area which it occupied gets "invalidated" so the windows system knows that this area of the screen needs to be redrawn. This leads to a WM_PAINT message being sent to the windows program(s) responsible of drawing that area. You can read more about invalidating the client area (the area of which your program is responsible) here.
If you're truly interested in this stuff and want to get deeper understanding on how the system handles drawing (and other things, like windows messages), I recommend reading more on the Win32 API, e.g. beginning on Charles Petzold's classic, Programming Windows.
Your drawing didn't disappear, it simply isn't there. Bear with me:
to draw on the windows window, you have to respond to the callback indicated by the WM_PAINT message. It was in Win 3.11 and it is so NOW.
to draw on button click is a waste of time, because next form/control/window repainting will draw background color there
move the same code from button event handler to OnPaint - of course, handle the differences in semantics
windows don't save the copy of your screen buffer - your drawing - so you have to save it somewhere or draw it on-the-fly
In Windows (prior to Vista / DWM and MIL) the application is responsible for drawing its own GUI. That is, the application has to paint its own GUI When the operating system tells the application to do so. Resizing or moving a form will trigger the paint event. This is how it works in User32+GDI. That is, the application draws its own pixels.
A WPF application will however use the Media Integration Layer (Vista and Windows 7) and the "mil core" is responsible for drawing the visual tree of the application. In this case the operating system is responsible for the rendering, but the application is responsbile for what it wants to be rendered.
If you want to plot, use microsoft chart controls.
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=130F7986-BF49-4FE5-9CA8-910AE6EA442C&displaylang=en
or ZedGraph
http://zedgraph.org/
If you want to plot yourself: The window is redrawn when you resize.
You need to redraw your plot on the redraw event, or whatever it is called.
That is perfectly normal.
Also, use .NET 4.0, because else, you have no possibility of removing anything you drawed programatically, unless you remove (repaint) everything.

DirectX Desktop

I'd like to make an animated desktop background for Windows 7 using DirectX. I'm using C#, SlimDX and a couple of P/Invoke imports of Windows API functions. I'm not brilliant with native Windows programming, but I've had a poke around online and I believe what I need to do is either:
1) Find the handle of the window containing the dekstop wallpaper, hook it up to a DirectX device and draw into it.
2) Make a new output window, and insert it above the desktop wallpaper but below the desktop icons.
I've tried both these, but neither seems to work. If I navigate the Window heirarchy starting from the handle returned by GetDesktopWindow(), I can go Desktop -> WorkerW -> SHELLDLL_DefView -> SysListView32. If I hook up a DirectX device to this handle, I can draw over the entire desktop, but it also covers the icons. If I create a Windows form, set its parent to SHELLDLL_DefView using SetParent() and then use SetWindowPos to play with its Z-order I can only seem to get it to go either behind the desktop wallpaper or in front of the desktop + icons.
It looks as though the desktop wallpaper is background to the folder view containing the icons, and therefore what I am trying to do cannot work. The only solution then would be to not use the desktop for icons, or to find some alternative, e.g. overwriting the desktop then overlaying a transparent window containing a view of the contents of some folder.
Does anyone have any idea of what I should be doing, or even whether what I want to do is possible? It seems you can draw to the desktop background using the GDI (as I believe the wxSnow program does), and I've seen something similar to what I want done by VLC Media Player under Windows XP with its DirectX wallpaper mode (interestingly, I can't seem to get this option enabled on my system).
Thanks!
Looks like this might not be possible. See this link:
http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/69839cec-3424-4300-9ac3-486b8c2fe492
If you need to draw some controls
between the desktop background and
desktop icons, an alternative step is
below:
Create your user control in a windows control library.
Embed the user control in an ActiveX control.
Embed the ActiveX control in a web page.
Enable active desktop and set the web page to be your desktop
background.
This can only be done in XP since
Vista doesn’t support active desktop.
Another post there suggests that you could possibly do this with the background of an explorer window - if you could get the handle of the window that constitutes it. Of course, if that's possible then it may be possible also to get the handle of the desktop window behind the icons.
Update: Well, so far the only thing I've found that could possibly "work" is just creating Bitmap files and changing the wallpaper over and over again (I suspect this would be slow, as you mentioned).
That full screen image must be resident in memory somewhere, but there may be no way to access it without some serious low-level memory hacking. I'm going to keep looking.
Update 2: This might work, but I'm not sure:
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/4af734fb-d2c1-414b-a9f1-759b76692802
The meat of it is this:
HWND p = FindWindow("ProgMan", NULL);
HWND s = FindWindowEx(p, NULL, "SHELLDLL_DefView", NULL);
HWND dtw = FindWindowEx(s, NULL, "SysListView32", NULL);
HDC hdc = GetDC(dtw);
You're basically starting with the ProgMan window and drilling down from there to the desktop wallpaper ("SysListView32", I guess). I'm going to try this out.
Update 3: No go - the above code does get the desktop's DC, but it's above the icons so BitBlt draws over them. It's not drawing to the Screen, though, because I can draw underneath an open form without covering it, so that's progress at least.
I'm guessing that there's some window available other than "SysListView32" that is the desktop behind the icons, or there's more than one "SysListView32" window.
Update 4: I'm pretty sure something using this would work:
http://msdn.microsoft.com/en-us/library/bb761155(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb774742(v=VS.85).aspx
Basically, it's an API method that you call, passing in a structure which include a bitmap handle. If the call is successful, that bitmap becomes the desktop.
Does DirectX expose frames as bitmap handles (GDI-compatible), or does it only expose the DC? In my case, my animation is already an array of GDI-compatible bitmaps, so I would have no trouble using this approach. If this is the only route, and DirectX doesn't expose the bitmap handles (and I don't think they would), then for each frame you would have to create a new GDI bitmap, which would slow things down quite a bit.
Actually, there might be an easier way, although I'm not sure it would work. Once you get the handle to the actual bitmap of the wallpaper, you can select it into a device context using SelectObject, and then just use that device context as the BitBlt destination. You might have to send a repaint instruction to the desktop, though, which might trigger the icons to be repainted every time.
How about you do some work here? :)
I guess you could get quite a few frames per second by dynamically generating bitmaps and constantly setting these as the desktop background. However, this sounds unnecessarily (almost stupidly) heavy for the CPU. Update: Now that I think about it (it was late when I wrote this), the main problem with such an approach is that you need to write and read bitmaps from the hard drive every time a new frame is to be displayed. This is not feasible.
Are you really using the desktop for icons? In Windows 7 the start menu search function and the new taskbar has made me not use the desktop for icons.
Just an idea
It might be possible to alter the desktop window, by means of SendMessage(GetDesktopWindow, WM_SOME_MESSAGE, wParam, lParam), so that you can achieve what you want. I might investigate this further tomorrow (currently 3 am, local time).
I've done some animation of alpha blended windows that are always on the top of the Z-Order. One idea would be to ignore trying to modify the desktop bitmap and just draw your stuff as a layered window but manage the ZOrder somehow so it is always the bottom-most, non-desktop window (perhaps by strategically calling Form.SendToBack() or something at the right times).
Depending on what you are trying to do this may give you the same effect of animating the desktop.

Categories

Resources