WPF - Why was it formed?

[BubingaMan]

WPF has the richest xaml-based feature set. Silverlight was pretty much a stripped down version of WPF. WinRT xaml looks like a stripped down version of silverlight ("looks like", because I haven't done anything worthwhile in it yet, it's just first impressions). In any case, as long as you get the xaml principles down along with MVVM, you'll be up and running on all xaml platforms in no time. The learning curve can be quite steap though, it's a lot to take in at first. But it's real fun imo.

[Peter Adam]

As a Delphi developer I would say this is cycles of evolution. In the beginning Delphi separated the design-time set properties into a binary dump. Then it became obvious that sometimes it is necessary to hand-edit this file (ex. remove properties of changed components, reorder parents, etc.) so the dump file became human readable. Change to .net. Then in Visual Studio projects these human readable, easy to write visual designers for configuration files became ordinary source files so the coders see what happens, was easy to remove components with conditional compilation. But it was became obvious that it was hard to write a visual designer for it. Then the configuration file became human-readable XML with option to compile it to binary form, and the cycle may restart.

[Tomaz Koritnik]

Hi Also don't look at it black and white. WPF has a ton of features you can use but you will also need a lot of time to get to know all of them. You can use only part of it for the start. You can start using it in a more WinForms-like way by handling UI events through event handlers and setting UI values directly instead of binding (ant not creating a mess on the way). With this, you can still use WPF's rich UI compositing feature which is light-years ahead of WinForms. You can do things you only dreamed about doing them in WinForms (unless you want to go low-level and draw controls by yourself). By only using UI composition features you're far ahead of WinForms, not to mention other features. I don't see a reason going back to WinForms once you get to know WPF. Best regards T

[Gary Wheeler]

For me, the problem WPF solves was rich UI. I've spent years in the MFC trenches writing owner-draw code and sophisticated layout management. I hate going back and maintaining those applications now, because WPF is so much simpler and more expressive. Thanks, Pete. Those of us who actually like WPF appreciate it.

Software Zen: delete this;

[Nicolas Dorier]

Actually it succeed. Silverlight, WPF, and WinRT have use same paradigm on styles, templates, datatemplate, visual state manager, resources. Sure the API is not EXACTLY the same, the commerical name is different, but I don't think we should keep such expectation when devices and way of using the app is so different accross device. Most of the code is copy/pastable or reusable through some clever "Add as Link" / #define in your code. Learn WPF, and you learnt most of what you need to know on WinRT and Silverlight

[Nicolas Dorier]

Learn WPF and so you will understand both WinRT, Silverlight and Windows phone dev at the same time. The name of the technology is different, but the way of developping is the same. There is a good chunk of code reuse between these devices. (Already copy/pasted a style of some Windows phone controls to my wpf app without changing anything, just to see it works as a charm). Styles,VisualStateManager, ControlTemplate,DataTemplate,Resources, MVVM, Binding, all works the same on all these technologies. (As well as Expression Blend for Advanced design)

[ClockMeister]

I'm with ya here. I played with WPF for awhile and didn't care for it. I still develop desktop Windows applications and the standard Windows Forms still works fine. I personally found WPF to be a method of making developing desktop applications as painful as web ones! You can have XAML as far as I'm concerned!

[Donald Thornhill]

Quote:

Windows Presentation Foundation (WPF) is the answer for software developers and graphic designers who want to create modern user experiences without having to master several difficult technologies.

Ummm... XAML, MVVM, MEF, Prism... jumping off into WPF was the beginning of sorrows. :cool:

[Jahmal23]

I really enjoy learning new things and I find WPF useful. That being said...it's difficult to explain the benefits of MVVM to management at times, especially since it's not as straight forward as event handling directly in the form code. They just see it as, "takes longer!". X| Hence, I'm working with Winforms lol.

[Erhy]

with ShowUI in PowerShell there is no need of XML a little tool with ShowUI in PowerShell :

Import-Module ShowUi

############################################################################

Hibernate_WPF_V2.ps1

start with Cmd-Batch example:

@echo off

cd /D C:\Users\Public\Documents\prog\Hibernate

