|
Quote: Hello... I'm a winform developer with 3 yers of experience. Now very confused with my carrier. Some of my friends told, there is no future for a winform developer. So what can l do for a good carrier. Now I'm working in a small company. Recently we are changed our development into wpf. But its very poor when comparing with scope of wpf. Anyway now I'm waiting for good advice. One more thing is that, I have to make a friend circle with some of self updating developers. What can I do. please me me...
|
|
|
|
|
Just learned to use a spell checker? So now you need to learn not to trust what it suggests... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
(NOTE: I was a pre-.NET VC++ and then a WinForms C# guy after that, up until I "retired".)
Other than just having a completely new API with slightly different names & signatures for functions - and perhaps some better software capability (i.e., that seems to be something that could have been incorporated into WinForms) - the only thing I can come up with it is that it is designed to work with XAML files & has a new way of doing data binding. I guess XAML was a big step and required a completely new API.
modified 24-Jun-15 14:07pm.
|
|
|
|
|
WPF is an old technology now; it's not normal to have WPF vs. Winforms conversations anymore.
With that being said, when WPF was being developed, a number of factions were pressuring Microsoft to make significant changes to Windows client development, forcing them to come out with WPF (officially released in 2008).
1. Test-driven development became a major industry trend after Kent Beck published the first TDD book in 2002. To facilitate test-driven code, people wanted more separation of the UI logic and business logic, resulting in both XAML (making some of the UI code declarative rather than imperative) and patterns such as MVVM (which avoids many problems that make event-driven UI code difficult to unit test).
2. Using graphics hardware effectively was important to some people, and Winforms used old software rendering for graphics. WPF does hardware rendering.
3. Some people wanted better control over avoiding the problems associated with large numbers of developers maintaining one application. Microsoft came out with the Prism library with WPF to appease that crowd.
With that all being said, after creating WPF, Microsoft did a poor job of improving it and fixing its issues. Winforms had to compete with Java Swing, Borland products, and other competitors, while WPF didn't have any serious competition, so Microsoft refused to allocate many resources towards improving it.
|
|
|
|
|
I think it's important to point out that while WPF might be considered "old technology", many aspects of it are more alive than ever in form of Windows apps. In fact, the whole Windows Runtime UI stack is just a reimplementation of the same core WPF/Silverlight concepts in native code (the property system, the data binding, templating etc.) You just have to take a glance at the similarities of the Windows.UI.Xaml and System.Windows namespaces to get the idea. You could brand that as based on WPF-technology, and it probably wouldn't exist without WPF in the first place.
But it's true that WPF was kind of left in the cold after it's release, and since the improvements that were made for .NET 4.0 (those were necessary because they rebuilt the Visual Studio UI on WPF during this period of time and found out how much performance and text rendering sucked in the real world on a large scale application), the platform was obviously considered mature and put into maintainance mode and the focus went to the Windows Runtime. Even though they try to revive it a bit recently, I think there's no doubt it's already on the way to be phased out over time in favor of Windows apps.
I'm not a fan of the new Windows app model and a little disappointed about the fate of WPF. After all, it's really nice to work with and from an API perspective one of the better frameworks Microsoft ever built. It's a little harder to learn than Windows Forms, but once you understood and got used to its concepts, you really see how powerful it is.
|
|
|
|
|
Once again I get in late. I'm starting to work with WPF and find it really nice (and I am saying 'nice' to a Microsoft thing). I like it very much. But being an 'outsider' of Microsoft world I just realize that it's old technology. Which is the trendy way of making windows applications if I can ask?
For me, comming form the C++ Qt world, WPF is a great envirovment for window apps and I feel a little sad about the no-support that Microsoft gives to it.
Regards.
Andres C.
|
|
|
|
|
Now, the trendy way they (Microsoft) want you to build new applications for Windows is Universal apps a.k.a Store apps. From a design perspective, building such an app is pretty familiar to how you do it in WPF or Silverlight. If you already know how to work with XAML and code-behind, you're all set to go, there are just a some limitations and missing features you have to deal with. The downside is that those apps won't be running on older versions of Windows than 8, heck, apps built for Windows 10 won't even work on Windows 8/8.1. Plus, they have to be distributed via the Store. They're opening up the Store restriction a little bit for individuals with Windows 10 and you can enable side-loading of apps (officially, this is only meant for developers and testing purposes), but still it feels weird to have this rather restrictive foundation on a Windows desktop OS, and the sandboxing actually doesn't help if you need access to lower-level system APIs.
Therefore, WPF (and even Windows Forms) is still the way to go on the Windows desktop for some time because your applications will work out of the box on every supported version of Windows, not just the current ones, and you don't have to deal with a Store and certification for distribution.
|
|
|
|
|
Thanck you for the answer. It was very clear.
So I will still using WPF for my apps. It's some kind of weird the way Microsoft is doing the things with the window apps developement, but is Microsoft after all, it has not be much sorprising.
|
|
|
|
|
Dunno. WinForms still does everything I need.
|
|
|
|
|
Did you get DPI scaling right? That's been the bane of all the old winform apps I still nominally support but have no budget to do any real fixes on. Based on an entirely unscientific study of 'this is messed up' complaints from a coworker who normally runs at a 125% zoom desktop it seems likely that everywhere I wrote custom layout/resize code is messed up. I suspect that I just need to add a GetDpiScalingFactor() call to the method start and apply it to everywhere I'm calculating sizes/spacings/offsets; but as there's no real maintenance budget for any of the apps I've never been able to investigate it effectively. (Well, that and the inability to run anything newer than w7, which requires a login/out to change DPI scaling, on the work network.  )
Edit: I suspect this is going to come to a head a few years down the line when even the cheapest Dell Latitude's come with high DPI screens that require using DPI scaling for anything to be readable. I also suspect the no money problem will still be present. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I agree that it is difficult to master. At first I thought it was the product of a tortured mind.
I still use forms but slowly the obtuse xaml approach is beginning to make a little sense.
I guess it will be a while before I become an evangelist.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
never saw the appeal of WPF myself when winforms handles everything I need to do. maybe I have some old bias, but when WPF first came out it was sluggish and awkward, where winforms just work. oh sure it doesn't have all the pretty graphical translation capabilities, but winforms has an easier model to work with for us one person shops.
|
|
|
|
|
|
swampwiz wrote: ...the only thing I can come up with it is that it is designed to work with XAML files & has a new way of doing data binding.
It also exploits advanced 3D graphics capabilities in modern machines.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I have only used it for my non-work projects however I have found that in learning some WPF and implementing some WPF projects it has improved my understanding of how to 'code' well.
In needing to learn MVVM, MVC etc design patterns it has had a very positive influence on my workday projects which are largely winforms projects.
So WPF may not be the fastest platform on which to develop however it did force me to learn better ways of developing and thinking about IT problems.
For that alone I have found WPF to be helpful - I find it helps me to learn new ways of thinking about or approaching problems and for me that is a good thing.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 21-Jun-15 4:23am.
|
|
|
|
|
Same for me.
However, WPF IS the fastest way to develop UI apps. I always blame the web world because is not (or rarely) taking inspiration from the WPF world.
|
|
|
|
|
GuyThiebaut wrote: In needing to learn MVVM, MVC etc design patterns it has had a very positive influence on my workday projects which are largely winforms projects.
I agree.
|
|
|
|
|
This was actually a boon for Winforms development. Those patterns (MVC, MVVM, MVP) already existed, they just weren't widely used. WPF brought them to the fore of the desktop developer hivemind, and WinForms project development has improved because of it.
|
|
|
|
|
You hit the nail.
- XAML allows screens/pages/windows to be designed declaratively. If you only ever use the designer, Windows Forms and WPF aren't that different, but that's just an illusion facilitated by the Windows Forms Designer.
- With XAML's binding model and MVVM, a lot can be done without writing any "code"; furthermore these tend to be easier to read and understand.
- The WPF UI is hardware accelerated. This is a big one. Windows Forms is slow and doesn't support true transparency. WPF is fast, and supports true alpha transparency.
- WPF is completely styleable. Don't like how the default radio button looks or operates? Override its template. All of the default templates are published, so if you want to tweak one, it's easy.
- WPF is easier to adapt to different screen sizes, not to mention the XAML is 97% compatible between WPF, Windows Store apps, Windows Phone.
I still find Windows Forms faster for quickly putting together business applications, but I find myself being won over by WPF for its flexibility.
|
|
|
|
|
For me its not so much about design patterns or industry trends, it is about capabilities:
Dynamic Layouts In Win Forms you often layed everything out with absolute positions on a "canvas". In WPF one quickly learns to use the dynamic layout capability of different panels so your app works at different resolutions, window sizes etc. and adapts.
Control Customisation You can completely overhaul the look and feel of every control with a little XAML to completely fit your vision - with Win Forms you had to work the properties you had - with WPF can you replace all the parts and it still works, e.g. a ListBox can appear as a Solar System.
|
|
|
|
|
The solar system link was really interesting
This is part of the reason that I like WPF it allows us as developers to do what we want with much less restriction than winforms - also part of the pleasure is in solving the puzzles that crop up when developing WPF(you know something is possible, you just don't at the moment know exactly how you are going to implement the idea).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
WPF can become the next big thing if some really good developers decide to build some applications that are very GPU intensive. The only other way to create an application that can do realtime graphics rendering and 3D structures with texturing and lighting without WPF is to handle it with Direct X. Until some fantastic apps come out that only guys with wild rigs can run, WPF will not ever get used fully and show its glory. I plan to develop a 3D desktop to take the place of rainmeter, Jarvis and a few others as an all in one interactive desktop as soon as I get the extra time. But for now, bread on the table baby.
|
|
|
|
|
I managed to get this stupid win 8.1 lappie into recovery mode.
How?
The obvious way.
Plug in a VGA monitor lead and turn the power on.
No, seriously. That's what I did, and Windows immediately came up with "Had a problem starting, what do you want to do?" On the lappie screen, of course, not the VGA connected monitor - that stayed blank.
And although windows couldn't fix the start up problem it is at least "refreshing" the PC - which is a reinstall of Win8 without scrubbing the HDD, it seems: you have to reinstall every app after that, but keep your data.
I'll do a disk image when it's powered up ok, and before I install anything.
My dislike for Win8.x grows with every single exposure...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Deja Vista
New version: WinHeist Version 2.1.1 new web site.
I know the voices in my head are not real but damn they come up with some good ideas!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
