|
abmv wrote: You can create your own controls if you need to..
That is good...I know I should feel like that is good.
But when you are spoiled by WinForms development and you drag and drop the control and it "Just works" it's difficult to be excited by that. 
|
|
|
|
|
Quote: But when you are spoiled by WinForms development and you drag and drop the control and it "Just works" it's difficult to be excited by that.
I work in WinForms with a team that requires ease of maintenance over innovation. Being a 20+ yr. programmer, I have learned that getting deeper into whatever you are using generates more functionality than any shiny new tech you learn from scratch. That doesn't mean that a better way of building things is ignored, just that you learn to sift value gained vs effort spent.
|
|
|
|
|
Well its up to you..besides there are a number of third party WPF controls available in the
market if you don't have the time to do the development esp if you are building a LOB application.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I have used WPF outside on my personal projects and as has been said before WPF makes the simple complicated and the complicated simple.
My experience is that it's a bit like doing web development - it can be a real PITA but when done right gives you something nice to look at... and that's pretty much what it comes down to - you can create 'nice' custom controls and it encourages loose coupling of the data and the UI.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: WPF makes the simple complicated and the complicated simple
That's a perfect explanation of the situation.
That's a perfect quote for everything Microsoft is doing now, it seems.
|
|
|
|
|
Come to think of it... I think you have a good point
What I describe does indeed pervade most of what Microsoft does and in fact most of IT nowadays.
What I see happening where I work is that the young-uns actually admit that the only reason they introduce new frameworks into the business is to improve their cv.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: the only reason they introduce new frameworks into the business is to improve their cv.
Yep. That nails it.
|
|
|
|
|
raddevus wrote: I was looking for a way to make sure my UWA (XAML-based) app's ListView would show the last selected item even when it lost focus
I'm not well versed in UWA matters but in WPF using a behavior would be one route you could take. Maybe not exactly what you're trying to achieve, but when working on a SignalR-WPF chat application I needed new items added to an ItemsControl to scroll into view, which is not the default behavior of the ItemsControl. I wrote a behavior to achieve this, which you can look at here: SignalChat: WPF & SignalR Chat Application.
"As beings of finite lifespan, our contributions to the sum of human knowledge is one of the greatest endeavors we can undertake and one of the defining characteristics of humanity itself"
|
|
|
|
|
That's a very nice article and a nice explanation of that behavior.
I will look at that more closely.
I was wondering if it would be a behavior which I find interesting since it feels like this simple thing takes a bit more processing power -- observing an event, instead of the thing just getting set and forgetting about it.
Thanks very much.
|
|
|
|
|
We started to work with WPF and MVVM years ago and I am very astonished that people still use WinForms. WPF/MVVM really does everything we need (for our standard product for company users). And I never found it difficult to get other developers' advice and examples for WPF.
We also have some UPW apps in the store, but I cannot find companies working with them.
Btw, I understood, that UWP is based on .Net Core and therefore will survive, when the Win32 kernel will die.
|
|
|
|
|
raddevus wrote: Just thought it was very interesting. How about you?
I'd rather deal with the quirks of HTML than WPF, which I won't tell you what it reminds me of every time I try to use it. Think Alabama voters and why they don't vote Democratic (usually.)
|
|
|
|
|
Is that an analogy for inbred?
|
|
|
|
|
Nish Nishant wrote: Is that an analogy for inbred?
No, more of a single voter issue analogy. 
|
|
|
|
|
Ah, okay. I over thought it
|
|
|
|
|
I moved over to WPF a number of years ago simply because it had been touted as the technology to replace WinForms.
To me WPF biggest advantage is that you can program it in similar style to that of an ASP.NET WebForms application. However, this is about its only real big advantage.
WPF documentation is notoriously fragmented, and in some cases just downright bad.
The complexity in developing a nice interface with WPF is terrible. And like ASP.NET MVC, forces developers to take on more complexity than is actually needed.
Having to rework templates for a single control simply to have it work in a manner consistent with how you may want it to work with your application is beyond ridiculous. And the time-worn excuse that WPF is designed to be highly flexible as a result, is pathetic. On average, how many developers really require such flexibility. I have never seen a need for it in my career.
The problem is that Microsoft is still trying to set trends instead of maintaining mature platforms that have made it very easy for developers to build and implement applications. As a result, you have gotten such implementations such as ASP.NET MVC, WPF (with all the complexity), and LocalDB (supposedly to replace SQL Server CE).
Though I believe that WPF would have seen many more developers gravitate towards it had Microsoft streamlined its interface design with less complexity, they don't seem to be interested in refining this development environment. The form designer is still terrible in that you cannot accurately gauge where anything will actually show up as with the WinForms designer.
My complaint about a lot of this can be encapsulated around LocalDB. Though an excellent refinement for SQL Server Express it can hardly be seen as a real replacement for SQL Server CE, probably the finest desktop database ever produced to date.
SQL Server CE served a very specific purpose for those developers concentrating on the desktop. And as of a recent Microsoft survey (I believe), 46% of all development, despite all the hype is still for the desktop. With a few refinements, SQL Server CE would have been a snap to deploy and would have remained the desktop database of choice for a long time.
Instead, with the new directions of Microsoft under Nadella, who like all technology idiots with a "vision", he is enamored with cloud computing, which was a major factor in SQL Server CE's demise. Instead of offering both, SQL Server CE is simply removed from the product lineup. At the very least it could have been Open Sourced to a third party.
True, LocalDB can be used with desktop applications but it is a far larger implementation. To avoid user intervention during an installation process one has to set up their installation with a silent install. If you want to control any of the features of LocalDB from your application (beyond data access) you have to use a "Process.Start" method to run the "SqlLocalDB" utility to create instances, databases and the whatnot.
The idea of on-demand servicing, where LocaldDB remains dormant until a call is made for a request is rather ridiculous, considering that it will then only stay active for several minutes at a time.
With this milieu, Microsoft now claims this is a great database for developers and desktop applications. I would like to know how, when SQL Server Express is a snap to set up and SQL Server CE avoided a lot of the LocalDB issues.
Thinking like this is why WPF is a great way to program but a painful implementation to deal with...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Steve Naidamast wrote: Having to rework templates for a single control simply to have it work in a manner consistent with how you may want it to work with your application is beyond ridiculous.
Steve Naidamast wrote: WPF documentation is notoriously fragmented, and in some cases just downright bad.
Steve Naidamast wrote: The form designer is still terrible in that you cannot accurately gauge where anything will actually show up as with the WinForms designer.
These are all the exact things I was thinking as I wrote my original post.
The designer where you have to see XAML and Design View takes up so much space, controls are often invisible --- no borders or anything show up.
Documentation is extremely fragmented!!
All great points and reasons that XAML dev never really took off like it should've.
And, yes, desktop development is still a huge part of ongoing development in the Enterprise (where most money is probably dedicated to development too) and yet everyone is so (supposedly) focused on web apps, cloud, etc.
It doesn't add up.
Thanks for a great post.
|
|
|
|
|
Steve Naidamast wrote:
The form designer is still terrible in that you cannot accurately gauge where anything will actually show up as with the WinForms designer.
I admit the form designer in WPF sucks that way. I happen to love setting up grids in xaml to get everything precisely where I want it without having to drag and drop. I may be weird...
|
|
|
|
|
Feature for feature, WPF has more to offer than Windows Forms; except maybe for the "Open / save", etc. common dialogs.
You fail to find an answer to you "obvious" question, and therefor discount the entire platform.
Funny thing is, I'm currently looking at a panel which has multiple ListViews with GridViews inside a WrapPanel, and ALL the ListViews are showing the "items that lost focus" as having a "different hilite" than the ones that were not selected. Looking at other implementations, they ALL show the item that "lost focus".
And I did "nothing" to activate that functionality. Maybe that's why there are no "articles".
Default behaviour out-of-the-box (if you don't override it; like one of the "system colors").
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Yeah, a lot of developers forget the wonderful experience that is writing a <control value="Bind"> and then everything just works with no edge cases, allowing you to expand on the complex stuff. That's how you get sh*t done.
|
|
|
|
|
As a caveat, what works for me does not necessarily work for others. That said...
For quick and dirty little utilities, I still use WinForms. But not for projects beyond personal use and little complexity. WinForms can do the large and complex, but that is not my preference.
I use UWP as part of Xamarin.Forms development. While the Android and iOS projects are targeted to phones and tablets, the UWP project extends my program to Windows tablets, laptop, and desktops.
I suspect as I get more proficient with XAML, and hopefully MS/Xamarin get over their cranial-anal inversion on a XAML designer that works with Xamarin.Forms projects, WinForms will no longer be my choice for the little one-off utility programs I do.
|
|
|
|
|
I just wrote two utilities using MFC as dialog apps. The UI work took almost no time, which let me concentrate on the guts of the programs. I debated using WinForms, but it wouldn't have given me the control I needed over the guts, plus everything else in the project is in C++.
(I also debated using Qt, but I'm rusty in it and couldn't justify the deployment pains associated with Qt.)
I've thought of rewriting the simpler of the two utilities to be a UWP app, on my own time just for learning sake, but it's hard to get the energy for that since my love is still embedded programming in C++.
|
|
|
|
|
Great post and it illuminates another topic about this whole UI (WinForms, XAML, etc) thing.
For many years, we developers could be completely ignorant about graphic design -- and it was great.
We could take the basic controls and drop them on a form and we got this standard look that worked.
Sure, there were tweaks we could do but basically there was a nice standard look created by this.
We never looked at the designer files -- okay, rarely. We just let windows and controls be windows and controls.
Then, with WPF, XAML all of a sudden we have another layer of technology to think about very specifically.
It's really all just more work.
Sure, people would say you get more control over everything, but it's also more work.
And it's work related to graphical elements. We aren't graphic designers or HFE (Human Factors engineers), we are devs!!!
|
|
|
|
|
Thank you posting this! Micro$oft built its reputation on making it easy for developers to get competent in its products (e.g., Visual Basic/C++, ATL/COM, and then later WinForms C#), but then lost it way as it kept releasing the newest k3wl stuff, only to kill it a year later. This type of churn does not help anyone that is not writing books about this stuff. After a while, folks get burned out on devoting the time to learn the new stuff, only to have it go obsolete before being able to make any coins from it.  Micro$oft, like Apple, had the heft to be able to be "market leader" in a standard, but it blew it big time, making folks like Yours Truly just want to throw in the towel and retire early.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)