I would like to know what exactly is WPF, what are the benefits of using this and how can it be used? A friend of mine told me that it came with windows vista and i have no idea what it is, ive never seen it
Printable View
I would like to know what exactly is WPF, what are the benefits of using this and how can it be used? A friend of mine told me that it came with windows vista and i have no idea what it is, ive never seen it
It didn't even occur to you to look at the MSDN Web site?
http://search.msdn.microsoft.com/Def...us&refinement=
The short (from how I understand it):
It's a GUI system, similar to Windows Forms. It seems more targeted at ASP.NET developers who design web client type applications, but it could be used for Windows Forms type applications as well.
It's more generic in that you can use the same controls for web-browser based applications as you do for stand-alone applications. The panels and controls are described via XAML. Thus, your GUI is more "separated" from your core application code, allowing you to re-design it more easily and implement things like skinning and localization easier.
It is rendered to the screen in a different manner than Windows Forms (it uses DirectX as opposed to GDI+ I believe) so things like looping animations are possible with little performance hit to Windows.
Personally, I've tried twice to start a Stand-alone WPF Application project, but ran aground because the controls just don't seem as feature-rich as Windows Forms controls and don't do what I want them to do. The foundation is in my opinion too primitive to replace things like Windows Forms projects, but it's a very smart direction to take the .NET framework in regardless for the advantages listed above.
It is definitely the future of user interfaces, but we're not there yet. It still isn't supported across the board, so there's no reason to use it right now.
You would really only want to use it if the target systems have great graphics processing power and of course the 3.5 framework.
This might help as an overview, coupled with that MSDN link above http://en.wikipedia.org/wiki/Windows...ion_Foundation
Just to clarify a few things:
- Yes it's pre-installed with Windows Vista (and available for, but not pre-installed with XP SP2 and Server 2003)
- It was partly available within the .Net framework 3.0, but expanded a lot in the 3.5 framework
- It does indeed utilise DirectX
From MSDN:
It is based upon the XAML markup language which was used by MS's Windows Mobile team. This is similar to XML, but allows for plugins (applications, movies etc.) and properties to be specified within the markup, alongside of properties for styling. It is meant to simplify desining of frontend applications so graphic designers or other users can manage the design more using applications such as MS Expressions, before the deisgn is passed to developers to hook up backend code using the .Net framework.Quote:
Windows Presentation Foundation (WPF) provides developers with a unified programming model for building rich Windows smart client user experiences that incorporate UI, media, and documents.
Glad its not just me then! The controls seem to have hardly any properties, I dont understand how you are supposed to make a decent usuable program with them :SQuote:
Originally Posted by Jenner
You use the XAML to customize your GUI, not just properties.
WPF will replace WinForms totally at some point. MS is still pushing WinForms a little for line of business type applications (forms over data, etc..) but eventually we will likely see WinForms go away all together in favor of WPF (or whatever it may be called in the future).
It is certainly not just for the web, as that is really WPF/e, which was renamed to something you may have heard about, called silverlight.
It is a bit of a learning curve if you are used to WinForms programming, but I can see its strong points as well. I am actually working on a hobby project that will use WPF as a replacement Windows shell.
Yea, about every 2 months or so, I attempt a hobby project. Man, I do application programming to get away from friggin <tags!>. Every time I see line upon line of <blah> <blah> <blah> I start going cross-eyed! :D
I suspected that the interface development for WPF was more on XAML side of the fence. I don't mind that XAML offers the ability to do a lot of custom programming of forms and controls on your interface, I just wish out-of-the-box it was more accessible as properties are. At the very least, offer most of the same properties as Windows Forms - even if those properties are only part of the IDE which is modifying the XAML behind the scenes. I think last I played with it, there wasn't even half of them.
I suggest for anyone doing any WPF that you install the beta of VS2008 SP1 because I know there were many changes and improvements to XAML rendering and the XAML editor in the IDE.
While sometimes it is easier to dig into the XAML, there is a pretty functional visual editor that is similar to WindowsForms visual programming, complete with drag/drop controls from the toolbox, a properties window (with filtering which WinForms doesn't have). So I am not sure what you mean about the accessibility of properties, other than maybe the fact that they aren't always called the same thing as they were in WinForms.
<RANT>Quote:
Originally Posted by kleinma
At some point back at the beta of .Net 2.0 I heard some rumblings from a Microsoft guy that Remoting was a candidate for deprecation after the next (then 3.0) release of the framework. I don't know where he got his info (or even if it was true at the time) but I remember that it raised the hair at the back of my neck and he had the same sentiments. We both supported .Net-based systems that were live in banking environments. I've got a ton of code on remoting and several live systems so I wouldn't want to see the namespace scrapped just after it's first really strong release (which I consider as that of .Net 2.0). Sure, WCF is great and web services are great too but I feel that Remoting offers the best mix of features, control and ease of use for people that code for Wintel environments.
I feel the same way for WPF. I definitely hope that we see something different than the existing version because I'm going to find it very difficult to justify to myself and my boss a redesign of everything the company has fielded simply because it suits the fancy of MS.
I'm a big advocate of the framework and that's the reason I've promoted it so heavily in my company. I salute brave, code-breaking changes and forward-moving actions where they need to be done. I love the notion of XAML and there are a few places where I think it can help in the codebase I support. But I'm not ready just yet to see the whole WinForms architecture being thrown to the dogs. I really hope that any kind of transition from WinForms to whatever WPF will evolve into will be very gradual so that everyone has a chance to assimilate the technology and migrate systems.
To some I may sound as an old fart that can't cope with change. Well, that may be true. But it's also true that I feel I have a responsibility towards my colleagues at work who aren't so eager to rewrite something that works perfectly and to my company which ain't going to sell more products because they use XAML instead of WinForms. I might as well use Clipper for all they care. I'm going to be very dissapointed (and I'm not talking about the VB6er-don't-change-anything-I-don't-get-it style) if WinForms isn't supported for years to come with regular updates to keep up with current new goodies and a clear roadmap that shows exactly when and how support for the namespace is going to be withdrawn.
</RANT>
one of the nice things at least about WPF is a WinForm host control, so you can host WinForms inside WPF. This makes transitioning applications a bit easier, and hopefully, with nTier type development, a good amount of business logic and other code is seperated from the UI, so wiring it all up to a fancy new WPF interface should not be a horribly complex undertaking.
For the record though, all my commercial development is still in WinForms, and I only know a little bit about WPF because I haven't had a paying job to really dig in and learn it. That is one reason I am using a hobby project to work on WPF.
oh, and while "support" and "compatibility" for WinForms is going to be around likely until I am dead at least, the real kicker is that you will see less NEW development in WinForms. So you won't be seeing as many nice new cool controls like we have gotten in WinForms over the years from VB6 and up, you will just be seeing really cool WPF type controls coming from MS. So you will start to WANT to change over, because WPF is supposedly going to make GUI development better. It is just that the technology itself, and more so the tools to develop with it, still need to mature a bit..
Just open a VB.NET winform project and drag a richtextbox or something onto the form and look at all of the properties shown in the designer alone, now do the same thing in a WPF app and you will see the difference. I have given up several times on WPF apps because there was simply no possible way to do what I wanted, which was very simple GUI changes (and I thought the whole point of WPF was to make nice looking, feature rich, GUIs)Quote:
Originally Posted by kleinma
Chris, I don't really see much difference with the richtextbox. Without digging too hard, can you provide an example?
ok I'll have a quick look. I just remembered one other thing that really annoyed me - the fact that you cant sort the properties by alphabetical order! I know your going to say "well you can filter them so you dont need to sort them" but its not the same... I'd much rather click a button and scroll down a bit than have to click a box and type something.
OK well the first thing I tried was to add a progressbar and found that this has no Style (or similar) property that allows you to choose from blocks, marquee, continous etc so unless I just havent looked very hard then thats one obvious thing that is missing. I mean just using that as an example - how do you actually make a progressbar move in a marquee style in WPF? Surely you dont have to manually code it when it is a preset thing in .NET 2.0...
The whole thing just seems very unfinished and sparse to me. I mean even small things like hovering over an item in the toolbox no longer brings up a description of what that control does, it just brings up the control name (which you could already see in the toolbox anyway). Also clicking a property no longer brings up a description of that property below the property window (which I find quite useful).
All of the missing things just seem to be things that it makes no sense to remove...
Maybe I just need to read up a bit more on what exactly WPF is supposed to do because to me it seems like it can no way be used in the same way that I am used to using winforms. I mean what is the point in this XAML stuff? It seems daft to me to be writing a VB.NET program but be naming the controls etc in the GUI using an XML style system... what advantages does this have over creating properties in native VB.NET code?
Let me introduce you to the IsIndeterminate property. Anything else?Quote:
Originally Posted by chris128
Though I suspect JMC's already answered this and found the property, what you have to think of also, is that WPF is a newer technology. As you mention yourself within this paragraph, it's likely this property wasn't added to the original .Net ProgressBar control until the 2nd edition of .Visual Studio.Net/the 3rd version of the .Net framework so many of the controls and properties missing at the moment will come.Quote:
Originally Posted by chris128
I refer the hourourable gentleman to post 6 :p XAML allows for a wider range of people (with little or no programming experience) to practically build a full blown working UI & application (well that is the theory - in likelyhood many will complete posssibly upto 3/4 of an app then need to pass this onto developers or learn programming, but it's a nice idea).Quote:
Originally Posted by chris128
well why the hell would anyone think "oh look a property named IsIndeterminate, that must relate to the style of the progressbar...". That just comes back to my point about how stupid it is to remove the description of properties that appears in the winform designer when you click on them. Why should I have to search through documentation etc just to find out something as ridiculously simple as how to change a progressbar style.Quote:
Originally Posted by jmcilhinney
It seems like they are moving backwards... I appreciate that they are kind of starting from scratch because of the XAML aspect but surely it doesnt take a genius to realise that adding everything from the winforms designer and then building on it would be a good idea, instead of just adding some bits and changing other bits and completely ignoring other bits..
Anyway, no one is going to win this argument because we are all entitled to our own opinion, so I'll just shut up now
Actually yes! How do you set the speed of the progressbar? I had a thorough look through the properties listed in the designer and couldnt find anything that could possibly relate to this... the default speed is rather sluggish so I'd like to change it but as per usual with WPF, that is not an obvious or straight forward task.Quote:
Originally Posted by jmcilhinney
So after I tried to customise the progressbar control and gave up, the next thing i did was play around with the bitmap effects that are available and found yet another stupid thing. When you select a bitmap effect from the dropdown list there is no way to change it back to nothing (e.g no bitmap effect). The only way I found that I could do that was to edit the XAML script. Again this just comes back to the point I made earlier about the whole thing feeling very unfinished and not very well thought out...
I know people are going to say well if you read the documentation blah blah blah but put it this way, would you make a program that users had to read loads of documentation before they could do even the simplist of things in it? I know I always try to make applications as user friendly and obvious as possible, so why cant Microsoft..
EDIT: Oh look, the next thing I tried to do was add a DataGridView but whats that? It doesnt exist in WPF? Brilliant.
lol.. Well i have a nice 1900 page to read through about WPF.... Obviously to make things a little harder its all written in double dutch (also known as C#), with VB code on a bloody CD! How stupid is that?
EDIT: Incidentally it was the only indepth WPF book on the market at time of purchase...
Can you not just print off the vb code from the cd? ;)
the fact that its C# or VB is not so important, because most of the learning curve is not on the code side of things, its on the presentation UI side of things, which is all XAML regardless of underlying framework language.
yep, fantastic, another language to learn as well as whatever you are using to do the actual coding of your application...
You dont have to learn it if you dont want to, just as you dont have to use WPF seeing how XP is still the dominant OS version in use in businesses. This will buy you time to pick up XAML later if you so desire to.
If you want to get a head start on WPF then the pitfalls are to be expected in the initial version release.
come on man, its still better than web programming where you need to know HTML, Javascript, XML, XHTML, VB or C# etc for server side code, ajax, etc. on top of having to evaluate it several different browsers to maximize your user base potential..Quote:
Originally Posted by chris128
That is actually something very promising about web and client development going forward, especially since MS is supporting browsers outside IE finally.
Silverlight uses XAML and VB.NET code.
WPF desktop applications use XAML and VB.NET code.
I see potential there, even with a learning curve now.
I agree thats good for web developers but I dont plan on ever developing any web applications so none of what you said applies to me :)
Its not that I hate the idea of WPF or am just set on not liking it... in fact I would love to use WPF but it just pisses me off that it takes so long to do anything simple in it and all the things that i have mentioned that are missing from the designer are annoying as well. One other thing I have noticed is that to actually make your GUI look really nice then it seems that you basically need to use MS Expression Blend (which, to anyone who has experience with Adobe After Effects or similar, will seem pretty basic and sparse).
I mean can anyone explain why on earth they have just left several very common and useful controls out of the WPF toolbox? Like the DataGridView control for example... I mean I know you can use the WinForm Host thing but surely thats supposed to just be to aid the transition over from winforms to WPF. What about when that transition is over, what are we supposed to display databases in?
It just annoys me that the idea of WPF is to make GUI configuration easier and the end result look nicer but then they have left a lot of useful controls out and havent even made the tickboxes or buttons look any nicer than normal .NET controls..
I agree that I see potential here and that MS is slowly merging desktop applications with Web application. I have been playing with WPF and I believe that the learning curve is not going to be that great. I think that the approach will succeed and that we will take this new technology in stride as we take all the new tech we must absorb to stay competitive in this great field that is Programming.;)Quote:
Originally Posted by kleinma
WPF is still a baby. A control like a DataGridView is pretty complex, and they probably just were not able to fit it into their timeline for the initial release. They probably evaluate things like the fact that you can use existing WinForm controls in WPF right now when making these decisions.
If you want your UI to have flare, and still use a DGV, then use a DGV and develop the WPF around it. As for your question as to what will happen when WPF is the norm and WinForms are depreciated, well I am sure there will be a data grid or some sort in the WPF control library. The DGV is a relatively new control even to WinForms if you think about it.
I dunno I have only ever used .NET Framework 2.0 and above so its not a new control to me ;)
This thread highlights something else as well - we dont have a WPF sub forum on these forums! I know you could say well WPF isnt directly VB and this is a VB website but we have C++ and C# forums so I think WPF is worthy :P That way any issues like this wont just be discussed in a single thread in the VB.NET sub forum. Perhaps I should suggest it to the powers that be...
If it were to become very popular here, we might consider it.Quote:
Originally Posted by chris128
Alright cool, cheers.
I'm really trying to persevere with this whole WPF thing and thought I would have a go at a WPF Browser app to see if things in there are easier to use... but no! First thing I tried was to add a textbox with a drop shadow effect and oh look it wont even run. It seems that any bitmap effect doesnt work in my WPF Browser apps so thats brilliant... they miss a lot of obvious things out but even the porperties that ARE available dont work! Dont even get me started on the anchoring system that changes itself every single time you move a control. GRRR.
Chris, I think your problem is you are trying to fit square pegs in round holes.
For most standard desktop applications these days, WinForms is still the king. For lots of custom controls, graphics, and eye candy, WPF is a strong candidate. WPF will no doubt get better as time goes on, and we will see many improvements, but in its current state, it is not suited for building most standard windows applications, unless you incorporate WinForm controls into them.
I know and I appreciate that but my point is, even making just the GUI in it is an absolute piss take... I've spent the last 2 hours trying to make very basic things in it and I have just given up now because its so aggrivating. I mean come on - to set the text of a button you use the Content property but to set the text of a form you use the Title property but then to set the text of some other control you use the Header property... it just doesnt make any sense to have 3 different property names for the same thing just on different controls. Well, not to me anyway.
I'm bored of being frustrated by microsoft's lack of common sense now and will just leave WPF for another year or whatever until maybe enough people will of complained to make them do something about it...
Well it is aggravating to you, because you are used to WinForms, and you are trying to apply all your WinForms logic to WPF. I understand why you would do so, being that you are looking at WPF as more or less the "next version" of WinForms. However MS got to design WPF from the ground up, and was able to leave behind some WinForm things that have been around since Windows 95.
If you haven't done so already, I suggest grabbing a beginner book or at least reading a few intro articles to WPF before you make final judgement.
I did read a few intro articles and to be honest the idea of developing the GUI seperately from the actual application logic sounds good for a proper programming team but doesnt seem like much of an advantage for a one man band such as myself (I dont work as a programmer, I'm just a network & server admin that has learnt a bit of VB over the last year or so). I was going to get a book but I noticed that all the ones I found were a year or two old so I figured it may be better to wait until SP1 comes out and then see if any new books come out after that. (arent there supposed to be quite a few changes in SP1?)
EDIT: Oh and yeah I am thinking of WPF as the next version of winforms because thats how people make it sound. Saying things like "the transition period" implies that we would transfer from winforms to WPF.
Talk about off topic lol, i ask one question and right here we got a novel of opinions.
On the contrary, its everything you asked for. What its it and how to use it and some links too.
Ps, yes WPF will replace WinForms eventually. MS has stated this already.