SharpDX 'No such interface supported' - screenshot

I came across this post here C# Which is the fastest way to take a screen shot?
and am trying to implement the answer that utilizes SharpDX. It appears to run fine on Windows 10, however, it crashes on Windows 7. The error it gives is:
Unhandled Exception: SharpDX.SharpDXException: HRESULT: [0x800004002], Module: [General],
ApiCode: [E_NOINTERFACE/No such interface supported], Message No such interface supported
And the stack trace it points to...
var factory = new Factory1();
var adapter = factory.GetAdapter1(0);
var device = new SharpDX.Direct3D11.Device(adapter);
var output = adapter.GetOutput(0);
var output1 = output.QueryInterface<Output1>();
Happens at output1 line where it does the QueryInterface. I don't know a whole lot about graphics drivers, but is this an issue with the DirectX11 configuration? Or is this something inherent to Windows 7?

SharpDX is nothing more than a thin managed code wrapper around the native C/C++ COM interface for Direct3D. As such, all the information you need can be found in the Direct3D documentation on MSDN. I would highly recommend reading through whatever you can find there, as almost all of the restrictions and caveats apply to SharpDX.
Now, the code you have is doing the following:
1) Creating a DXGI 1.1 Factory interface (IDXGIFactory1).
2) Getting a DXGI 1.1 Adapter interface for the first graphics adapter (IDXGIAdapter1).
3) Creating a Direct3D 11 Device interface from the aforementioned adapter (ID3D11Device).
4) Getting the first output from the adapter interface (IDXGIOutput).
5) Querying for the DXGI 1.1 Output interface (IDXGIOutput1) from the DXGI 1.0 Output interface.
The last step of this process is the point where things fail. This is because the interface you're asking for (IDXGIOutput1) is not supported on standard Windows 7 - it requires Windows 8+ or Windows 7 with the Platform Update. You can see that in the Requirements portion of the IDXGIOutput1 documentation on MSDN.
Again, I would highly recommend you familiarize yourself with the C/C++ interfaces defined by Direct3D if you plan to do any further work with DirectX or SharpDX.

Related

Are OpenJDK and Oracle JDK compatible serialization wise?

Can you safely deserialize with OpenJDK some binary data that we got by serializing something with Oracle JDK? (and vice-versa)
Let’s assume the java version is the same (and that the class code is available, and is the same, in both stages).
Is the exact way Oracle JVM serializes objects considered public information?
To expand on comments from #morgano, #RealSkeptic and #EJP (to whom credit should be given): yes, Java Object serialization is directed by an official specification, which is public, so any JVM implementation that does serialization should conform to it, or not be called a JVM.
I will say it is not entirely safe. In my Android app, I can not deserialize data on an Android 7 device which has been serialized on an Android 6 device. Apparently, Google switched to OpenJDK in Android 7.
The error I get is:
java.io.StreamCorruptedException: invalid type code: 71
This problem was reported here in a similar fashion
This poses quite a problem since my app sends serialized data over the internet and it will not be compatible if it runs on both Android 6(or lower) and Android 7.

Kinect motor control via Processing

I'm hacking the Kinect using some simple-openni based processing apps for a talk I plan to give soon and I found an API that appears to control the motor. There is a moveKinect method that appears to be added to the main ContextWrapper interface but I can't seem to get it to work. Looking through the svn history and release notes it appears to have been added last year with a note that explains it doesn't work with the newest drivers(5.1.02,Linux64). I've tried calling the method giving it values in degress and radians but nothing happens. I get no error and no movement. Has anyone else played with this? I'm running with the 2nd to latest processing 2.0 build (the link to processing 2.0.1 doesn't work) and the latest SImpleOpenNI package I could download.
SimpleOpenNI is the wrapper for OpenNI which allows access to the RGB/IR/Depth streams and the middleware for body/hand detection, but does not allow access to hardware like the LED, accelerometer or motor.
You should try Kinect P5 which uses libfreenect behind the scenes and supports motor control. Bare in mind you won't have support for the middleware.
If you need both middleware and hardware access you can try OpenFrameworks with the ofxOpenNI addon. It has a has a hardware class that works on OSX and Linux (as sudo) allowing use of both the middleware and motor.

OpenNETCF and Windows Embedded Standard O/S

