4 ms·
Haha, nah it's all good. Honestly I'm shocked (shocked!) that I still see Winforms on resumes to this day. My real claim to fame is the VS Property Browser, whi
by shawnb576 8y ago
Haha, nah it's all good. Honestly I'm shocked (shocked!) that I still see Winforms on resumes to this day. My real claim to fame is the VS Property Browser, which is System.Windows.Forms.PropertyGrid to this day. I love seeing new versions of VS and being like "yep, still there, that's m'baby".
Lots of stories, here's some quickies:
- Windows Forms was originally WFC from the Visual J++ project. Anders Hejlsberg was the architect as one of his first MS roles, working with him was a huge impact on my career.
- The Winforms team was, I think the first team to ever use C#, which was called COOL (C-Like Obj Oriented Language). Before then we were using a Java-like language that ran on the CLR
- The .NET Framework originated as a mash-up of the Winforms and ASP.NET teams, who were busy building frameworks separately for a while.
- The .NET project was a boiled ocean - everything was new from the runtime (CLR) to the tool (VS.NET), and two languages (C#, VB.NET). We didn't have a working debugger until late in the cycle, everything was always on the floor. This might be an anti pattern.
- I don't remember exactly what the story was with the font...20 years!... but my guess would be that it had to do with dealing with different versions of Windows and which fonts were installed.
- Pxtl 8y agoYeah, the boiled ocean was what impressed me about it. That was a monstrous amount of content for a 1.0 release. I was coming from a python and java background so I was used to "batteries included" but .net took that to the next level. The PropertyGrid was quite lovely. I dimly remember being envious of Visual Studio having that cool no-frills edit-my-object widget and it wasn't initially available as part of the forms lib, but iirc there was some trick you could do to use it... I tried once but gave up on the learning curve because it was so designed for object properties and I wanted to use it to manipulate a datarow. I assume it got a more line-of-business-developer version in its later incarnations.
- nurettin 8y agoAs a side note, not a .net pro, but I wish you came from a delphi background where component properties are searchable by focusing on a property input and pressing tab to go into name search mode instead of scrolling around. It feels like the feature was cut from VS and properties were sorted by name instead.
- BuckRogers 8y agoFirst, thank you for your service. You did an excellent job, really. WinForms is on my resume, and I'm proud to have it there. I love it, and consider it the gold standard for GUI development. I'm not the only one with this opinion.[0] WPF just came at the wrong time, as mobile was about to ascend and added complexity (which I'll admit can definitely add to correctness). Given hindsight, they should've just extended WinForms in some way. Leaving more complex needs than whatever that extension entailed to the Win32 API. UWP is fine and would be the greenfield target, but being Windows 10-only makes it a nonstarter at any enterprise I've worked at. So it's WPF/UWP that are essentially dead to me. Once Windows 7 is completely abandoned, I'll change my tune and stop promoting WinForms and go with UWP. But not today. I'm all about building out on WinForms, or while not a UI framework, Blazor. The latter of which is part of an application/UI rewrite that we're looking to do for a WinForms app that I maintain, once it hits 1.0. WinForms does the job and it allows me to almost entirely focus on the business logic. [0]https://sietch.net/ViewNewsItem.aspx?NewsItemID=271 https://sietch.net/ViewNewsItem.aspx?NewsItemID=271
- tigershark 8y agoCompletely disagree after years and years working on winforms and wpf and switching between them at my current job. You can really tell the difference when using Wpf, you can see that it was created years later and with testability in mind. Trying to test a winforms app is much more painful and even for debugging you need continuously to switch between code behind, controller, child controllers. In a properly architected wpf app you have no code behind. And good luck with laying out your components manually, without the designer it’s a massive pain compared to xaml. So kudos to the gp and to all the great guys the worked on winforms, but please don’t tell me that they shouldn’t have introduced wpf.
- shawnb576 8y agoI think you're both right. Winforms was built on the Win32 stack, which is pretty basic and doesn't allow you to cleanly separate concerns. We had to build layout, hwnd recreation for style changes, clean wrappers around multi-hwnd objects (damn you combobox), etc. Some of these concepts around MV*, TDD, etc weren't that well known in 1998-2000. WPF was designed to merge the best of client with what was happening on the web at that time. Data binding, declarative layout, model-view separation, these are all much better BUT you're also left dealing with styling, transitions, other stuff. WPF is clearly more powerful (I also worked on Silverlight fwiw), but takes more skill to operate. We were targeting the VB6 user who was creating LOB apps at a big enterprise and wanted to get things done and move on.