webinars blog downloads register login
Home Porting Products News Support About Us
Ice Tea Group Blog
Stay informed about the worldwide migration from
Team Developer to .NET. Don't get left behind.. again!


Gianluca Pivato posted on September 30, 2010 14:42

WPF is a great new rendering technlogy from Microsoft. It's based on .NET and offers a huge set of options.

According to Unify, Team Developer 6 will be able to import and use WPF controls.

At a first look it appears that through a combination of reflection and WPF hosting it's true. You will be able to host WPF controls in a SAL application. In fact it can be done easily with TD 1.5, or TD 4.2 already.

I have doubts about the usability of wrapped WPF controls in a language (SAL) that is not really integrated with .NET. So far the implementation that has been divulged by Unify shows a very simple interface based on strings and string arrays. Meaning that to use a WPF control you have to use its methods and properties using string arguments for the method name and parameters. This approach precludes you from creating composite controls, passing objects, receiving objects, prevent syntax errors at compile time (strings cannot be checked by the compiler), and so on...

In any case, Unify made me curious. I started wondering: what if they are onto something? What if it's difficult for a migrated application to use a WPF control? So I tried to use a WPF control, actually a composite control, on a ported form. That is a form originally created in SAL and migrated to C# using our solution. Here it is:



Couldn't be easier. There is no interpreter or converters in between. In C# you can use directly all the methods and fields of the WPF control. No matter how complex they are.

Look at this very simple code from the sample above: 

// Update YValue property of the DataPoint 

chart.Series[0].DataPoints[i].YValue = rand.Next(-80, 100);

What would this code look like in using SAL wrappers? I decided to try and started writing some SAL code, just to see what it would look like.

The first part of the C# statement is "chart.Series[0]". In SAL it would look like this (notice that I probably have to use "get_Series" to use the indexer):


  • String: sIdx[1]
  • String: sReturn
  • Set sIdx[0] = "0"
  • Call SalWPFInvokeMethod(VisiChart, "get_Series", sIdx, sReturn)


Now, the method "get_Series" should have returned a reference to an object of type Series. On this instance I have to call the method "get_DataPoints", right? It's the second part of the C# statement  "chart.Series[0].DataPoints[i]".

But sReturn can only return primitive types, so I'm lost at this point... Wait, I can still write the last part of the simple C# statement, assuming that there is (or will be) a way to overcome the previous stumbling block:


  • String: sArgs[2]
  • Set sArgs[0] = "-80"
  • Set sArgs[1] = "100"
  • Call SalWPFInvokeMethod(VisiChar, "[?]set_YValue", sArgs)


Is this really the kind of syntax you want to work with?

I can see many points of failure in programming with strings and arrays of arguments, so many that I may write a blog just about that. It's like low level C++ code trying to use the old IDispatch interface on COM objects. For me it was a nightmare.


Actions: E-mail | Permalink |

Our Mission

We help developers stay competitive and
organizations preserve and increase the value of their
software investment.

©Ice Tea Group LLC. All Rights Reserved