01.31To .Net or Not to .Net - by Geoff Evans
Some comments to my previous post were asking why we decided to switch from .NET to wxWidgets. Here was why we decided to switch:
* The .NET Forms Designer was very unstable for us. Editing code that gets parsed back into the forms designer lead to forms that could no longer be edited in the designer. Cryptic internal exceptions when trying to edit forms were difficult / impossible to troubleshoot. Sometimes the form would appear but silently remove user controls placed within it. We ended up having to hand code all our UIs because the forms designer would inevitably break our layouts. This was especially true with user controls and controls loaded from assemblies outside Windows::Forms.
* Windows::Forms is buggy and lacking features (Multi-select tree view anyone?). We encountered bugs that we had to workaround that compromised our user experience because Windows::Forms is closed source (why is that anyway? we couldn’t think of a single good reason for Microsoft to keep that source close to their chest). wxWidgets comes with full source and we have made fixes and added features that have been picked up by the main line. wxFormBuilder is a superior solution to this problem and its fast and extremely stable.
* We like to tightly integrate code between our game runtime and tools, and we see this as key moving forward with the next generation. This means we have native C++ code that we wanted to call from .NET (and sometimes *god forbid* vice versa!). This lead to managed C++ (C++/CLI) wrapper classes that ended up creating more work for us. Using .NET made it feel like we had less choices rather than more choices when it came to organizing our code (you must use DLLs), integrating code (especially with intricate data structures), and deploying our tools (.exe.manifest and .exe.config madness just to use an assembly in another folder). All of these things are easier with wxWidgets and native code and we are able to spend less time troubleshooting .NET idiocy and more time creating what our users want. Also, mixed-mode debugging is no fun and gathering callstacks from a crashing tool across the managed/unmanaged barrier isn’t really possible or supported by .NET.
* We already had a good C++ reflection system and data-driven property system (they are in Nocturnal). This gave us type checking, serialization, automatic type conversion, and property sheets without using .NET. These were the killer features to us for using .NET, and having our own solutions to these features that gave us the freedom to ditch .NET for our level and asset editor in about 1 man month.
* Embedding technology based on .NET as a plugin in another product (like Maya) is impossible and/or dangerous and/or difficult. This goes back to what I said about having more choices rather than less choices. wxWidgets integrates with Maya very easily.
* Getting support from Microsoft is a joke. The community is a better source of support than contacting Microsoft directly. Several of our tickets we closed in their tracking system (without a real resolution that we could use) because they were fixed in ‘their internal builds’. They just hung us out to dry on a lot of things. If we are going to be paying for a development environment and UI toolkit then it either needs killer support or it needs to be open source so we can fix it ourselves. Getting stuck at the mercy of a company that won’t release service packs to fix your bugs and makes you pay for them in the next product cycle that contains little in the way of other benefits is immensely maddening. Also, the public hotfix directory is a joke… They need to make fully tested service release so we can get on with our lives!
* wxWidgets is cross platform. I like to believe that someday we (as a studio) won’t be as dependent on Windows as we are now, and wxWidgets gives us strategic room to grow in this regard. The Linux and Mac ecosystems have a lot of things that are desirable compared to Vista/Windows7. Not having to reboot your server farm every 2 weeks due to kernel memory leaks in the 32 bit emulation layer is one example 
Ultimately switching to wxWidgets simplifies everything in our tools pipeline, makes refactoring and making major changes to key subsystems easier, and makes our tools easier to deploy to our users. It was an easy choice to make, and we haven’t looked back since. We still have several small tools that use .NET and going back to work on them and fix bugs is no fun after switching to wx.
I think, that you shouldn’t abandon .net from the wrong reasons. Try the WPF and you will be enlightened.
January 31st, 2009 at 9:10 pm
That’s a tough sell since we switched two years ago
Just curious though, what are the wrong reasons?
January 31st, 2009 at 9:26 pm
If you were having those problems with the .Net Windows Forms designer then you were doing it wrong.
Also, .Net has this little thing called 3rd party components. Maybe you’ve heard of them? DevExpress, Telerik, Infragistics…
January 31st, 2009 at 2:35 pm
> If you were having those problems with the .Net Windows Forms designer then you were doing it wrong.
That could very well be, but its not like there are many ways to use it. Given that, the forms designer is either A) Not scalable or stable or B) Not straightforward to use. Either way there is a good reason not to rely on it. People in the support channels we had were seeing the same problems we were, and solutions were hard to come by once your form became so complicated it wouldn’t load.
As far as your appeal for using 3rd party resource to work around problems with .NET/VS, I don’t buy it. They can help, but not fix the problems endemic in the core of the platform and dev environment.
Don’t get me wrong, .NET/VS isn’t broken… they just wouldn’t scale for what we wanted to use them for. .NET/VS is awesome for prototyping and developing simple applications. Its a fantastic platform for that. We just needed a platform that could take use beyond that.
January 31st, 2009 at 2:49 pm
.Net development based on drag & drop so, if you need more you have to switch platform.
January 31st, 2009 at 3:17 pm
Just out of curiousity, were you guys using WinForms prior to .NET 2.0? I had tons of issues with the designer in the VS2003/.NET 1.1 days, before partial classes in C# allowed the designer generated code to be extracted to a second file. Then again, I haven’t done as much WinForms development since then.
Anyways, thanks for the inside view. Keep the articles coming!
January 31st, 2009 at 3:41 pm
Great job, Wayne and ChaosSpeeder, your amazing comments contribute absolutely nothing.
January 31st, 2009 at 3:46 pm
> Just out of curiousity, were you guys using WinForms prior to .NET 2.0? I had tons of issues with the designer in the VS2003/.NET 1.1 days, before partial classes in C# allowed the designer generated code to be extracted to a second file. Then again, I haven’t done as much WinForms development since then.
Yeah, we were using it back then, and the problems were definitely worse with 2003. Before 2005 came out we decided that C# was making our native/managed code sharing situation worse since it required a Managed C++ dll to wrap our native APIs. We used a code conversion tool (Instant C++) to covert all of our C# to C++/CLI right when 2005 came out.
C++/CLI was a big win over C# for us. It was (at the time) the best compromise of CLR features and code interop. We did completely miss out on the partial class support though. Needless to say the Forms Designer didn’t survive that automated code conversion, but we were used to doing all the GUI layout by hand at that point.
January 31st, 2009 at 3:53 pm
Why wxWidgets??? Qt is far superior and will be released under the LGPL in the upcoming version.
January 31st, 2009 at 4:25 pm
> Why wxWidgets??? Qt is far superior and will be released under the LGPL in the upcoming version.
We ported from .NET two years ago. The windows version didn’t even go GPL until after we ported to wx.
January 31st, 2009 at 4:30 pm
Whoa, very different experience than me for .Net. I’m a tools architect for Ubisoft, and we switched 4 years ago to .NET for all our tools development across the board on the entire pipeline, and it’s going really REALLY well with .NET for us. Compared to our previous C++ based toolset pipeline, we’re able to produce tools quicker and the tools are more stable and flexible.
We do all our UI in the Windows Forms Designer. Sometimes programmers will break the designer, but we quickly correct these problems because having a working designer is very useful and saves a lot of time. The two main advice I can give not to break the designer is to never touch the code in the .Designer.cs files, and avoid calling things that might not be initialized from your control/form constructors because that code is called by the designer.
We use many 3rd party controls, I’m a big fan of everything from Divelements: SandDock, SandBar and SandGrid (which allows multi-select tree views with columns). We also use the free TreeMap control from Microsoft Labs, and Flowchart.NET for diagram views. In my experience, most of the .NET 3rd party libraries are really easy to use.
For deployment, I don’t use any of the setup or deployment technologies from Microsoft. I don’t use the GAC either. I just copy my executable and the required DLLs in a folder.
As for the “troubleshooting .NET idiocy”, I’ll trade that any day than to try to debug C++ stuff like STL, templates or memory leaks. Or maybe its cause my C++ is getting rusty after coding in .NET for 4 years.
That’s probably the reason I try to avoid Managed C++ as much as possible. There are other techniques than Managed C++ you can use to communicate between .NET and C++.
I’ve never tried to get support from Microsoft, I never even considered it actually. I usually find my .NET answers pretty quickly from the community.
One thing I found very hard to do in Windows Forms is to unit test the UI. I’ve been reading a lot about WPF recently (Windows Presentation Foundation), and I think it’s gonna replace Windows Forms when it matures a bit more. WPF makes it much easier to do custom UI things like having custom list view items, makes it almost effortless to create controls like a Thumbnail View. WPF also makes it easier to unit test your UI because of its design that encourages the MVC pattern.
I just wish .NET was cross-platform. Visual Studio and .NET is the only reason I spend time away from my beloved Mac
January 31st, 2009 at 4:39 pm
> Whoa, very different experience than me for .Net.
Great to hear about your success with it. I suspected that there were folks out there that were making it work for them
I personally prefer the C++ challenges you talk about 
I think that with discipline they are very manageable. Data breakpoints and Microsoft’s Debug CRT help a lot.
Ultimately we want to make our tool set as rigorous about memory usage and allocation as our game is. Its going to be an interesting challenge! The .NET GC works well, but at the time we didn’t know of any tools to help track down which object references were preventing objects from being reclaimed. Does such a tool exist? I suppose that it really didn’t burn us too much though…
You you ever tried Mono? I am skeptical about it, but the Unity engine and others have used it pretty successfully I think.
January 31st, 2009 at 4:52 pm
Newb programmer cries. Film at 11.
January 31st, 2009 at 5:32 pm
> Newb programmer cries. Film at 11.
LOL
January 31st, 2009 at 5:34 pm
GTK is cross-platform too and does a better integration than wxWidgets really. It’s Glade designer is more mature too.
But the choice has been made
January 31st, 2009 at 5:54 pm
> GTK is cross-platform too and does a better integration than wxWidgets really. It’s Glade designer is more mature too.
Yeah, once one decides to go for an open source toolkit there are a ton of good choices. wx, GTK, and QT all have rich offerings.
I used GTK in college and it worked well on IRIX, but its event model wasn’t as versatile as wx’s is now. I am sure GTK come a long way but we decided to go wx because it had a rich set of community controls (wxAUI is excellent for IDE-style GUIs). Static event tables, dynamic event handlers, and pushing event handlers all give programmers interesting ways of fielding user interaction. Its learning curve is a little steep (especially sizers), but the wins are big.
I cannot stress enough how nice it is to have full source of your entire widgeting platform.
January 31st, 2009 at 6:07 pm
I developed some simple apps for in winforms using .net 2.0. I stuck to 2.0 to give me the largest installed base (anything after 2.0 is a huge bloated pig) while getting all the cool features in C# 2.0. I was able to get LINQ features with LinkBridge.dll.
Having been in asp.net land for so long, I assumed that the designer would be slow and buggy. I always did my layout manually in the web forms. I was disappointed (but not shocked) that the form designer for win forms was so buggy. I ran into all kinds of problems and resorted to manual layout of the forms.
My biggest problems came from grids and user controls. I had much the same experience that you did. Glad to know I wasn’t alone.
January 31st, 2009 at 7:11 pm
> Great to hear about your success with it. I suspected that there were folks out there that were making it work for them
I personally prefer the C++ challenges you talk about 
I think that with discipline they are very manageable. Data breakpoints and Microsoft’s Debug CRT help a lot.
Data Breakpoints is something I wish there were in .NET. However, in general most of our data is wrapped in a property, so you can put a breakpoint in the property’s “set”. Another thing I forgot to mention that is a major advantage in my mind for .NET is IDE enhancements like Resharper for refactoring and quick code exploration. It makes it a breeze to explore and update your code reliably. Our engine programmer’s use Visual Assist for C++, but it seems to have more trouble with very a very large/complex C++ code base.
> The .NET GC works well, but at the time we didn’t know of any tools to help track down which object references were preventing objects from being reclaimed. Does such a tool exist?
We use JetBrain’s dotTrace to fix performance issues. It works really well for that. It can also be used to track down leaks, but I haven’t used it much for that, so I can’t say if its good or not. We haven’t had too much issues related to leaks.
One annoyance with .NET I forgot to mention earlier is the C# compiler. On very large C# solutions, the compile time can go up exponentially. I think it’s due to the fact that the C# compiler puts all your .cs in a bunch and compiles them together. Typically, this means the compilations are extremely fast. However, at a certain threshold when there’s too many .cs file in the project, the compiler slows down drastically. But after testing the same projects on Visual Studio 2008, the problem seems to have finally been fixed.
January 31st, 2009 at 7:31 pm
> Having been in asp.net land for so long, I assumed that the designer would be slow and buggy. I always did my layout manually in the web forms. I was disappointed (but not shocked) that the form designer for win forms was so buggy. I ran into all kinds of problems and resorted to manual layout of the forms.
A lot of people seem to have trouble with the Windows Forms designer. I can say that in my toolset, every single editor, user control, custom control working properly in the designer (and there’s hundreds of them). Some of them are quite complex editors with docking panels, menus, and a hierarchy of embedded user controls.
Here’s some tricks I’ve learned over the years that might help you guys out to make the designers work best:
* Often, the designer is broken not because of your code, but just because Visual Studio is dirty/buggy and needs a reset. I first try a couple of things that sometimes get it working again: First, I do a “Close All Documents” and try to reopen the form. If that doesn’t work, I close and reopen the solution. And lastly, I clean up all the bin/obj folders using a batch file (works better than doing a “Clean Solution” believe it or not).
* Then its time to investigate your own code. Make sure the embedded user controls work in the designer first (before trying to check the parent forms).
* You should avoid calling code that only makes sense at run time from your user controls constructors or any property setter that’s a public and serialized property. For example, loading data from a database or a file. You don’t want that to run in the designer and cause exceptions. I shield that kind of code away with a static variable that I set in my Main method (e.g. Application.DesignerMode = false). Add [DesignerSerializationVisibility] attributes to prevent your properties from getting serialized by the Windows Forms designer.
* If after all this I still can’t figure out why the designer does not work, you can use Visual Studio to start and debug Visual Studio! Make sure you catch exceptions when they are thrown, and try opening your form in the designer. Visual Studio should catch the exception in your code.
January 31st, 2009 at 7:58 pm
Geoff, I totally agree. It’s stuff like this, the absolute pain of developing and deploying apps on Microsoft that caused me to say “fuck it” back in 2005. I applaud the rocket-scientists that choose to follow Microsoft’s convoluted path, but I opt for simplicity in my life. I moved my way to Python and Django, and I can honestly say life is good. I actually enjoy solving problems again, not fighting with my tools.
Cut your losses and never look back!
January 31st, 2009 at 11:23 pm
I’ve had nothing but an awesome experience with .NET but it’s been mostly for RAD. It’s great to quickly(< 1month) put together a gui editor for something. Not sure about big scale projects though but I know a few who simply love it and have done some awesome applications with it.
January 31st, 2009 at 11:49 pm
Oh and .NET is quite awesome in most aspects IMO, but aren’t we talking WinForms here? There’s a big difference between .NET and WinForms.
January 31st, 2009 at 11:51 pm
I also believe that WPF might be the way to go.
We started to develop several new tools in our studio using WPF/.NET 3.5, and results are very promising so far.
February 1st, 2009 at 2:28 am
After a long .NET career, I vote “NO” on this technology.
I’ve worked extensively with just about every flavor of .NET: WinForms, ASP.NET, WPF.
The designer support is universally bad. WPF is not an improvement. (I’ve used both Expression Blend and the “Cider” designer)
Don’t use .NET if you want to draw your GUI in a designer.
The language has grown out of control. The work Microsoft is doing on .NET 4+ is much too theoretical to ever make your life any easier.
The things I liked about .NET originally were:
1) It was small enough to really understand
2) It seemed like a plausible “RAD” tool
3) It pared down much of the OO jargon that trashed C++
All that’s fallen by the wayside.
February 1st, 2009 at 8:03 am
You should consider giving Flex/Air a look. RIA feel to applications with analogous to HTML/Javascript/CSS (minus the compat issues) for simple stuff and full component model with local embedded db for online/offline with syncing support through Lifecycle/BlazeDS.
Full support for binding grids, forms, etc and XML is a first class member of language, making interaction with REST services (write your server side in anything) a breeze.
February 1st, 2009 at 8:23 am
I think the root of your problems can be found in your first paragraph:
“* The .NET Forms Designer was very unstable for us. Editing code that gets parsed back into the forms designer lead to forms that could no longer be edited in the designer. ”
You don’t edit the designer files. Doing so is very bad, and very wrong.
The beauty of partial classes means that all of your custom code goes in a different file. If you are editing the file that the designer users it is going to crash, in a big fat ugly way.
February 1st, 2009 at 9:15 am
Adding to “flexaholics” comment…
This might sound odd, but have you considered ditching Forms altogether?
We had to implement a forms application within a deadline of just a few days. The forms route turned out to be a bit impractical. Especially considering the number of developers involved.
In the end, we moved away from a forms app altogether and implemented a web/webservice based solution. It turned out to be pretty much our own in-house Cloud app in a way.
I.E. An Intranet machine with connected a server-side control-app/server. This also allowed employees to use their favourite browser (Mozilla, Opera, IE etc…). And there’s also the possiblity of remote access using a VPN into the network as well as cross-platform (as far as employees are concerned) compatibility as there’s nothing to install locally. As a side benefit, the app was very easy to customise (UI front end) for mobile devices.
These are rather to implement (securely) via Forms alone. Also you’re already starting in a fairly limited way regardless of which forms platform you choose.
February 1st, 2009 at 11:22 am
> You don’t edit the designer files. Doing so is very bad, and very wrong.
When we were really digging into Windows Forms in VS2003 it was really easy to just add event handlers via the events view in the properties. Perhaps that’s bad form and a slippery slope, but if that’s really the case then Microsoft shouldn’t have even built that feature into the tool. Adding event handlers within the Designer’s code files is main line work flow in visual studio, so I don’t buy the argument that we were doing it the wrong way since it was how the development tool was designed to be used.
Also, this is before C# partial classes existed and Forms design is even worse in C++ with Managed Extension (C++/CLI). I don’t think its fair to equate Windows Forms Designer to C# anyway. The Forms Designer is meant to support C#, VB, and C++/CLI.
February 1st, 2009 at 10:33 pm
VS2003? Eek. Your mileage may vary… With partial classes and VS2005/2008 I don’t believe you would be experiencing any of these issues if used properly.
February 2nd, 2009 at 7:46 am
> VS2003? Eek. Your mileage may vary… With partial classes and VS2005/2008 I don’t believe you would be experiencing any of these issues if used properly.
Yeah, I am sure things have improved. Microsoft does eventually get things right once they totally screwed the pooch
Its frustrating it has to be that way though. Having to pay for fixes to things like this is a major annoyance.
Is there partial class support in C++/CLI in 2005/2008?
February 2nd, 2009 at 9:00 am
I have been programming on console for many years now and I never had the chance to write a tool in .Net. Too busy with the C++ runtime code to do anything else. So I tend to favor C++ code that is controlled by the developer. My personal experience with GUI programming on the Windows platform has never been very productive. So, I am all for C++ and whatever GUI API that is easy to use and gets the job well done.
February 2nd, 2009 at 3:23 pm
To .Net, would be my response.
But that’s not really here or there. Any development team should go with what they know and what will work best for the project.
I think 2003 .Net 1.1 days left a bad taste in your mouth with their terrible support for managed C++ cross layer support. But those days are long gone from my experience. It is much better these days, but obviously there’s plenty of room for them to improve.
When it comes down it for me, yeah, the GUI designer kind of sucks some days, but there are plenty of guards to keep it working, but you will need to dirty up your GUI a bit with DesignMode and some other ones for WPF. Personally, most good UIs are so customized and dynamic that any UI designer is not really going to help you all that much. If you’re still getting crashes, just attach one Visual Studio instance to another and debug the UI code that is getting run that shouldn’t be.
This is fairly recent, but stepping into Microsoft’s Forms/WPF code is now possible, which can be helpful debugging some problems.
C# as a language is just far superior to C++. I can do things in C#/.Net that would just be a nightmare to attempt in C++. With it I can turn out tools faster and at a higher level of quality for the art staff than I could if I was using wxWidgets and C++. It’s also much easier to debug the applications and keep them running in my experiences with .Net. Also, lets not forget how easy it is to multithread a C# application. Which can be so useful when trying to make a responsive UI for our users.
I would kill for a good multiselect treeview though
February 2nd, 2009 at 8:20 pm
@Nick
C# as a language is just far superior to C++.
I hope you realise what you’ve done!
Well, I’m going to step aside and await the inevitable re-kindling of the language war.
February 2nd, 2009 at 10:20 pm
> I would kill for a good multiselect treeview though
There is one: SandGrid by Divelements. I used to use a combination of ListView, DataGrid, TreeView, Xceed.Grid in my app. Now I’ve replaced all of them with SandGrid. It’s very efficient, and very easy to use. Not free though, but well worth the price in my opinion.
February 3rd, 2009 at 5:11 am
@eksith
Mwahahahahahahaha
February 4th, 2009 at 4:12 pm
We once experimented with Adobe Flex/Air for our content editors. Designing the forms was a breeze: the xml-structure falls naturally with the GUI structure and they can easily be referenced in the AS3 code with full IDE support. Moreover, you can always fall back to manually programming the GUI layout (which is just like coding HTML… only much simpler) with much ease. What’s nice too is that it’s cross-platform.
However there are three problems: no 3D, performance and typing. The 3D issue is understandable, the performance is horrible on large data sets and the lack of typing in collections makes handling complex data structures difficult.
So eventually, we fell back to our original plan of using Qt. Though, one thing that makes wxWidgets better than Qt is that it doesn’t need another preprocessor which makes setting up the build environment and system a lot easier.
February 6th, 2009 at 6:32 am
> Though, one thing that makes wxWidgets better than Qt is that it doesn’t need another preprocessor which makes setting up the build environment and system a lot easier.
This is huge IMO. I hate anything other than the compiler parsing my source. We have a parsing system for our game data and almost everyone hates it with a passion. I hear GCC is going to be working on a plugin API, which would be cool. It would just be a matter of Qt (or our system) having a plugin that dumps meta-data directly out of GCC.
February 6th, 2009 at 9:06 am
What is wxWidgets? I hear of a new programming language every other day. I do hope there are capable people backing these technologies.
February 8th, 2009 at 9:58 am
@Joy
vxWidgets was originally called wxWindows and has been around since 1992. It’s hardly “new”.
And C# has been around since 2000, making it nearly a decade old.
BTW… I can’t be sure if your comment was legitimate ignorance or a cleverly disguised spam link.
February 9th, 2009 at 1:29 am
Geoff, I think you are being slightly disingenuous in this post. It reads well, and is certainly good flame bait, but in reading the comments it comes clear that you were using an older (although certainly not old) version of WinForms and that you have tried to the newer versions.
I work on a team that has successfully used VS2005 with .NET 2.0 to produce a number of relatively complex UIs.
Good job in getting lots of comments and discussion, less good job on giving good context.
February 9th, 2009 at 6:03 pm
Complex UI’s are one thing. User-friendly ones are a totally different one however
February 9th, 2009 at 6:07 pm
@VadimP. I couldn’t agree more
Regardless of their friendliness the UIs we’ve made are relatively complex and written using the form designer in VS2005.
February 9th, 2009 at 6:10 pm
> but in reading the comments it comes clear that you were using an older (although certainly not old) version of WinForms and that you have tried to the newer versions.
I think you may be missing a key word there… it doesn’t quite seem like a complete thought.
Thank you for the frank feedback. What do you feel is disingenuous about it? I was definitely trying to be candid. My motive was to enumerate why we (Insomniac) decided to move away from .NET/WinForms since people were immediately interested in the comments to my previous post. I guess I am not seeing where I got off track. Perhaps its just a misleading title? Perhaps the title implies the article was more even handed that it is? It would be hard to do so because so many different studios have different requirements and approaches. It is an opinion piece, but perhaps I need to figure out a way to make that more clear within the context of this blog.
Thanks again Ben,
February 9th, 2009 at 6:27 pm
@Geoff. Gak! I hate it when my brain outpaces my fingers. It should have read:
“were using an older (although certainly not old) version of WinForms and that you have NOT tried to CREATE TOOLS IN the newer versions.”
Sorry for the confusion/appalling grammar.
I realize it is an opinion piece and it certainly made me sit up and think because 1) I run a tools team using .NET and 2) I have a LOT of respect for Insomniac (your games, your tech and your attitude to sharing). I would have liked more context such as the versions of WinForms and .Net that you were using. It became clear in your responses to the comments what the context was but I would have liked to see it in the post itself.
All in all, keep up the good work, we need more places to talk about how to make tools.
February 9th, 2009 at 6:43 pm
> It became clear in your responses to the comments what the context was but I would have liked to see it in the post itself.
I see, that makes perfect sense
Thanks again for the feedback.
Cheers,
February 10th, 2009 at 8:48 am
The talk about how third party components address lackings in Microsoft products and the lack of a multiselect treeview reminds me of what I used to do before I became a game programmer. My first job out of university back in 2000 was web programming, specifically ASP pages running within Microsoft’s web server IIS.
There were lackings in the functionality available, the case in point for me was sending an email. It was such a basic functionality that seemed applicable to a wide range of situations. Yet, in order to do it, you needed to license a third party component. It wasn’t the only basic functionality missing either.
The impression I was left with was that Microsoft intentionally left gaps in functionality and did not fill them, in order to seed a third party component market. This intention (or giving the benefit of the doubt oversight) is really to their detriment. With a variety of tools at the ready disposal of a programmer, it facilitates the creation of better products and that makes the tool used to make them look better.
In any case, nine years later, it is interesting to know that people are still thinking: “If we are going to be paying for a development environment and UI toolkit then it either needs killer support or it needs to be open source so we can fix it ourselves”
February 28th, 2009 at 2:34 pm