You've missed my point. I have no doubt that WPF (and Silverlight 3 for that matter) is "ready for business". You'd asked what was the point of doing WPF in VFP via COM and I tried to point out that one could maintain their VFP data access techniques (and just change the UI with WPF to a certain extent).



>WPF can definately do serious LOB. I'm currently working on a WPF project that has no video, no spinning buttons. It's capabilities are similar to what we'd do in a VFP form.
>
>
>>How about this...getting to your VFP data is no different than what you're currently doing while giving your UI a face lift? I'm assuming that the WPF app is actually a "real LOB" that needs data and not just some form with video on a spinning button :)
>>
>>I'm only half serious here. I guess it does have the benefit of letting you learn WPF while staying within the bounds of VFP for a while. I'm currently using a web browser control on a VFP form to render a "dashboard" in a VFP app. The dashboard has sortable, searchable, tables, charts, graphics, regions than can be toggled, etc. I had to learn HTML, javascript, jquery, css and all that good stuff. On top of that I had to figure out how to drive all this from within VFP. While it was a bit of a challenge, it turned out to be not so bad. I ended up having a multithreaded VFP dll that grabs the data from a VFP database. I then "inject" the content into the dashboard's "regions". After all this I think that I've been doing what's called "DI" and "IoC" in the .NET world of WPF, PRISM, CAL, blah, blah, blah...