3D in managed mode (WPF, and not only)

In this week I had the chance to do a little work with WPF 3D capabilities.

I wanted to implement a user control implementing a visualizer of “something” in 2D for a Windows.Forms application. I decided to add a 3D view capability. Language used was C#.
I started with Managed DirectX. It’s crap. Simply put, there exist just two versions of MDX and they are not compatible (!). Plus the first one is very buggy (if you write a 50 lines program and find a bug in the SDK, you can claim it’s very buggy :(). The DLLs do not come with the framework. Last but not least they are abandoned, because MS decided to develop XNA.

I could go with XNA, but XNA is not, again, distributed with the framework, and is very game oriented. I didn’t want to force business users to run an XNA installer for a non-game application, specially taking into account that the 3D visualization is not a requirement, it’s an added feature of the component.

OpenGL wrappers exist, but the first one I found has been abandoned. Not the solution I wanted, but still better than MDX/XNA.

So I went to WPF. The 3D is not very complex and so WPF it’s enough.

I developed a 2D control using Windows.Forms and System.Drawing and then left the 3D part to an internal, hidden, control developed using WPF (thus my control is in the end what MS calls an hybrid control — supported scenario ;)).

So, let’s go with some considerations about WPF.

Edit :

I was forgetting a very important consideration.

WPF is fixed function, sadly. No shaders. In 2007 this is like releasing a single tasking operative system. I don’t know if I will use this Windows 3.1 of 3D in the future, on second thought.

November 23, 2007 | Filed Under .NET, Programming, Rants | Comments Off 

IE7, Javascript, the WebBrowser control and bugs

Problem
Internet Explorer 7 (IE7) has been released. Applications around the world are breaking. … Well at least mine failed.
If you use the WebBrowser control in .NET applications or shdocwv ActiveX control you may hit this issue.

If you load the html by navigating to “about:blank” and then using DocumentText, AND you are including a script (using for example <script src=”somefile.js” language=”Javascript” type=”text/javascript”></script>) your script will effectively not be included. The main symptom is a “Error: Invalid Character” message or simply script failure.

This means that your other scripts and events in the page will fail. Most probably this is a security measure (I have a theory about it but before that .. the solution).

Solution : embed the Javascript in the HTML. You hoped for something better right ? :( Anyway embedding the script in the HTML solves the problem and if you are setting DocumentText from your code chances are it’s either generated by an XSLT (in which you can use either a msxsl javascript to include a file or a couple of xsl:include / xsl:apply-template without many side effects) or from your code (in which case.. well you are the programmer who did it, find a clean solution ;)).

Now, why have they introduced this change?
Probably they fear the scenario where a Javascript injects in some way in the DocumentText the include of a local file (along with some copy of itself) and then uses the data which now is in DocumentText in some .. evil way. I’ll try to forge some proof of concept demo.. if that is possible at all of course.

Edit
I’ve found this discussion [forums.microsoft.com] which propose a number of other interesting solutions.

Another interesting page with registry keys (process wide) for IE7 is here [msdn.microsoft.com].

October 26, 2006 | Filed Under .NET, C++, Programming, Security, Uncategorized, Win32 | 1 Comment 

Helper application for COM interop in .NET

A common usage of COM interop in .NET is using Active Scripting (or the Microsoft Script Control) to add scripting to an application. While this seems odd (.NET has powerful scripting capabilities, why not use them?), it’s infact frequently used for its simplicity.

There are a couple of problems, however. The classes must be declared COM visible (or the entire assembly if you prefer) AND overloaded methods and statics are not accessible.

Here is a small C# app (source) which lists all public overloaded and static methods and properties which are in public classes of the assemblies passed in the command line.

Check the source here.

October 23, 2006 | Filed Under .NET, Code Snippets, Programming, Uncategorized | Comments Off 

Wow! P/INVOKE made easy

While wasting tim^H^H^H^H^H^H^H^H^H ahem While reading important and interesting stuff around, I stumbled upon http://www.pinvoke.net/. It is a great site for those who want to P/INVOKE from .NET languages on native APIs. Heck, it’s so great sometimes I check it even when coding in native C++ :D

February 8, 2006 | Filed Under .NET, Uncategorized, Win32 | Comments Off 

← Previous Page — Next Page →