As if Pipes, and IPC were any better? c'mon give me a break bastard programmer from hell.

Hey Sledge, Take a look at this one: d3js.org[^] And then take a look here: Google Charts[^] Both free!

Oh but nothing has to fly over the intranet for these things. Look at Node or Express, host your own WebServer in your solution. None of this requires IIS.

Ok bud what ever you say is true. I'm thinking it's a skeletal team doing skeletal things. Only time will truly tell us where WPF will go...

No, it's not possible to impress execs with WPF charting. That's my point. System.Windows.Forms does a better job, but not the upscale "better" big brother. BTW, there are so many free charting solutions for web pages out there it's really not possible to figure it all out. I agree MVVM is simple. 3D charting is free... again my point on the missing parts of WPF.

Yes head's do explode, especially when they realize the limitations of the WPF framework. Not that this idea would have done anything to plug those gaps, it could make things much easier than they are today.

You may have forgotten that Rich GUI was one of the tenants of Silverlight, of course WPF being the superior cousin in many respects, never had RIA! WPF is not Rich GUI, it has too many gaps.

Oh Pete, you die-hard WPF lover, are you telling me that's a bonifide release?

Oh geez Sledge give me a break... I saw their list of "new features"... Tell me which one is your fav? I never said I wanted to run a desktop app inside of a web browser. What I was alluding to is hosting web browsers with better control inside of WPF applications. In addition, seeing that MVC is a far easier framework wondering why WPF hasn't gone that route. The Charting control? Yes... I mean even TFS 2013 shows charts all over the place. Want to impress some exec? Show them a graph, oh yeah, I forgot, just don't show it to them in WPF. Hey Sledge; "how come" you never have provided any articles here on CP?

No, I don't play with guns.

Thanks for input, I must be crazy!

No not confusing anything at all, but thanks for your response. And agreed the WPF MVC concept could be done today with the tools provided. There would still be view and viewmodel folders; however a new Controller folder would handle all "routing" requests. Of course WPF doesn't have a routing concepts because the view is routed automatically by WPF system. However, we see plenty of code for MessageBus and ICommands as well as RX implementation of event handlers.

No question that the concept is mind-blowing... however consider this: WPF never integrated (fully) the charting control, it's only available via some outdated toolkit. If you search for open charting tools there are zillions of them in browser world. But who wants to force a desktop application to also have a WebSite that hosts those charts? WPF is mostly in what I feel is a Sunset mode, there appears to be no further development happening from Microsoft. WPF has overcomplicated things too, just look at the DataGrid and compart that to JQUERY's DataTable, there's no comparison JQUERY is agile, WPF DataGrid is not. The web side is exploding with new frameworks that were inspired from the MVVM pattern. Just look into Angular. If there were a Hybrid WPF solution implementing MVC where the web site is hosted within the application, then we have the best of both worlds with everything being bindable to a single ViewModel on what MVC calls the "Server Side". We as WPF people don't loose anything but we gain everything "Web". This idea is not that different than those saying that there is a coming convergance of C# and Javascript!

With all the open web libraries out there... we find that we can create some very nice MVC projects (quickly) using them! WPF is my personal favorite Desktop framework but sometimes I find myself wishing I could use some of the open source web stuff in the WPF projects. Conceptually if a WPF project could easily bypass IIS but provide similar web services (gets and posts) then we know that MVC would be happy as it doesn't care who does the service. Assume now that we could use the controller model of MVC inside of a WPF project, host a browser and use ViewModels just like we do today in WPF. The project template would then look very similar to the MVC template but would be for desktop applications. We could easily combine WPF controls with the WebBrowser or many instances of the web browser (one for each control) and use the Controller model on them for the post backs. The first hurdle would be bypassing IIS and containing the equivalent HTTP support in a WPF project.... The second would be how to implement the controller base class as we know from MVC that it is a pretty intense component. Of course they always say start simple right? Thoughts? Or am I just going crazy?

Was wondering if anyone at CodeProject can find this source code? Someone alerted me that there is nothing there. Rated the articl a 2 because of it. WPF Grid Row Iteration[^]

Agreed, all legacy Office code in my opinion is junk. They spruce it up by adding pretty views, but then confuse us by hiding stuff. In ten years we'll be pissed that they changed Office 2010.. Office needs a complete rewrite with .NET wrappers. None of this COM B.S. :)

Be careful how you feel and think about new technology. In 1992, I was a mid-range, mainframe bigot. Their mode of communciation back then was SNA. SNA had built in routing (mostly in the APPC world via static configuration), but it also had dynamic routing via it's cousin APPN. I had heard noises about TCP and the Internet back then and a little company named Cisco who sold a piece of hardare called a router. The whole idea of the router was to dynamically link peers for the sake of communication. I dismissed it as a novelty because the Mid-Ranges and MainFrames so domminant back then did not need a separate piece of hardware to establish inter computer communications. Fast forward to 2010. Today we see nothing but Routers handling 98% of all computer communications. The mid-ranges and main-frames all now support TCP as the primary protocol of choice and hook directly to the internet which routes packets by a piece of hardware called a router made almost exclusively by Cisco. My bigotry stopped me from buying $8.00 Cisco stock, so in a sense I lost a fortune over this. The other thing I learned is that when a company makes an internal descision to turn to another technology, often the developers and end users are the last to know. The reason they do this is to keep everyone that bought into their now legacy solutions happy. They will intentionally delay sunsetting products for those that invested in legacy solutions. The early adopters that caught the first wave are now company heros for having 5 years experience before anyone realizes what has transpired. I'm not Javascript fan, but HTML 5 and Javascript appear to be taking over the world. :)

Most of MSFT's objects are propriatary. Not that you can't figure out the protocol (in this case Visio protocol) but it's usually pretty complicated. Not to panic, what I've done in the past is attempt to save MSFT as a web page and decipher it that way. Looking at HTML is the "Common Thread" that we all easily understand. Because Visio involves graphics you may have to dig in a bit deeper because yes, even graphics have protocols. XML is another good way to "skip the internals" of a file protocol. XML is another Easy way to get the Visio engine to respond to simple commands via the markup. So here's a start fo you take a look here and see if you can't find a mapping for the file format you want: Google Search for Visio File format