start powershell -STA -WindowStyle Hidden -Command .\Hibernate_WPF_V2.ps1

############################################################################

function global:Hours_and_Mins ( [Int16]$MinsTill ) {
if ( -not ( $MinsTill -gt 0 -and $MinsTill -lt 1440 ) ) {
return "--:--"
}
do { #get certain time
$nowdue = Get-Date
$now = Get-Date
$nowminutes = $now.Minute
$nowhours = $now.Hour
} while ( ( $nowminutes -ne $nowdue.Minute ) -or ( $nowhours -ne $nowdue.Hour ) )

$TimeAtTill = $now.AddMinutes( 0.5 + $MinsTill ) #a half minute in plus
# Write-Host  ("TimeAtTill: " +  $TimeAtTill.ToString("HH:mm:ss"))
$HoursAndMins = $TimeAtTill.ToString("HH:mm")
return ( $HoursAndMins )

}

function global:MinutesTill ( [string]$AtTimStr, [ref]$TodayTomor ) {

$now = Get-Date
try {
        \[DateTime\]$AtTim = Get-Date $AtTimStr
} catch {
        \[DateTime\]$AtTim = $now.AddMonths( 12 )
}

if ( ( \[int64\]$span = \[Math\]::round(( $AtTim - $now ).TotalMinutes )) -lt 0 ) {
    $span += 1440
    $TodayTomor.value = "tomorrow"
} else {
    $TodayTomor.value = "today"
}
return ( $span )                    

}

function global:BtnOKdekorate ( [object]$Btn, [string] $clicked ) {
if ( $clicked -eq "clicked" ) {
$Btn.Tag = $Btn.Name
$Btn.FontSize = 13.0
$Btn.Content = "count down"
$Btn.Foreground = "green"
} else {
$Btn.Tag = $clicked
$Btn.FontSize = 22.0
$Btn.Content = "OK"
$Btn.Foreground = "black"
}
}
#############################################################

main

