RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The Two Faces of .NET : Page 3

Developing applications with .NET sometimes feels like I'm working with a split personality. Now that .NET has been around long enough, I and many of you undoubtedly have had a chance to put .NET through its paces with some real applications rather than just little samples. For me, the .NET learning curve has been a long one. I find working with .NET both exciting and frustrating at the same time. Talking to other developers I think I'm not alone.

The Obnoxious
The UI designers themselves are another major cause of frustration. Both the Windows Forms and Web Forms designers have quirks that make them less than ideal to use on a regular basis. The designers are two-way code generators. Code is good—you can look at it and understand it. But the designer's code can be a hassle because if something happens to go into the code that the designer can't deal with, your form goes kaput. I've had at least five forms blow up on me when the Form designer decided that all contained controls no longer exist. The code is all still there, and the form compiles and runs correctly, but the designer doesn't show any of it. Saving at that point wipes the missing designer controls from the source file. Ironically, it's the form designer's own generated code that caused this problem. In many cases the problem was fixed by moving around the Windows Forms generated code section immediately following the property section, but figuring that out took quite a bit of digging and help from somebody who'd had this problem before. Again—hours and hours of wasted time.

Rather than using real containership, forms use code generation to hook up events and property settings. The designers have problems if you copy controls around—try copying a button with some code attached and paste it onto another or the same form. You can't keep the code with the control! Or try to rename a control after you've added some code to it. The events you implemented retain the original name like Button1_Click rather than update to the control's new name. Code generation can bite you in a variety of ways like this.

Visual HTML editing in the development environment has been Microsoft's weakest spot for years. Fixing it could provide the biggest productivity boost in Web application development.
Web forms don't fare much better. The Visual Studio .NET HTML designer is incredibly tedious to work with if you need to create or manipulate HTML manually. It offers IntelliSense but no additional help for templates. And the Visual Studio .NET HTML designer is even worse at manipulating anything but simple HTML in design view. For example, try to resize an HTML table with the designer—you might get lucky and pull on the right handle to stretch a cell or you might stretch the entire table. Or add a column. For a tool that puts such a heavy emphasis on the Web developer, the HTML designer is almost embarrassing. You can't even select a control in the visual designer and switch to HTML view and edit the HTML code quickly. Instead you must find your place using the Search dialog or manually look through the document. How hard could it have been to implement this simple feature? Luckily other companies have figured out how to build an HTML editor that lets developers work both in visual and code modes simultaneously, but you can bet the majority of developers torment themselves with the VS editor. Visual HTML editing in the development environment has been Microsoft's weakest spot for years. Fixing it could provide the biggest productivity boost in Web application development.

Both the Windows and Web form designers suffer from the twitchy User Interface of the Property Sheet. When you set properties flipping from control to control, the focus doesn't stay on the same property. Or when you click onto a property in the property sheet the field is not auto-selected to simply overtype the text. Instead, you have to use the cursor keys or mouse to position the cursor when practically all of the time you simply want to write in a new value. The property sheet can't be navigated by keyboard easily either—you can't use up and down keys to move to the next property while in the value of a property. You can only navigate from the text field. In the editor, the various alignment tools are next to useless due to the scale and positioning of the various controls. Getting controls to line up requires that you manually move the controls even though there are supposed to be alignment tools. These are little issues but they cause lots of wasted time during everyday development.

And let's not forget about the Windows Forms UI itself—the stock controls aren't XP Themes aware, and the way stock menus and toolbars look seems to come out of the last century. A "state of the art" tool should support the latest Windows look and feel, but .NET doesn't. Menus don't support images natively (you have to owner draw them), and you can't move toolbars. The menu designer is easy to use, but it requires a new event handler for every single menu button—there's no central handler event you can pipe selections through. The Tree and Listview controls seem slow and flickery and have odd behaviors when you use default images. They don't have events you would expect like NodeClick().

One of my biggest complaints is the lack of a built-in Web Browser control. The Web Browser control has become a mainstay of the modern user interface, but it mysteriously wasn't provided as a managed control. Instead, every time you want to use a Web control in your application you have to import the ActiveX control. This causes several problems: You have to use object variables for most parameters on events and properties, and you have to pass variables by reference. Since the ActiveX control was based on optional parameters, you have to pass complete parameter lists which .NET requires when calling COM components. What's worse is some important events like BeforeNavigate2—which is needed to capture clicks in the Web Browser control—don't fire. Although that's a bug in the ActiveX control, this still makes using the control in .NET very limited. Microsoft has acknowledged this bug in the control for over 2 years but they haven't fixed it. Several third parties have created more complete COM wrappers for the control that work more reliably, but it's non-obvious to find these solutions and you're likely to find these solutions only after a futile attempt at getting the ActiveX import to work correctly. Using ActiveX controls in this fashion also poses a security problem since ActiveX controls are unmanaged code. You'll run into security issues in applications that run over the network unless you adjust the security.

The .NET documentation in MSDN is a major issue as well, especially for more advanced topics. I've been working on an application that implements the ASP.NET runtime in a desktop application (an article on this topic appears in this issue of CoDe Magazine), and trying to find information on this topic has been very painful. Ultimately, with the help of several developer papers and a decompiler I was able to figure out what was happening behind the scenes when a new Application Domain is created for hosting the ASP.NET runtime, but this is not documented anywhere in MSDN. Most methods that are related to this topic are documented with a single line in MSDN that say little more than the name of the method name with spaces in it. No example, no explanation of when this or that event would fire and what gets passed. I can't tell you how much time I've wasted searching for information in MSDN that ultimately wasn't there or is utterly useless. It seems to me that a policy is needed at Microsoft to document functionality as the specs and the code are created, not afterwards when nobody is around to explain how the functionality is supposed to work. Without adequate documentation .NET can be a huge time sink for unproductive research time.

Many things in .NET seem to be designed without having been thought all the way through, especially in the Windows Forms engine where many features are implemented in a dead end way that can't be extended without throwing everything away and starting over. For example, .NET can't handle menus with a single event handler, but you must add a method for every single menu option. This yields extremely unwieldy source code for even a moderately sized menu. The Help provider has no generic events that you can capture when Help fires, which means you can't hook any external Help tools for editing Help. To fix this you need to completely throw out the built in behavior and built your own handlers or resort to third-party tools that get it right.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date