Hi John,

>>>That's because Internet explorer is not an application interface, but a document container. It's an ActiveDocument host, and support of this is very difficult to do. And even in IE it works worth a s*it. It's nice to demo but I have yet to run into anybody actually using this technology. Heck Microsoft did (GotDotNet shared projects) and stopped - in fact it killed the whole GotDotNet concept over it.
>>
>>>There's also the whole issue of security that will likely be a nightmare with control access at this level because VFP will not support hte .NET security model - so there's no way for VFP to be a trusted caller over COM.
>
>Is .NET really that poor of a system that it can't concievably interact nicely with other systems? And... if it is why would I want to bother using it at all? You really leave .Net in a rather unfavorable light here. Listening to you I have to wonder why I would consider using .NET with VFP at all.

This has really nothing to do with .NET, it has everything to do with Windows and to some extent Visual FoxPro's inability to interface with other environments. It may seem trivial to you to say that 'it should just host this form in my environment' but it's just like I said - you're asking the equivalent of hosting a Windows form in a DOS application. Did that work? I don't think so...

The issue here is not so much .NET but the hosting environments. ActiveDocs is not a .NET construct - it's a COM construct and one that never really worked well outside of Internet Explorer. Just like the ActiveX container in VFP that never was truly as compatible as say the VB6 ActiveX container. These interfaces are very difficult to implement into a development tool interface, especially VFP because it is not using standard Windows windows.

I'm talkign about visual aspects here. PLain interop to components works reasoably well through COM interop and that's easy to do.

>But... I don't really buy that. On a simple google search I see tons of examples of .NET\winform controls being hosted in IE. If it's that hard why do so many places say it's so easy to host them in IE? I currently host IE in VFP just fine... so it only follows that it should be posible to host winform controls in a more direct fashion.

Show me a real example that isn't a demo...

It's easy to do until you try to rerfresh the form or you run in an environment where security is tied or, or, or, or... even GotDotNet required custom security settings that needed to be entered into the configuration framework configuration tool manually. You want to put your users through this? This might work for developers (and even then it caused major problems), but definitely not for end users.

>>>Frankly I fail to see the significance of running an Avalon UI INSIDE of a VFP application? Avalon is different enough that if you want to take advantage of this functionality you will need an environment that supports the richness of this model.
>>
>>Avalon is VERY different in how it handles the graphics layer and it's not really 'more of the same'. it's kind of like asking to embed a Windows control into a DOS application...
>
>I don't recall anyone here even mentioning the Idea of hosting Avalon in a VFP form. It sounds like the ability to call and interact with an Avalon form will be one of the things we are getting in Sedna. Avalon is further out in the future, and you may be right it may not be doable on a VFP form. We were talking about hosting current .NET winform style controls on a VFP form, a much different animal from what I can see.

Ah, but you didn't listen to Kens keynote. Sedna is all about Avalon and Longhorn, which is why it's not coming for another two years.

You can do .NET interop today and if you put in the work to translate you can talk to .NET today well enough to do just about anything you might need to. If Sedna is to have any value at all beyond that it would have to be tieing much more closely into .NET in a way that provides access to services directly masking the interop aspect or help with things (a la accessing forms of a completely different environment) that would otherwise be VERY difficult to do.

>.NET programming really isn't an option for the 90% of work I do. Maybe some day in the future it will start to have some of the features that make VFP such an indispensable tool for me, but .NET has a long long way to go to even come close. In the mean time, I would love to be able to use some C# in the work that I do. There are some things that would be easier for me to do in C#. Providing a way to host winform controls on my forms would be a great step in that direction. But... if it's too hard or .NET is too bloated or incapable of a system to be able to do that, I can live with out it. (I just find it hard to believe that it is.)

I am not saying that .NET is the answer for you or anybody else. But Sedna and what it means for VFP at this point is pure speculation. It's clear from the VFP keynote that the VFP team has no idea at this point how or even what to address as the technologies that are in the next push are not even completely defined at the API level and still completely changing. All they have committed to is that they will provide

My personal opinion of all of this is this: Choose one or the other (.NET or FoxPro) as both have strengths. But using both together other than for transititional purposes is not something that I would bet the farm on for a variety of reasons.


+++ Rick ---