#############################################################
New-Window -Name MainWindow -Width 200 -Height 286 -title 'Minutes till hibernate' `
-ResizeMode CanMinimize -Background Pink -Top 0 -Left 0 {
New-StackPanel -Margin 7 -Background Pink {
New-TextBox -Text "minutes`ntill hibernate" -IsReadOnly $True `
-Background Pink -BorderThickness 0 -FontFamily Arial -FontSize 22.0 `
-HorizontalCont

[User 10205789]

Funny as the main reason presented here is the polished look and feel you get from WPF. Yet if you look at Windows 8+ and Visual Studio 2012 and on, the visual interfaces are absolutely ugly. Polished look - where? What an excuse to force an ugly practically useless product onto developers.

[User 2893688]

Don't know if this has been answered but will take the liberty to state it again. WPF was an ambitious plan to change the way we work with Windows development. It was part of Framework 3.0 which was a part of Vista. Ironically it wasn't a full Framework at all, but just three sets of BIG APIs designed to change different parts of the coding process. Before we delve into WPF, we must touch the other two (Windows Communication Foundation [WCF] and Windows Workflow Foundation [WF]) and know that all three share the same XAML description language. WCF is a modern replacement for the old .asmx model which allows you to build a Web Service inside any CIL *.exe and build Web Services beyond SOAP. I currently use them to connect BizTalk to SAP using SAP Connector. WF was an ambitious plan to create Enterprise Service Bus potential in everyday applications, connecting WebServices to business flows and logic, using graphic programming. Last, but not least, came WPF, the Windows Presentation Foundation, which was an attempt to 'reimagine' the desktop experience. It was thought that during Vista, application developers would abandon Win32 in favor of WPF. That didn't happened since the impact of the Web was far greater than Microsoft had expected. Enterprise had already went full web and all modern application development was being done in Java or ASP.NET. So Microsoft created Silverlight, to revive WPF into a Web Plus thing, just like Flash. But then came the mobile revolution and people started making apps instead of applications, and apps became companions to web pages (aka a thin client world). Today WPF lives on in the Metro paradigm for both Windows 8 and Windows Phone 8. Windows Phone 7 was a type of Silverlight, but WinRT (the common framework for 8's) is more WPF like. All Metro apps can communicate with WCF services and could (theoretically) use WF workflows. Few people are going this route as Node.js and JSON have replaced SOAP as a communication approach except in the B2B side. As for the reason to use an XML markup system to describe the app, instead of doing it graphically and programmatically like WinForms, you must know that the concept behind WPF was that the markup is just a partial class of the codebehind. That way you could have the View separated from the Controller and Model. This was an approach created by the NeXT Cube and NextStep (the fore father of iOS and OS X) in a system called Model-View-Presenter. The language used was called a plist had no programmatic

[_CodeWarrior]

What you are talking about is more of a XAML nature. While XAML is a part of WPF, it is only the popular method by which WPF user interface items are expressed. WPF itself has a lot more to do with performance, binding, and event handling than just XAML. For instance, WPF offloads almost all UI display processing to the graphics hardware, while Windows Forms relies on the CPU to process each repaint. WPFs binding ability, arguably one of it's neatest and most useful features allows for true (and fairly simple to implement) separation of concerns between application logic and UI display logic. I will also say that the UI elements have a very good dynamic sizing engine built under them. I could never have done some of the things that I have done in WPF with Windows Forms.

[_CodeWarrior]

I did not buy Visual Studio for a polished look. I want something that is there when I need it, and gets out of the way when I don't. I have found VS2012 (2010 also used WPF BTW) and VS2013 to be pretty good about that. The ui elements do not draw any undue attention to them and I can focus on my work. Additionally, I have some degrading eyesight and the Dark Theme in 2012 and 2013 work wonderfully for me. The monochrome-ish design supports the dark theme. Too many colors would make the dark theme unusable.

[BillWoodruff]

As always, I enjoy and learn from your thoughtful remarks, Pete. I think an issue anyone ... who's not already committed to, in the thick of ... WPF ... today ... faces is evaluating the future potential of investing time and energy to master a given Windows technology stack, like WPF, or ASP MVC, or RT/XAML/C#. Several months ago, you hinted, in a message here on CodeProject, that you felt some exciting news was coming from Microsoft that might affect the perceptions of the future value of WPF ... information you could not share at the time (I infer) because you were under NDA. Perhaps all of whatever you hinted at is already revealed; I'm not sure. So, let me ask you a rhetorical question: if you had a bright young developer asking your advice at this time ... someone who's weighing technology stacks like ASP/MVC, HTML5/CSS3/JavaScript/jQuery/nodejs, Android/whatever, .NET technologies using XAML (WPF, Win RT, et. al.) ... and let's throw IOS in there for good measure ... what advice would you give them about where to invest their energy in learning and mastering a given stack, and getting productive with it ? I don't mean for this to be "trick" question: obviously, what a person is already knowledgeable about comes into play here; as does whether they are looking to be employee or be an entrepreneur; whether their target platform is desktop, or smart-phones; whether making money is the goal, or achieving "fame and glory" is the goal ... and so on. I'd really enjoy hearing any speculations you care to make, and I am sure other people here would enjoy them. yours, Bill

“But I don't want to go among mad people,” Alice remarked. “Oh, you can't help that,” said the Cat: “we're all mad here. I'm mad. You're mad.” “How do you know I'm mad?” said Alice. “You must be," said the Cat, or you wouldn't have come here.” Lewis Carroll

[Pete OHanlon]

Right now, if I were advising a new developer, I would push them towards the MEAN stack (MongoDB, Express, Angular.js and Node.js). While WPF does have some future (sadly, I cannot reveal what it is - you're right that I'm under NDA), this release was probably the last that any new features would make it in; effectively it's now gone into maintenance mode. So, why would I not recommend the "Metro" stack? Well, I'm just not convinced that Microsoft is going to get enough traction in the consumer device space to make it worthwhile for developers to really push into that space. If I were advising devs on looking at the consumer space, I'd recommend learning Java and pushing for Android, or learning Mono C# and targetting Android/iOS. At the end of the day, it's a numbers game, and until Microsoft change direction in their licensing, they will not make the huge inroads in the consumer space. It's not as though they had a form of monopoly on small form-factor device OS that they had on the PC OS market, so they really have their work cut out. Realistically, I see Microsoft moving more towards the enterprise space and pushing things like Cloud services (their idea of an OS in the cloud really hints at this direction). I see that there will be a fair move in this space to the web world, which is why I recommend working with the MEAN stack - I'm currently writing an article on it for CP, and it's a really rich environment to work with. To give you an idea, here's one of the bits of code that I'm currently working on:

var mongoose = require('mongoose');
var Schema = mongoose.Schema;

var LanguageSchema = new Schema({
language: {type: String, required: true},
display: {type: String, required: true}
});

function languages() {
languageModel:null,
__constructor = function(){
this.languageModel = mongoose.model('language', LanguageSchema);

    var languages = \[
        {language:'Csharp', display:'C#'}, 
        {language:'VB.NET', display:'VB'},
        {language:'cpp', display: 'C++'},
        {language:'css', display:'CSS'},
        {language:'html',display:'HTML'},
        {language:'javascript',display:'JavaScript'},
        {language:'java',display:'Java'},
        {language:'perl',display:'Perl'},
        {language:'php',display:'PHP'},
        {language:'python',display:'Python'}
        \];
    languages.forEach(function(language) {
        this.languageModel.find({language:language.

[RafagaX]

Shiny new toys, that was it's purpose back then... :laugh:

CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...

[Kyudos]

I agree. Unless you need some sort of 'clever' or 'fancy' UI, I don't see many advantages. Honestly, how many times have you wanted to re-style a whole UI. WPF certainly has nothing to recommend it when considering updating apps built on 'old' frameworks like Froms or MFC.

[JamesHurst]

You pose some good, very-honest questions preaa. Here's my thoughts, "Why would you put your UI in painful XML tags when you can use Windows forms?" Once you get used to the XML, it actually becomes far easier and gives you a lot better control. Actually, you *can* still compose your gui by creating your widgets in your code-behind, but once you become as one with the XML, you find that you can weave a GUI as simple or as capable as you want, with non-rectangular elements, animation and other visual effects that are impossible with Windows Forms, and the binding facility is quite advanced. I've been spending the last decade creating a lot of desktop applications, and WPF is my #1 tool of choice. Nearly everything can be defined using the same 'language' (XAML) - and I am not limited to standard widgets. I've created some fairly sophisticated 3D CAD programs, a beating-heart animation (that reflects the measurements being taken of an actual patient's heart), and a geographical-display that shows aircraft moving across it, with drop-shadows and multiple cameras (all, still without leaving the world of XAML). I created one family of pretty 3D-effect buttons, and easily share it across all of my WPF projects while overriding certain of it's properties. I never liked using a "designer" to place controls onto my GUI, and am so comfortable with XAML that it takes me only seconds to type up a fairly decent form that responses as the user resizes the window, adapts to changing text values, etc. "If it were to separate UI completely with the behaviour, aren't the developers doing that already with clean layering architecture with the forms based applications?" WPF provides a way to achieve a far cleaner separation of presentation from domain behavior. In fact, you can have your graphic artists load up the same Visual Studio solution into, for example, Blend, and fine-tune the visual aspects, at the same time that the developers are working on the code. "load .. on a browser?" That (XBAP deployment) in my opinion, was an additional deployment option, that neither I nor most developers I know ever used. SilverLight, on the other hand, did seem to take off for a while and I felt it was an excellent solution for a time, until HTML5 and CSS3 provided more standardized solutions for the same problem-space and SilverLight got de-emphasized. I think it's safe to simply ignore that option. I see the world of desktop apps, and online apps, as usually serving two very different spaces. A lot of users do not want to

[preaa]

Well thanks again for lots of insights. I do not have a clear picture of where WPF knowledge will take me as a developer. I am also an ASP.NET MVC developer and earlier did a lot of iOS work. I thought windows desktop applications were obsolete until I saw some cool apps on Windows 8. I bought myself a Win 8 touch machine and I really liked the weather app and some others. So, I think that WPF and all the other 1000 things like silverlight or RT etc are going to help me create these desktop apps on Win 8. Will that be cool? I don't know. nevertheless, lot of good answers that help me. BEst