If I have an application that is written in .net Compact Framework (and runs on Windows CE) and is theoretically compatible with Windows Embedded Standard O/S, would it still be compatible if it makes use of OpenNETCF functionality?
Things like running .exe files with help of OpenNETCF for example. I am assuming that OpenNETCF uses P/Invoke under the hood, which might make the application incompatible with other OS than Windows CE.
I don't use P/Invoke in my code, but I can't asnwer for sure whether OpenNETCF does or does not.
.net compact framework 2.0 and windows embedded standard
OpenNETCF does use P/Invoke extensively.
It is effectively a wrapper for some core OS functionality in Windows CE and its derivatives, that is not otherwise implemented in the Compact Framework. In practice this means extensive P/Invoking of coredll.dll; the basic OS module for Windows CE.
Windows Embedded Standard is Windows XP. For this reason I would not expect you to be able to use OpenNETCF.
Depending on the version you're using you may be able to get hold of the OpenNETCF code here (or buy the latest of course), and see what's going on under the hood. Also, what you may find is that the calls you are making to the OpenNETCF are actually implemented anyway when compiling for Windows Embedded Standard.
One way to approach this is to make another project to target this platform, containing exactly the same code files, but no reference to the OpenNETCF, then work through fixing the compile errors.
You can add a Conditional compilation symbol to either the CE project or the Windows Embedded project then fix the errors like so (This example is not for OpenNETCF, but you get the idea):
public static string ExecutingAssembly
{
get
{
#if WindowsCE
return Assembly.GetExecutingAssembly().GetName().CodeBase;
#else
return Assembly.GetExecutingAssembly().Location;
#endif
}
}
Obviously you will then have to create a build for each platform as the outputted assemblies will now be different.
As Chris points out, the SDF makes heavy use of coredll P/Invokes. That's not to say everything does, but it's certainly a minefield. I tend to have a CF project and a FFX project and places where I have overlap I use aliasing, like this:
#if WindowsCE
using Thread = OpenNETCF.Threading.Thread2;
#else
using Thread = System.Threading.Thread;
#endif
Then in the code you just do your normal
var thread = new Thread(...);
And things work out.
Now ages ago we did start an interesting side project of creating a coredll "shim" for the desktop. What that means is that a p/invoke to "coredll" on the desktop would actually call that DLL, which would in turn marshal the calls off to kernel32, user32 or whatever. Our testing for what we implemented (and there's a fair bit there) showed that it worked just fine, so if you're using a limited subset of APIs, just dropping it on the PC might make the CF assembly "just work".

WCF KnownTypes in Mono 2.10 / MonoTouch 4.0

I have an application that uses WCF. It runs great on Mono 2.8.2 on Ubuntu and .NET 3.0 on Windows.
It decorates the WCF service contract with the 'ServiceKnownType' attribute, which points to a method returning the derived types needed to use the server:
[ServiceKnownType("GetKnownTypes", typeof(KnownTypeProvider)]
I am porting my app to MonoTouch. I am using the latest 4.0, based on Mono 2.10.1. This no longer works: my WCF call fails because the DataContractSerializer on the client doesn't recognise the return type.
I set a breakpoint in my 'GetKnownTypes' method and see that it is never called. I assume that this part of System.ServiceModel is not present / not working in MonoTouch?
I try to work around this by decorating the base return type with the 'KnownType' attribute instead.
[KnownType("GetKnownTypes")]
Again, it doesn't work and my 'GetKnownTypes' method is never called. Looking at the source for DataContractSerializer, it seems if you use a method name rather than specifying the type, it just gets ignored?!
I will try again by specifying the type instead of using a method (looking at the source of DataContractSerializer, it looks like this will work), however this is tricky for me in MonoTouch because I will need to use typeof rather than Type.GetType("fully.qualified.typename").
Is there another solution? Workaround?
I did see this: How do you configure WCF known types programmatically?, however it seems MonoTouch is missing some of the required interfaces...
Thanks in advance
It looks firmly like either a bug in MonoTouch or a regression in Mono (I don't have an environment to test in Mono 2.10 on the desktop right now)
Worked around the issue by restructuring my projects and using
[KnownType(typeof(MyDerivedType))]
On the base type. This works just fine on MonoTouch 4.0.

Haptic feedback in Compact Framework 2 running on Windows Mobile 6.5

I'm writing a Compact Framework 2.0 application on Windows Mobile 6.5
Several of the built-in controls (e.g. button) produce haptic feedback - small vibrations - when clicked.
Is there any way the same thing can be achieved in custom controls?
I'm aware of some platform specific APIs for this - but I'm looking for a generic WM6.5 API to call if there is one.
There is no "generic" managed Windows Mobile mechanism for this. Your best bet is to abstract the implementation into an interface, then have it determine at run time what you're running on and instantiate the implementation based on that.
The LED notification API is probably the most common implementation by OEMs and I think would cover the majority.