Is there a way to prevent or disable video capturing of my WPF application? Probably some Win32 API calls or some mask over my WPF content. Or if it is imposible is there a way to at least prevent the most popular screen capture programs from recording what is happening in my WPF application?
To prevent an application from capturing window contents, you can call the SetWindowDisplayAffinity Windows API with a WDA_MONITOR affinity. While this prevents applications from capturing a screen, it will not prevent a user from whipping out their smart phone and taking a picture of the screen.
The API is available on systems running Windows 7 and later. It's also required that Desktop Window Manager composition is enabled. Turning off DWM composition will undo the effect, so you need to prevent users from turning DWM composition off. If you are running Windows 8 and later, this is not an issue, since Desktop Window Manager is always on.
Related
I'm trying to create a WPF application that makes a Skype video call with the use of Kinect gestures (Kinect SDK v2.0). I want to use the Kinect color camera in the video call, while still be able to use Kinect in my WPF application to detect the "hung up" gesture. Is there a way to do this? While the Skype video call is active, I don't really need Kinects color stream in my WPF application. I just need the Body stream to detect the gestures. I'm using the Kinect for Xbox One.
Sure. It works out of the box like that.
The SDK 2.0 is designed specifically to enable "simultaneous multi-app support":
Improved multi-app support enables multiple applications to access a
single sensor simultaneously. - Developing with Kinect: Simultaneous multi-app support (on the very bottom)
There isn't anything special you have to consider. Since the SDK doesn't allow you to change any camera settings (like exposure time or gain), your applications basically just have read-access to the SDK, so they can't interfere with each other.
Just develop you applications separately and run them at the same time.
I`ve a legacy winform desktop app that works perfectly with mouse and keyboard. It has some selfmade controls that involve the creation of threads and so on, for example the longer a button is pushed the faster a number is incremented.
The application also uses a win32 dll. Now, the client wants that application to be touch enabled and run it in a tablet, which also means resizing and rotation capabilities.
My question is, which is the better way to get that application touch enabled and responsive design?
I can try to modify the existing winform, but I think it will be lot of work with poor results. I can also migrate to WPF and reuse the c# code, but I might have trouble with the keyboard, as I have not found a good way to show the keyboard and maintain the whole app on the screen. Or I can migrate to windows store app, but with the problem of that win32 dll, that I`m not sure it could be migrated.
The winform application is multilingual so creating a keyboard is not a valid option.
If the target is touch screen, then for sure the best option would be a Windows Store App, although there are several limitations.
If you are not going to publish this application in Windows Store, then you should be able to use all WinAPI functions. (I'm not sure what is win32.dll - if it's your own dll then it can be a problem).
I'm building a Silverlight Out Of Browswer Application with Elevated Permissions and need the ability to basically have the application listen for a keyboard shortcut such as doing something like Ctrl + F10 will cause a window to take focus of the screen... Personally I am against stealing focus but feel that this is alright seeing as the user invokes it themselves.
So more background... if any of you are familiar with applications like XFire or Steam.. I'd like to the ability to do a keyboard shortcut and have a window open above all the other applications like Steam can with the in-game windows.
If Silverlight can't do this can someone point me towards a better language where I can create this sort of application?
If Silverlight can do this can someone point me in the direction of how to accomplish this?
Silverlight 4 can't do this and Silverlight is not a "Language". Any application developement platform (JAVA, Delphi, VB6, .NET) that has full access to the windows API could do it.
Silverlight 5 includes support for PInvoke so if your willing to wait for the RC to go to RTM then you may be able to hook the system level WinAPIs needed to watch for a hotkey.
I am trying to create a multitouch application.
I have the hardware which will allow me to do this. On the software side I want to be able to have WPF textboxes, WPF web browsers, multiple focuses, multiple keyboards and multiple users at the same time.
From what I've seen, I can't be focused on two controls at the same time.
What is the Microsoft MultiTouch approach for this kind of job ?
The OS limitations are what they are (and don't appear to change in Win8): only one hWnd at a time can have focus.
Since you are using WPF though, everything within your application (with the exception of the WebBrowser control ActiveX widgets you may be using) is rendered within one big hWnd.
WPF 4 introduced native support for multitouch, including multi-touch capture. The APIs for this are many but pretty intuitive so I'll just say this... go to http://msdn.microsoft.com/en-us/library/ms590078.aspx and search within the page for all of the members with "Touch" in their name.
The catch however is that the controls shipping with WPF 4 don't work with the touch input events... you'll only be able to interact with one of those controls at a time. To take advantage of the multi-touch capture APIs, you'll have to create controls that are designed with it in mind. Fortunately, the Surface team at Microsoft has you covered on that... the "Surface 2.0 SDK" includes a suite of controls (usable on any Win7 machine, not just for Surface) that were built with this stuff in mind.
To create application with MultiTouch UI, use MultiTouch Framework in .Net
Go to http://multitouchvista.codeplex.com/
I am working on a Silverlight 4 out of browser (OOB) application on a Windows 7 tablet PC. The majority of the time, the program is in full screen mode. However, if the user rotates the tablet, the application rotates and stays full screen, but is scaled for the previous screen orientation. Taking the application out of full screen and putting it back into full screen rescales everything correctly. Is there any way I can detect when the screen rotates? So far I've tried the app's Resize, LayoutChanged and FullScreenChanged events and have a handler for the main page's SizeChanged event. None of these get fired when the application is rotated in full screen mode.
Per Josh Einstein's suggestion, I tried polling the ActualWidth/Height of the application on a timer. It looks like after the rotation, the ActualWidth/Height values returned from the Silverlight plug-in are the pre-rotated values. Only taking it out of full screen and putting it back in full screen will change the resolution of the plug-in. The HtmlPage.Eval hack didn't work since I am OOB.
The WP7 version of Silverlight has the OnOrientationChanged event, which doesn't seem to be available in the desktop version. Anyone have any ideas?
Great question but as far as I can tell, it doesn't seem to be possible. I tried changing the screen resolution in a virtual machine (orientation change is really just a screen resolution change that results in width being larger than height or vice versa) and could not trigger any layout events.
The issue seems to be that the Silverlight plugin itself is not resized. With an elevated out-of-browser application you could presumably use COM interop with WMI to get the actual screen resolution, but it's kind of hacky. If it's an in-browser application, you could use the HTML DOM. In both cases, you'll probably have to poll for the current screen resolution instead of being notified via an event.
Mister Goodcat has written a blog post about how to get at this information in both scenarios.
I would file it as a Silverlight bug too.