How do you put a Windows Form Application on top off everything on your screen?
Just setting the topmost-property isn't enough when you're running fullscreen games.
If anyone has a solution for good old Forms i'll also be happy
I've seen many posts on this forum that say it's impossible but i know it's not couse i've seen alot of apps (fraps, teamspeak overlay, xfire, etc) that does this.
If you want to use a graphics library to display something always on screen, you may want to start here on SO. There are wrapper libraries available like OpenTK for OpenGL. If you want to go the DirectX route you'll need to load in the C++ libraries and access them using P/Invoke. There's a good tutorial to start with on msdn. Wrappers for DirectX also exist in the form of SharpDX.
Related
I am writing a C# Windows Form application which communicates with a webcam.
However, I want to tune webcam properties inside a button click function. Examples of those properties are brightness, saturation and sharpness.
I have found IAMVideoProcAmp::Set which might aid me with this. However, I don't quite understand how to implement this.
Can anyone help me in the right direction?
What you'll need to do is wrap calls to certain APIs (whether it's Windows, DirectX, etc) which is easier said than done when it comes to C#.
Luckily this problem has been solved numerous times (as you can see by number of webcam questions here) - and you can find one good approach in the following article:
Versatile WebCam C# library
Check out "How to change contrast and saturation programmatically?"
I'm wondering about that many new applications, I think most built in WPF, has this really cool Windows Aero Glass interfaces.
For example Seesmic or the upcoming Firefox 3.7
(source: crenk.com)
Searching in the internet most time it looks like you need a hack to realize this. But seriously: I don't think big software development teams use hacks to roll out their huge used products.
So my question is: Windows Aero Glass Areas - How to do?
Is it only possible with a hack?
Maybe it's just one property, i don't know. I'm WinForms developer so I never tested out WPF. But my Google search didn't look like It is easier with WPF.
To have Aero glass, you need to use the Desktop Window Manager. It is a Win32 DLL, so you need to P/Invoke it. Articles on how to do this are all over the Internet, ex. Link Using P/Invoke is definitely not a hack.
Windows API
So i know that the WinForms touches on the Windows API a little, but frankly its horrible. ESPECIALLY with the layered windows and flickering. So i was wondering if anyone has wrote partial, or full wrappers for the Windows API.Im particularly interested in the Layered Window aspect, but really any part of the API is a good place to start.
Update: I found the Windows API Code Pack here: http://code.msdn.microsoft.com/WindowsAPICodePack but it seems that it doesnt wrap Layered Windows? Am i correct in assuming this?
Native API (Windows)
Ive heard a little bit about the Native API, but im not quite sure what it is for? what features does it provide? would it be a good idea to look into?
Summary (Questions in a nutshell)
Does anyone know of an existing (partial or full) wrapper of the Windows API?
If the answer is no to question one, where would be a good resource to learn about it myself, and potentially write my own?
An explanation of the Native API? What does it do? Can I use it to make applications better? Can I even USE it at all?
An answer to any of those is highly appreciated :) thanks
You could start at PInvoke.NET.
The LayeredWindows actually work better in WinForms than windows.
The native windows controls don't even have the alpha channel support of the WinForms analogues, so native windows flicker, and require massive amounts of subclassing to override the painting to use alpha compatible routines.
You would be better off going to WPF. The windows team has not treated the native control's well at all, going so far as to remove support for a style (WS_EX_COMPOSITED) if aero glass is enabled which, given the way that windows controls paint, effectivly made it impossible for any application to paint flicker free if it uses child window's as controls.
WPF "draws" windows controls, but does not use discrete (native) child windows to represent individual controls. This gives it control over when and how its window surface is rendered.
The Windows API is huge. There is a ton of stuff in it. Windows Forms is a wrapper of parts of it. WPF is a wrapper of parts of it. Parts of the Base Class Libraries (eg System.IO.*) are wrappers of parts of it. The Code Pack is a wrapper specifically of things that were new in Vista and Windows 7 and not in Windows Forms or WPF.
Have you looked into WPF? Combined with P/Invoke of specific API functions, it might take you a long way towards where you want to be.
I am transitioning from WinForms/XNA to WPF/SlimDX because:
a) all of the benefits of WPF over
WinForms (but learning curve = ouch!)
b) I would like to have multiple
SlimDX viewports attached to Panels.
XNA has 1 "game" screen.
c, last and least) DirectX 10 support
All of my previous XNA code is in C#. I am having trouble figuring out how to port this over to SlimDX and WPF on a high level. I have searched like crazy. The closest I have found are:
1) http://www.gamedev.net/community/forums/topic.asp?topic_id=507941
Many articles point to this discussion, however it is incomplete and I can't figure out the XAML, and I get device errors after attaching all of the _slimDXDevice and Window1 events that were left out.
2) http://www.codeproject.com/KB/WPF/D3DImage.aspx
This article assumes the user is porting C++. I am porting XNA code which is very close to MDX code.
If I could get to the point where I have a WPF form with a custom SlimDX driven viewport that was just a blue box, I could go from there. In XNA I rendered many separate RenderTargets and placed them all over the screen, now I want to attach them to controls. But first, just 1 blue box! :D
Any ideas? I feel that this is either simple or that there's some "cookie cutter" code that I'm missing. Greatly appreciated!
You can look at the sample now. It's just been checked in to our repository, so you'll need to use SVN to get it (or wait until we ship the Feb 2010 release):
http://code.google.com/p/slimdx/source/detail?r=1356
D3DImage is the class you want to use. Even though the codeproject tutorial is C++, it is very applicable to SlimDX and WPF.
All you have to do with your SlimDX, is run your code normally, but DO NOT run a Present(...) on your device or swap chain. At the point where you would put a Present(...), do a D3DImage.SetBackBuffer(...) and send your SlimDX surface's ComPointer property to it. Then do D3DImage.AddDirect(...) and you now have D3D composited in WPF.
Also, make sure you create a IDirect3DDevice9Ex or else your performance will be terrible in anything but XP!
I recently was messing around with D3DImage and SlimDX and didn't find it too difficult to get it working (with DirextX9). I have some code at my home pc that I'll post later, but it's pretty similar to the code in the links provided.
I was never able to get it working with a higher version of directx though. Jeremiah has a nice blog post about using a directx9 device as a link between directx 10/11/d2d and the D3DImage, but I couldn't get it working with Slimdx. I didn't put a whole lot of effort into though as directx9 did what I needed it to do and I kind of wanted it to work on XP.
I am pretty new to DirectShow and really just feeling my way round at the moment. I am wanting to host the directshow renderer window of a directshow graph within a WPF app and am currently using the HwndHost class to try to achieve this. What I need though for HwndHost is a handle to the window which is rendering the video. I have found an example which shows getting the handle by enumerating the pins of an IVideoWindow interface and querying for IOverlay so the GetWindowHandle method can be used to get the handle.
Problem is IOverlay doesnt seem to be available in DirectShow.Net. Reading the DirectShow.Net About page, IOverlay is listed in the table with the heading "These interfaces are in the source code, but are deprecated, undocumented, intended for Ole Automation or otherwise untestable which means they are not, and will not be tested".
So what is it that I have to do to get access to this definition? Is it excluded from the build that is distributed as a library and so should I build the library from source myself?
OR Is there a better way of doing what I am trying to do? Anyhelp would be appreciated as like I said I am new to all this stuff.
Thanks in advance.
EDIT: Not many DirectShow devs out there? Or is this a stupid question, definitely open to any advice peeps may have...
The normal way to do this is to reparent the video window using IVideoWindow::put_Owner to make it a child of your own window. You will also want to set the AutoShow (false), Visible, Width and Height properties, and change the WindowStyle property to make it a child window.
The IOverlay interface was implemented in the first version of DirectShow (1996) to support some hardware decoders that are long since defunct. I don't think the current video renderers will support it.
The window handle was made difficult to obtain because poor application programming caused frequent deadlocks in Video for Windows and the developers felt that a clear separation was needed between the DirectShow threads and the windows they owned, and any application threads.
G