Hi Martin,

There were a lot of questions about this at DevCon this week and I think there's been a lot of misconception around this topic...

I think you're right on when you say it's silly to host Avalon in VFP, then go call into .NET code to manipulate the UI, then call back out of the .NET code back into VFP???? That just doesn't make any sense...

There may be realistic interop scenerios, but the above isn't one of them. Remember in order to use this Avalon interface in the first place you have to create it somewhere and manage the event code etc. It's most likely this will be done in VS.NET (or whatever .NET IDE). So you already have to work this 'on the other end' so why now try to tie that back to VFP?

The realistic scneario there is to use Avalon on the front end calling back into VFP components or VFP automating .NET components via COM from VFP. But this convoluted scheme of going from VFP -> .NET -> VFP is just fraught with all sorts of problems.

And that's not even considering all of the Interop issues we face with passing data between .NET and Visual FoxPro (ie. type mapping incompatibilities, the inability to map VFP objects to strongly typed .NET objects) which means almost any data interaction layer between VFP and .NET is always a 'hack' solution. It can be done, but given a choice would you really want to???

The way I see it using Interop is a transitional option, not a strategic one.

+++ Rick ---


>Hi, Neil.
>
>>Visual C++ 2003 supports hosting .NET winform controls in unmanaged code, you can wrapper native .NET controls in MFC. You could even expose them to VFP through the use of an MFC ActiveX shim.
>>
>>http://msdn.microsoft.com/msdnmag/issues/03/03/WindowsForms/default.aspx
>>
>>Wouldn't it be good to host .NET winform controls in a VFP form instead of waiting for Avalon?
>
>Yes, it's true, but did you really saw the implementation? It is a lot of work to mix both models.
>
>You don't have document/view framework like in MFC, nor full OLE Server or Client support, and no GDI renering support, so as I see it, I won't migrate any of my MFC applications except to jumping really long to something like Avalon... there are so many tricky things to handle.
>
>I don't really see a big advantage of being able to embed .NET controls into a VFP form as I guess it would be quite difficult to control, and I don't think it should be a big saving (or worth the complexity risk) to do it instead of just writing WinForm client and reuse (if already available) VFP business objects.
>
>Do you have any idea I'm missing there?
>
>Regards,