>There's nothing to stop you from creating a WPF control and COM-enabling it, then dropping it on a VFP form. But then, why not just use WPF in the first place?
>

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...