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.
Yes, but you were complaining of lack of control support in the current version of WPF. The transitioning really comes into play by mixing WinForms and WPF, and as WPF matures, you will be able to get rid of the WinForm stuff.Quote:
Originally Posted by chris128
Yeah I see what you mean. Still annoying that the controls that are available dont seem to have as much functionality as the controls in winforms but oh well.
I keep getting tempted to go back and try WPF again but every single time, anything I try just ends up reminding me why I havent stuck with it so far...
For example, I tried to follow a video tutorial on the MS website that involved just adding a few controls to the form and doing some basic stuff but even that got screwed up. I added two controls to my form and then after that it wouldnt let me add anymore... I dragged them in from the toolbox and the form just flashed grey and the controls didnt appear. I spent ages trying to get it to work and in the end just started again from scratch and this time it worked fine... Oh except the toolbox didnt get filled with items until I closed the form and re-opened it twice :S
EDIT: Oh and god knows how you reference controls on one form from a class in WPF! I tried for about 20 minutes and gave up. Anyone got any ideas?
Quote:
Originally Posted by chris128
reference controls on a form in a class? That has nothing to do with WinForms or WPF, it is all the same as it is just a language feature. If you want to reference a given control on a given form, from some random class, the random class needs a reference to the form (or at least the control) it wants to modify.
If you had a new WPF app, and stick a button on it (button1), you could write code like this:
in your Window1 classCode:Public Class TestClass
Public Sub ChangeButtonText(ByVal myForm As Window, ByVal Text As String)
DirectCast(myForm, Window1).Button1.Content = Text
End Sub
End Class
this is the same as WinForms...Code:Class Window1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click
Dim myTestClass As New TestClass
myTestClass.ChangeButtonText(Me, "HELLO WORLD")
End Sub
End Class
Well all I would do normally in a winform project would be something like this:
but that does not work in a WPF project so it is not exactly the same as winforms...vb.net Code:
That syntax is using a feature specific to VB and WinForms called "default instances". They actually only exist in .NET to make VB6 developers more comfortable, as they were the norm in the VB6 days. VB.NET actually dropped them in its first 2 releases, but added them back in, in 2005 because of the migration woes of VB6 developers.
So it is actually not the "standard" .NET way to do things.
Ah well like I said before, I only jumped on the VB bandwaggon at .NET 2.0 so these things are the norm for me and as such I had no reason to think things would be different in WPF. I just installed VS 2008 SP1 BETA and it has made a few improvements to the WPF designer (such as being able to sort properties alphabetically) but has also brought along its own set of problems...
well it is only a beta so things are likely to change when the RTM hits. To be honest if you really have these issues and problems with WPF (even if I don't see all of them as "issues") you should enter them in connect.
Connect is a feedback and bug reporting system that MS runs, and they actually WILL respond to every entry you put in there. You may not always like their response, such as "won't fix" for a bug you report, or "closed (by design)" for some issue you think is a bug, but they state is by design.
In any event, I use connect all the time to report bugs and feature requests, and I get very good feedback from MS when I do so. If you feel there is a problem or something lacking, go report it, and wait for their response. It usually happens within a few days (if not sooner).
If the features you want, are also features other people want, then MS will see the number of requests for a given feature, and will be more likely to implement it. Likewise if they see people having lots of the same issues with regards to a certain bug, that changes their priority on fixing such things.
The URL is
http://connect.microsoft.com/visualstudio
You can search all existing feedback first to make sure you don't duplicate an entry, you can also vote up someones existing feedback, or comment on it, if you are having a similar issue, or have more to add.
Cool, yea, my next attempt at WPF will be after the RTM comes out. As I said, I like how the GUI is disjoined from the application. It'll be interesting.
I'm in the same boat as Chris, I tried about three tutorials on MSDN's site and only got one of them, the simplest one, to actually work. One I was getting close to done and I dragged a form and next I know, all my controls disappeared off my form. I can only assume some bug/glitch in the IDE FUBAR'ed the underlying XAML code and broke it completely. I couldn't make enough heads or tails of the XAML to figure out what happened though.
Yes, there have been some problems with the designer. Most people developing full time in WPF actually use the XAML editor exclusively, and don't do any visual layouts via drag/drop controls like WinForms. More of a webpage type approach (since WYSIWYG editors for webpages never seems to get it right).
There is even a bug with WPF projects if you have option strict on. They missed it before it went RTM, but there is a type conversion error that happens when option strict is on. The IDE is smart enough to correctly propose the CTYPE() fix and apply it for you, but still annoying none the less.
They issued a KB article on it, but I think it is fixed in SP1 for 2008
http://support.microsoft.com/kb/945756
I still think even after SP1 the whole thing will seem quite unfinished... I know its only the first version of WPF etc etc but I think I speak for most people when I say I would rather wait longer for a decent stable version of it than have a buggy unfinished version sooner.
One other thing that I touched on earlier, Microsoft Expression Blend - doesnt anyone else think its a bit of a joke that to actually make decent animations and really nice looking GUIs with WPF you need to spend another £400 on some extra software? As far as I can tell you cant even make a reflection effect, which is something that like 80% of WPF examples seem to use, without using Blend.
I agree, as SP1 is not really going to bring too many new things to the table in terms of WPF as a technology. SP1 is not a service pack to WPF, it is a service pack to the Visual Studio development environment. So the improvements in the WPF sector are going to be focused on better development support in the IDE, faster XAML rendering, etc...
Yea, that irked me as well. I toyed around with Expression blend's trial version last time I tried to figure out WPF and while better than what VS could do, I don't see it worth the price MS is asking for it.
You're right about there are no decent WYSIWYG editors for webpages. The web is built on such a horrid nightmare of mish-moshed standards and additions to those standards, is it any wonder why Firefox and Internet Explorer, in their latest incarnations STILL have disparities displaying the exact same webpage the same way?!
My biggest concern is that WPF will have the same issues. If the Visual Studio IDE already is having problems constructing and building forms, and WPF is in it's "first version", then I'm expecting a spiral-of-death with buggy, glitchy behavior in the future that has to be painstakenly manually tweaked every time just to work exactly the way you want it to.
The web "standards" are far from adequate as standards go. Only recently have good feedback tests such as Acid2 and Acid3 come about to test the display and formatting engines of browsers. I'm just hoping it's not going to be the same for the "future replacement to Winforms."
Well you have to really look at the magnitude of a company like Microsoft, and the projects it undertakes. I really didn't get that either until I went out there for the first time 2 years ago, and learned a bit more about how they run. It is probably not too much different from any huge software house, but I am a sole developer, like many of you on this forum, so it is a much different environment for me.
Such is the products and technologies that make up WPF, VB, and Visual Studio, etc...
There are all these teams over at MS that work on specific things. So there is a VB team, but they don't actually implement features of the IDE. They may work with the IDE team to implement things specific to VB in the IDE, but it is still 2 different teams, that have 2 different sets of workers and managers, and it all goes all the way up to a common person who is a manager for the entire division or product group or whatever.
So they all have to collaborate and decide on what can work, what will work, what they have time to implement based on release dates which are planned way in advance, etc..
Many of us live in an environment for development where we can make a small change to a program, test it really quick to "assume" it works for everyone, and compile, and we are done. Over at MS, they are building the tools we use to build our tools. They have to account that people are going to try to use their software in all kinds of unthought-of ways, versus the apps we write which usually have general purpose "do this" type of functionality. It is just a totally different monster.
I remember asking someone on the IDE team about a feature I wanted to see implemented on intellisense. This was probably back in May. They said to me "That is a good idea, and we have already scheduled time in November to evaluate what changes we will plan for intellisense, so we will add that into our discussions". So that should give you an indication of the time spans that projects see over there, that they have to schedule time months in advance just to have meetings about possible features they might implement... its pretty crazy.
Yeah I mean I cant even comprehend that kind of thing, having never had any programming job in my life I dont even know what its like working for a small development team let alone a huge one.
How come you got to go over to the MS development headquarters then kleinma?
As you may notice th MVP designation in signature which gives us special access to developers at MS. But we should try to keep on topic. :)
I must admin that I do fail to see what potential benefits having a XAML method of creation has over the classic winforms. Ok WPF looks great and as a display technology its wonderful. But to the developer would will ever be the advantages of using it?
Currently to me the only real reason to use WPF on anything is to gain experience of it, so in 2 years time when its actually worth bothering with you can say on your CV that you've already got 2 yrs experience with it.
I do think it seems largely unfinished, which isnt surprising considering the size of the task, I would imagine it will be great in VB11 though.
There is a yearly summit for all MVPs to visit the Redmond campus. I have gone to 2 of them now. Being an MVP for a programming technology, you get to interact with many of the developer product teams while there. Probably my favorite presentation we had was from Paul Vick.. I am probably just a geek, but it is pretty cool to get a presentation done about the future of VB from none other than the lead architect for the language. Being a VB guy, to me it was cooler than the presentation that Anders gave (C#'s daddy).Quote:
Originally Posted by chris128
A really good overview of WPF that is not some Microsoft whitepaper, or some how too article, is actually the wikipedia entry on it.Quote:
Originally Posted by Jay1b
http://en.wikipedia.org/wiki/Windows...ion_Foundation
Thanks, I have read it previously.
But the currently method of dragging the controls on to the form could still be continued without going the XAML route, but with the WPF engine reading the winforms instead... Web development is a mess, I would hate application development to go the same way.
Yea I kinda hate the XAML as it reminds me of web dev. IMO the drag n drop should still have the same technique that winforms have for designing (like setting properties in the property grid and not in the xaml). Sure maybe for more advanced features you could access the xaml but there should be more vb code dependancy.