Mike Sue-Ping
Cambridge, Ontario, Canada
>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...
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only