The .NET Framework is a very advanced framework as it has two different types of garbage collection. Like Java it is able to remove objects that is not in use anymore without being told and do it automatically. But .NET also has another GC that Java doesn't have. It is not the normal GC that you would assume, but it is highly integrated into the WinForms framework.
This new garbage collection is a property named Tag in the Control class. This is a place where you can put any garbage into that you could use later. The Controll class will store it for you forever, which is nice when you want to have garbage lying around. So with this enhanced garbage collection, you can store all your garbage and it looks like it is good OO.
The idea behind the Tag property is to store objects for combo box and list items, which is later used when a list item is selected and the object "representing" is needed. It seems that MS has come up with their own solution to the well known Model-View-Control pattern for GUI development. What they came up with is that every GUI control needs to have a model/data, and therefore it is wise to add such functionality to the Control class. The problem is that changing the model (Tag property) does not have any effect at all, the list or combo boxes doesn't change when the Tag property is updated. It is just a place to store objects; it isn't really MVC, is it?
The thing with Java, which tries to enforce the MVC (or at least MV) it is that the GUI devloper has to seperate the model from the view (and control). With .NETs approach you most of the time end up with a Form that has several Control objects and data in one class. I thought OO was to go away from the One-File(-To-Rule-Them-All) idea and seperate code. Now that MS still lets the developers use the Tag property, they are not helping us to seperate logic from representation. And it sucks, because we developers are lazy. We really need someone standing behind our back so we code "correctly".
Once again, I'm sitting wishing that my current project was developed in Java and not in .NET 2.0, because I do not want to work store everything in one class.
Wednesday, September 27, 2006
Tuesday, September 19, 2006
OO is for suckers
Im trying to read up on .NET Forms and how they work with .NET 2.0. Im reading a quite good book "Programming Microsoft Windows Forms" by Charles Petzhold. It's a Microsoft Press book. This evening I read something that I though was quite strange. The below quote is from page 167, when the author talks about creating controls in DLLs.
"We haven't been worrying much about making classes public. It's really only an issue when you're putting classes in a DLL."
So, making classes public, private, protected, package (or whaterver its named in C#) is only good when packaging everything in a DLL. I thought it was good OO to make certain classes private, public, etc. Perhaps I was wrong to put classes in different namespaces/packages so classes cant access every other class in a project. But the good thing is that I've been enlighted, and only bother with OO when packaging everything in a DLL.
BTW, I know Im nitpicking, but I thought it was fun :)
"We haven't been worrying much about making classes public. It's really only an issue when you're putting classes in a DLL."
So, making classes public, private, protected, package (or whaterver its named in C#) is only good when packaging everything in a DLL. I thought it was good OO to make certain classes private, public, etc. Perhaps I was wrong to put classes in different namespaces/packages so classes cant access every other class in a project. But the good thing is that I've been enlighted, and only bother with OO when packaging everything in a DLL.
BTW, I know Im nitpicking, but I thought it was fun :)
Wednesday, September 13, 2006
One more nail in the coffin for Unchecked exceptions
At my current job, Im fixing bugs in a huge C# system. This system has moved from .NET 1.1 to .NET 2.0, and it was not painless but the move was considered successful. (except that resource handling has changed totally, which messes up everything, but that will be another blog) Today, Im seeing a problem with one of the components that is missbehaving when it fails to send an SMS.
The whole component (which is a stand alone service) crashes because of some unknown exception. After Ive started to investigating the problem I discover that the exception is an AbandonedMutexException. Since Im quite new with .NET/C#, I have no clue what this means. MSDN informs me that it means "In previous versions, the WaitOne method returns true when a mutex is abandoned. An abandoned mutex indicates a serious coding error. The exception contains information useful for debugging.". The exception is new for .NET 2.0 and is there to "help" developer.
So, now we have a service/component that works fine in the old .NET 1.1 but can potentially crash in the new environement. Even if there is a "serious" coding error in the product, it has worked as it should for at least 2 years. But now MS wants to "help" their developers to write better code, but the problem is that they did not tell the developers that something happened. This would not happen if C# had checked exceptions, because this would have been caught when compiling with .NET 2.0. Now it was caught by "misstake" and could have been shipped if I didn't do something wrong to provoke the error. Sure MS will help the people who is developing new software, but they just made it harder to maintain software.
I havent still made up my mind about Checked vs Unchecked exceptions. But I believe that if C# had Checked exception this problem would have been caught when moving to .NET 2.0 and not 6 months later. It was impossible to test every part of this huge system when the move was made and therefore it passed. It has come to my understanding that coding with Unchecked exceptions means catching unnamed exceptions here and there. In one component I saw 120 catch statements, 12 was for named exceptions and the rest was just "catch(Exception)". That is not handling an exception, that is hiding an exception from reaching the user or crashing the application. For me catching unnamed exceptions all over the place is bad code.
The whole component (which is a stand alone service) crashes because of some unknown exception. After Ive started to investigating the problem I discover that the exception is an AbandonedMutexException. Since Im quite new with .NET/C#, I have no clue what this means. MSDN informs me that it means "In previous versions, the WaitOne method returns true when a mutex is abandoned. An abandoned mutex indicates a serious coding error. The exception contains information useful for debugging.". The exception is new for .NET 2.0 and is there to "help" developer.
So, now we have a service/component that works fine in the old .NET 1.1 but can potentially crash in the new environement. Even if there is a "serious" coding error in the product, it has worked as it should for at least 2 years. But now MS wants to "help" their developers to write better code, but the problem is that they did not tell the developers that something happened. This would not happen if C# had checked exceptions, because this would have been caught when compiling with .NET 2.0. Now it was caught by "misstake" and could have been shipped if I didn't do something wrong to provoke the error. Sure MS will help the people who is developing new software, but they just made it harder to maintain software.
I havent still made up my mind about Checked vs Unchecked exceptions. But I believe that if C# had Checked exception this problem would have been caught when moving to .NET 2.0 and not 6 months later. It was impossible to test every part of this huge system when the move was made and therefore it passed. It has come to my understanding that coding with Unchecked exceptions means catching unnamed exceptions here and there. In one component I saw 120 catch statements, 12 was for named exceptions and the rest was just "catch(Exception)". That is not handling an exception, that is hiding an exception from reaching the user or crashing the application. For me catching unnamed exceptions all over the place is bad code.
Aftermath
Sure, I found the problem. It was not a big one, and is definetly not a "serious" code error that could have horrendous effects. Yes, it was a coding problem. The problem is that it could have reached the customer, and in my eyes MS played a major part in provoking the error that could have reached the customer. Bad PR for the company, no PR change for MS. tsk, tsk, tsk.
Wednesday, September 06, 2006
Label is not JLabel, or Why wont .NET make my job easier?
Once again, I'm struggling with C# .NET 2.0, and finding out that .NET isn't really doing my job easier. My job as a software developer should not involve re-inventing the wheel every time I develop software. MS has always being good on creating tools that are simple to use and build simple things. But every once in a while I see cracks in the facade, sure it is simple to use but it is so much harder to do something advanced.
By "advanced" I mean in this particular case that I want to have a control that displays an icon and a text next to each other. A simple label that has a text AND an image. In Java, it is quite simple; create a JLabel and set horizontal position with setHorizontalTextPosition(). This has existed forever in the Swing framework, and Sun thought of it from the begining. Simple and "advanced".
In .NET it is not quite so simple; my first try was to use a Label for the text and image. The class has both a Text and Image property, so I thought I could set the text and image and it was done.. But unfortunately the control does not have a property to set a alignment relation between the image and the text. So if I set the image and text, the image will be placed behind the text and it is not very pretty. If I set the alignment of the icon and text to Left and Right, the control will still have the image behind the text but now the text looks like crap as it is right aligned. So the result is, I can either set the text OR the image; but not both. C'MON this isn't really advanced, is it?
Last week I had the same problem with a button, but (credit to MS) they actually have implemented a TextImageRelation property that fixes this "problem". The interesting part is that it was introduced in .NET 2.0, so I wonder how people managed to create a button that has text AND an image before December 2005. And the other question is why didn't they think it through and thougt of other .NET Controls that could have this problem and fixed those as well? I got the answer for you, "Because they don't think"
What is the real solution to this problem? Adding a new Label with an Icon, develop my own control?
By "advanced" I mean in this particular case that I want to have a control that displays an icon and a text next to each other. A simple label that has a text AND an image. In Java, it is quite simple; create a JLabel and set horizontal position with setHorizontalTextPosition(). This has existed forever in the Swing framework, and Sun thought of it from the begining. Simple and "advanced".
In .NET it is not quite so simple; my first try was to use a Label for the text and image. The class has both a Text and Image property, so I thought I could set the text and image and it was done.. But unfortunately the control does not have a property to set a alignment relation between the image and the text. So if I set the image and text, the image will be placed behind the text and it is not very pretty. If I set the alignment of the icon and text to Left and Right, the control will still have the image behind the text but now the text looks like crap as it is right aligned. So the result is, I can either set the text OR the image; but not both. C'MON this isn't really advanced, is it?
Last week I had the same problem with a button, but (credit to MS) they actually have implemented a TextImageRelation property that fixes this "problem". The interesting part is that it was introduced in .NET 2.0, so I wonder how people managed to create a button that has text AND an image before December 2005. And the other question is why didn't they think it through and thougt of other .NET Controls that could have this problem and fixed those as well? I got the answer for you, "Because they don't think"
What is the real solution to this problem? Adding a new Label with an Icon, develop my own control?
Subscribe to:
Posts (Atom)