John,

Exactly! I would think this would give Sedna some real power. I started a thread awhile back here in Sedna regarding "ElementHost and WindowsFormsHost Classes". Now the part that would be really cool is if we got something like the ElementHost that could be used to host forms/controls from some of these other technologies in our VFP forms. I would think it would be well within the realm of what's possible. If they could pull off both, including the WindowsFormsHost, then we would really have some options.

>>I am an absolute ignorant in NET (and half ignorant in VFP BTW), so I don't know if this is a stupid question, but at what degree would be posible to use NET controls in VFP forms?
>>
>>As NET is maturing, so is the NET controls market. I would be nice to be able to integrate them in our forms almost like native controls. I mean that NET controls should follow VFP init and destroy rules (like control hierarchy initialization and destroy). With COM controls one is left out in the dark sometimes.
>>And it would be nice to have complete control on the databinding to the NET controls.
>>
>>Please, let me know if this question is a foolish one, or if I can do it already.
>
>>Javier,
>
>>No. That is not possible as VFP is not a .NET language and therefore does not play in the CLR (Common Language Runtime). What this means is that you cannot instantiate a .NET control like you can an ActiveX control. What you can do today, and Sedna promises to make even easier is to share components between .NET and VFP through COM Interop. One of the few newer demos and ideas shhown here this week at Devcon was a VFP form that seamlessly launched a .NET form. Note it was a fully functional form, full of controls (textboxes, labels, buttons and a grid, like you do normally in VFP. The sample in question used VFP data (Northwind DBC) but you could tell that the controls, especially the grid were not VFP. The example did not have a really purpose for this except to show that it can easily be done. This way you can share components and interfaces in one program.
>
>>HTH
>
>What I don't get about this is, if they can call a .NET form like an ActiveX control, why not an AciveX type container for .NET controls?
>
>I have a number of places I can think of where I could see using a control written in .NET, but only a very few where a whole .NET form would be usefull. I would do more .NET coding if I could create usable VFP controls the way I do now with c++.