Archives
-
Splitter Control with Drag Handle
Here's some code straight from my work on GhostDoc that just has started again with new energy after a pause in the weeks before Christmas.
I think most of us will agree that Splitter controls are really cool. Once you have learned the basics, there's virtually no excuse not to use them in your dialogs. The splitter itself is invisible, but in most cases users can easily guess where a splitter might be, and when the mouse pointer is over the splitter area, the pointer changes its shape indicating the direction in which the splitter can be moved:
In some situations the use of a splitter is not that obvious:
Would you expect the summary field to be resizable? In this case, it would be better to give the (first-time) user a hint showing a drag handle, e.g.:
I needed a splitter like this for GhostDoc, fortunately writing one is extremely easy. Basically, all I had to do is to derive a new class from System.Windows.Forms.Splitter and override the OnPaint method. In case you're interested, you can download the source code and a small demo project here.
Note that this control is ripped directly from the GhostDoc project and thus is not highly configurable. I changed the default docking to "top" matching the typical use case (other docking is still possible) and the thickness of the splitter is fixed. Simply regard the code as a good start for your own splitter control (e.g. if you want to change the drag handle's appearance).
-
The Power of First Impression
After months of ZIPping up the GhostDoc source files every now and then, I finally have a source code management solution running (better late than never ;-). I've built and set up a server from spare parts, mainly to be used for storing files (e.g. backups and VMWare images), on which I installed SourceGear Vault. Using SourceSafe at work, this was an obvious choice for me. Usually I don't shy away from learning new things, but this time I didn't want to invest time to learn to use a system with a different philosophy (like e.g. SubVersion).
Now I have to admit a few things: While there are quite a few things I'm really good at, I have no or only superficial knowledge when it comes to administering/configuring
- databases
- IIS
- ASP.net applications
So this is me, not wanting to invest a lot of time, and I want to install a product that
- uses a database (MSDE in my case, which I have never installed before)
- is running on IIS
- is an ASP.net application
And you know what? I got things running without any problems worth mentioning. The combination of a good installer (e.g. no editing of configuration files required) and an installation guide on the product's website with lots of screenshots enabled me to install this product. Creating a repository was also pretty easy and just a matter of minutes.
So I'm happy to report that GhostDoc is now under source control.
Maybe it turns out that I just installed the worst product imaginable. Maybe things go wrong from now on in every imaginable way. But right now I trust this product. It just feels right. From the splash screen (nice, but not too fancy) up to the help file (not really spectacular, but it was able to answer the few questions I had). Everything made good first impression.
Now there's another application I installed on the server (I will not mention the name here, as it would be pretty unfair). When I start it, I get a "SqlException: SQL Server does not exist or access denied" error message. I couldn't find what to do in the documentation, the product's website does not have a FAQ, there's no forum, only a email address I can write to. This is what I'll to, because I'm pretty sure that once things are running, the application will be what I was looking for. But I guess you agree that the first impression is spoiled.
As a developer I know that I'm completely unfair here, but as a customer (even though in both cases I don't have to pay as a single user) I don't care about being fair. Whether you like it or not, the first impression plays a vital role how users view your software.
So do yourself a favor: When you release software (even if it's just a small tool), invest enough time in what could be called "the most important minutes" of your program. After a couple of months since the release of GhostDoc, I'm happy to notice people praise the "out of the box experience". Let me tell you it didn't come easy. Things weren't perfect from a start and a lot of time and testing went into getting things right. I actually bought VMWare Workstation especially for testing GhostDoc on different system configurations (virtual machines simply rock, period). Did all the effort pay of? After all, I could have implemented lots and lots of features, so GhostDoc would produce less funny results in certain situations and would be as useful as I know it could be. But all I can say is yes, it was worth the effort. GhostDoc was downloaded a bit more than 1000 times (all versions combined) and while this may not be too impressive, I'm proud that I didn't receive a single question about the first steps. I receive bugs and feature requests regarding the text generation, people wanting to tweak things, people wanting to code their own rules, but not a single of those "I can't get it to run, what now?" questions that quickly eat away lots of time from actually developing software.
-
GhostDoc News
While work on GhostDoc has slowed down a bit, I still haven't lost my enthusiasm for this project. It has proven to be useful for me in my daily work and feedback from users has been really positive so far. Most of the feature requests I receive are already on my TODO list, which I regard as a good thing as it shows that I'm on the right track with my plans. And it helps me to prioritize the items on the list -- so don't hesitate to drop me an email with your suggestion.
Plans for 1.3.0
The most wanted feature is proper handling of "On..." methods.... Oh yeah, this will be the next rule to be implemented and I plan to include it in 1.3.0. Interestingly, every person who wrote me about the funny mess the current version of GhostDoc is producing of e.g. "OnClosing" had a different idea of what the generated text should look like. Which leads to another problem: The more text GhostDoc actually adds to a simple processing of identifier names, the more people wish to change these additional texts to their liking (quite understandably).
That's why version 1.3.0 will allow users to customize generated texts by editing template texts containing macros for dynamic content. The macros are similar to those for the pre-build and post-build steps in the Visual Studio IDE. For example, the template text for the summary of a constructor is "
Creates a new $(DeclaringTypeName.ShortNameAsSee) instance". As in Visual Studio, you don't have to type out the macro name, but can select it from a list (or, to be more exact, from a tree).Here's what selecting a macro for e.g. the summary of a property will look like this (more or less, the screen shot is from a dialog in a GUI test, not the actual addin):
As usual I won't talk about a release date; when I feel comfortable releasing 1.3.0, I'll release it ;-)
-
GhostDoc 1.2.1 released
While working on version 1.3.0, I ran across some minor issues in 1.2.0 that were pretty easy to fix. These fixes are now available in version 1.2.1.
Download: on the GhostDoc homepage
What's New:
- Fixed: Under certain circumstances, acronyms used in parameter names that are referenced in summary texts are not handled correctly (the first character of the acronym is shown in lowercase).
- Added: Better visual feedback after pressing "Import" and "Upgrade" buttons during setup, now the wait cursor appears while the determining the differences between the two configuration (current/imported or default/imported).
-
What do you use for bug/issue tracking of your private projects?
Currently I'm using an Excel sheet for keeping track of bugs and change requests for my Visual Studio Add-in GhostDoc. The worksheet was easy to set up and definitely does its job -- for now. But I'm not sure how things work out in a couple of weeks or months.
Searching for "bug tracking freeware" on Google, there doesn't actually seem to be a shortage of tools I could try, given an infinite amount of time (which I don't have). So I'm asking the bloggers out there who have their little private pet project running for some time now: How do you keep track of things? I would definitely prefer something that doesn't require a web server.
-
GhostDoc 1.2.0 released
Version 1.2.0 originally was planned to contain mostly new rules; but it turned out that many of the planned rules require some kind of individual customization/configuration, so this had to be taken care of first. Internally, this release now does use configuration settings for each rule (e.g. templates for the generated texts), but the dialogs for actually editing these settings have not been implemented yet (they will be part of a 1.3.0 release). From a user's point of view, version 1.2.0 contains some important bug fixes and new rules for handling properties and methods with names starting on "Is", "Has" and "Can".
Download: on the GhostDoc homepage
Note for users of version 1.1.2
During setup, GhostDoc upgrades configuration settings of previous version (stored in the file "Weigelt.GhostDoc.gdc"). Usually this file is located in the GhostDoc installation directory, but due to a bug in version 1.1.2 the file was stored in the root directory of one of your hard drives.
If you have made changes when using version 1.1.2 that you want to keep, you can import the old settings using the "import" feature on the configuration dialog (see the help file for more information), then delete the ".gdc" file in the root directory.
What's New:
- Added: New rules for handling method names starting with "Is", "Has" or "Can".
- Added: New rule for handling property names starting with "Is" or "Has".
- Added: Internal changes in preparation for rules to be configurable individually (affecting e.g. import/export) in future versions.
- Changed: During the setup phase, importing and upgrading configurations can now be distinguished(button and window title renamed).
- Fixed: Editing the adjectives for the "of the" reordering does not enable the "Apply" button; pressing the "OK" button does not store the changes. If anything else is modified in the configuration dialog, the changes will be stored correctly.
- Fixed: Configuration file is stored at the wrong location (root of the installation drive). This bug was introduced in 1.1.2.
- Fixed: GhostDoc can be affected by installing other add-ins, sometimes setup dialogs are shown again when Visual Studio is started.
-
GhostDoc 1.1.0 released
A new version of GhostDoc, the winner of Roy Osherove's Visual Studio add-in contest, is available - finally! Some bugfixes, some new features, an all-new help file, some eye-candy... but the most important work was done on turning a contest entry (with some corners cut to meet the deadline) into a stable foundation for the coming versions. To have this whole thing manageable, I pretty early on decided to push most of my ideas and the feature requests of users to version 1.2.0 -- looking back, a wise decision as finishing 1.1.0 turned out to be pretty painful.
Download: on the GhostDoc homepage (Edit 2004-08-31: removed link to a specific version)
First Steps
- Install the MSI
- Start Visual Studio to complete the setup
After installation, the Windows start menu contains a sub-menu "Programs -> Weigelt -> GhostDoc" with shortcuts to the help file and the demo project.
If you hate reading manuals, you should at least take a look at "How do I see some action without reading boring stuff?" -- the link to that topic is on the start page of the help file ;-)
What's New:
- Added: Configuration dialog for acronyms and words involved in reordering operations happening when sentences are generated from identifier names (e.g. "of the", "no the" words).
- Added: Import/Export of settings (on the configuration dialog).
- Added: Help file and help in dialogs.
- Changed: The "of the" reordering now checks for certain adjectives affecting "of the" trigger words and takes them into account while reordering.
Example: If "size" is configured as an "of the" trigger word and "initial" as an adjective, then "initialPageBufferSize" will be translated to "initial size of the page buffer" instead of "size of the initial page buffer" (as in Version 1.0x). In contrast, "primaryPageBufferSize" will still be translated to "size of the primary page buffer" (because "primary" is not on the list). - Changed: The rule for method names consisting of only one word now checks for parameters and adjusts the generated doc comment accordingly ("<Verb> this instance." for methods without parameters, "<Verb> the specified <first param text>." of methods with parameters.).
- Fixed: Bug in the automatic detection of acronyms -- words consisting of consonants and only one vowel at the start of the word (e.g. "Add") were classified as acronyms.
- Fixed: Bug in the handling of all-uppercase words in identifiers -- the words (e.g. ID) were split into single characters.
- Fixed: Bug when documenting properties in interfaces -- XML documentation comment didn't appear (reason was a fat bug in Visual Studio's CodeDOM; I'll have to check whether this still exists in VS2005 as soon as I get the copy I ordered at Microsoft).
-
Feels like Christmas...
...and these are just some of the prizes I've won:
The software prizes were distributed via internet and thus are kinda hard to show (and a CD-R isn't that spectacular to look at), but are really cool. And another book is still on its way -- winning stuff is fun!
-
1st Place for GhostDoc !!!
Wow... what a way to start into the weekend... GhostDoc was voted the #1 Addin in Roy's Addin Contest! If you haven't tried it yet, why not download it and give it a whirl. There's even a "how do I see some action without reading boring stuff" demo included. After installing the MSI, simply open the program menu -> Weigelt -> GhostDoc and read the quickstart document for the few steps necessary.
Right now I'm busy preparing 1.10; I don't know when it will be ready for release (working on a CHM help file can chew up enormous amounts of time), but it shouldn't be that far away. The feature set is frozen and I'll touch the code only if a serious bug is found in 1.02. Note that funny results of the text generation don't count as a bug ;-)
I have a huge list of improvements waiting for 1.20 and later (e.g. generation rules for virtual "On..." methods), but first I want a clean release of 1.10.
-
WinXP SP2 - How to Replace Notepad.exe
Installing SP2 brought back good ol' Notepad... what a shock. So I performed my usual steps for replacing Notepad with Florian Balmer's excellent Notepad2:
- Create backup copy of
c:\WINDOWS\notepad.exe - Change Explorer view options to show system files
- In temporary folder: Prepare new
notepad.exe. - Copy the EXE into the clipboard
- Open folder
C:\WINDOWS\system32\dllcachein Explorer - Ctrl-V, Backspace
- Ctrl-V, Backspace
- Ctrl-V, Backspace
- Answer the "insert WinXP CD" dialog so Notepad won't be reverted to the original version.
But this time the dialog didn't appear and after a few seconds Notepad was changed back to the original (huh, what original? Didn't I just overwrite the version in the dllcache directory?).
Well, with SP2 there's a
Notepad.exeinC:\WINDOWS\ServicePackFiles\i386that will overwrite the replaced versions. After creating a backup copy ofC:\WINDOWS\ServicePackFiles\i386\Notepad.exeand replacing this file with the new EXE I tried to replace Notepad again -- with success (even though no dialogs appeared).Update 2007-07-31: My colleague Jens Schaller has posted a how-to for replacing Notepad on Windows Vista.
- Create backup copy of
-
"Edit in Notepad" Entry in Explorer Context Menu
Busy preparing version 1.10 of GhostDoc, I'm currently writing the help file (CHM). I haven't spent much time yet on looking for a help authoring tool, so I'm using the HTML Help Workshop which is fully sufficient for the few pages I want to combine in a CHM file. It's one of those "it works, but man who designed the GUI" tools, and some things are done definitely faster when editing the .hhk, .hhp or .hhc file in Notepad (I'm using Florian Balmer's Notepad2 as a replacement).
I have a shortcut to Notepad in my "Send to" for quite some time now, but recently I got really tired moving my mouse from the top of the explorer context menu to the "Send to" menu over and over again. Fortunately, writing a small registry hack for creating an "Edit in Notepad" entry near the top of the context menu is trivial, here's the .reg file:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell\Edit in Notepad]
[HKEY_CLASSES_ROOT\*\shell\Edit in Notepad\command]
@="notepad.exe \"%l\"" -
VS2005 Color Scheme / XML Doc Comments : Who's Idea Was That?
This is what XML doc comments look like using my current color scheme in Visual Studio 2003:
When I took a quick first look into the "Fonts and Colors" options of Visual Studio 2005 I was delighted to see a new setting "XML Doc Attribute", so I was hoping to be able to configure something like this:
But actually this is what it looks like in Visual Studio 2005 Beta 1 (Express):
Umm, this is not what I would call an improvement. I can live with the change of the color of the "///"; personally I like the old version better as I think it's less distracting when reading the doc comment, but I'll get used to the new version.
But what on earth happened to the background color? Visual Studio 2002 and 2003 was perfectly fine. Who came up with the idea to change the behavior behind the last character of the line? Did some customer actually complain about this so it had to be "fixed"? Could somebody please explain the benefits of the new version?
With the old version, the methods were nicely divided by the doc comments:
Why would anybody now choose a different background color for a doc comment at all? This is so frustrating. This is one of those issues that has a low priority compared to the other "really important" ones, so it's likely not to be fixed for the final. And the next chance for a fix is years away. That hurts. Sorry guys, you just broke my heart.
But anyway, I'll give my feedback, maybe there's still a slight chance...
Update (2004-07-29): My feedback (FDBK12464) has been declared to be a duplicate of FDBK10617 and thus has been "resolved". These two feedbacks describe related, but different issues, so I can only hope that my feedback has been understood correctly.
-
Add-in Contest Website Live, GhostDoc Now Available
The contest results are not finalized yet, but the official website went live [via Roy]. All add-ins entered in the competition can now be downloaded, GhostDoc is available here.
Edit 2004-08-14: I've disabled the download link that was pointing to version 1.01; the most recent version can be downloaded from the GhostDoc website.
-
ReadOnlyRichTextBox
Writing texts for dialog boxes can be a pretty time-consuming task. When using only label controls, the constant tweaking of both wording (resulting in longer or shorter sentences, words wrapping in different ways) and overall text layout will drive you mad sooner or later.
For my Visual Studio add-in GhostDoc I needed a couple of dialogs like this one:
As the text between the header and the buttons was very likely to be tweaked over and over again, I decided right from the start to use a RichTextBox control (border removed, background color set to the form's background color) and write the text in Wordpad:
(I chose RTF over HTML because of the speed and ease of use of the RichTextBox on a Winform dialog).
To make things look a bit more professional it has to be made sure that the content of the RichTextBox can be neither edited (easy, that's what the ReadOnly property is for) nor selected (just a bit more complicated). I wrote a control derived from RichTextBox called ReadOnlyRichTextBox that does a pretty good job at doing just that; the actual code is pretty simple:
using System;
using System.Windows.Forms;
using System.ComponentModel;
namespace Weigelt.Windows.Forms
{
public class ReadOnlyRichTextBox : RichTextBox
{
protected override void OnGotFocus(EventArgs e)
{
// no call of base.OnGotFocus(e);
this.Parent.Focus();
}
protected override void OnEnter(EventArgs e)
{
// no call of base.OnEnter(e);
this.FindForm().SelectNextControl(this,true,true,true,false);
}
[ DefaultValue(true) ]
public new bool ReadOnly
{
get { return true; }
set { ; }
}
[ DefaultValue(false) ]
public new bool TabStop
{
get { return false; }
set { ; }
}
public ReadOnlyRichTextBox()
{
base.ReadOnly=true;
base.TabStop=false;
this.SetStyle(ControlStyles.Selectable, false);
}
}
}This control drives away any attempt to focus or select it. In order for this to work correctly, the ReadOnlyRichTextBox needs at least one other control on the form (for the SelectNextControl). As this is not actually a huge problem, I didn't spend time on finding an alternative solution.
You can download the code and a small demo here.
-
One Year of Blogging
I just can't believe that a whole year has passed. I still remember how I gave the whole blogging thing a long thought; I was a bit afraid of ending as one of those "Hi, I'm X and I'm going to write about Y, so stay tuned" bloggers never to be heard of. Well, at least I managed 1 year.
Looking back, these were my more popular articles, which generate feedback even now, many months later:
- When your WinForms UserControl drives you nuts
- Visual Inheritance - How to escape Layout Hell
- Visual Inheritance Revisited
My "Wouldn't it be cool" articles also seem to be pretty popular.
Ok, the amount of feedback I get (via comments, or via email) may seem laughable compared to what some of the "big guys of blogging" receive, but it's enough to keep me motivated. And that at least a few people have me on their blog roll makes me feel a tiny little bit proud.
So... let's see whether I can manage another year ;-)
-
GhostDoc is RTM (or is that RTRAC?)
(RTRAC = Released to Roy's Addin Contest ;-)
23:49 the mail with my contest entry GhostDoc left my outbox.
I'm exhausted. Several nights of only 4 hours sleep are taking their toll. Mostly addin related problems, stuff not working that worked perfectly for weeks. COM registration issues, you name it.
I had to cut features, there are things that could have been better, but that sucker is out the door.
I feel satisfied.
-
Crunch Mode
I'm busy putting the final touches on GhostDoc for entering it here:
Testing, cutting features, testing, writing release notes, testing, fixing last minute bugs, testing, ...
Hmm. Some parts of developing software a more fun than others... ;-)
-
Cool Google Search Macro for Visual Studio
Marty Garins wrote a really cool macro for performing a Google search from Visual Studio.
See the feedback section of that blog entry for a minor addition I proposed (urlencoding of the search text). By the time you are reading this, it may already be included in the macro code.
Tip: If you want to limit your search to the MSDN site, add the red text to line building the URL string:
Dim url As String = String.Format("http://www.google.com/search?hl=en&ie=UTF-8&q=site%3Amsdn.microsoft.com+{0}", selectedText) -
Strange: GetProcessesByName and Floppy Drive Access
Here's something strange: Each time I call the method Process.GetProcessesByName my floppy drive is accessed, which is rather annoying especially if no disk is inserted.
If you want to try it yourself, here's the code for a minimal command line app:
using System;
using System.Diagnostics;
class GetProcessesByNameDemo
{
static void Main(string[] args)
{
Process[] arrProcesses=Process.GetProcessesByName("notepad");
}
}A search on Google Groups for "getprocessesbyname floppy" shows (at least at the moment of writing these lines) that I'm not the only one with this problem; unfortunately I could find neither an explanation nor a solution.
So.... anybody out there knowing more about this strange behavior?
-
My Transition from Fixed to Proportional Width Fonts for Editing Source Code
I always find it interesting to look at source code I wrote years ago. Old dot-matrix printouts (BASIC and Z80 Assembly code from the 80's...) found in a drawer while searching for something else. Or source files in some remote "OldStuff" folder on my storage hard drive.
These old sources bring back lots of memories and it's nice to see the evolution of my personal style, which shows several cycles of first changing only gradually for some time, then suddenly getting a visible boost after being exposed to new concepts and ideas.
One thing that really amazes me in my source files back from the 90's is the amount of time wasted on formatting and indentation (sometimes up to the point of thinking "wow, did I do that?"). I'm speaking of things like comment headers for methods:
/******************************************************
* Method: CreateItem
* Purpose: Creates a new foobar item using the
* specified ID
* Parameter: id = ID of the item
* Returns: created item
******************************************************/Or end-of-line comments. Often I can literally see code statements and comments fighting for space, with the comments eventually losing and being split to two or more lines:
splurbyUpdateBits=noobahFlags & pizkwatMask; // a comment explaining what
// this line is all about,
// spanning several linesAnd another waste of time: lining up variable names and comments in declarations:
int n=0; // A comment
SomeType theItem; // Another commentA few years ago I started experimenting with proportional fonts for the source code editor, being inspired by screenshots of Smalltalk and Oberon systems I saw in magazines. After finding out that Verdana (unlike Arial) is well-suited as a developer's font, displaying the uppercase I, the lowercase L and the pipe symbol differently, I forced myself to use this font for a while.
The increase in readability was amazing (especially for long identifiers), but my exisiting source code was a mess when viewed in the editor - all elaborate formatting using tabs and spaces was gone. Not wanting to go back, I had to adjust my commenting and formatting style:
- I chose a less elaborate design for comments headers (which I won't reproduce here as it was C/C++ specific; now using C# with its XML documentation comments I never felt the need for exactly lining up anything)
- Wrapping end-of-line comments was no longer an option. Sure, you can line up the comments in your editor using tabs, but in other people's editors (using a different font) the result is unpredictable. So I reduced the need for EOL comments
- by moving some information to section comments that explain the intention of several code lines, and
- by writing better code (yeah I know, d'oh!), as long EOL-comments usually are an indicator for bad/complicated parts
- I simply stopped formatting variable declarations. Maybe it was a nice thing to do in plain C, but in C++, Java and C# long lists of variable declarations are much less common anyway. What benefited most from lining up were the end-of-line comments behind variable names. But with the switch to a proportional editor font (supported by the Intellisense feature) the length of my variable names grew considerably, and with more expressive names, most comments were no longer required. Now, the few remaining comments don't need to be lined up.
I'm now using a proportional editor font (Verdana 8pt) for quite some time and I wouldn't voluntarily change back to a fixed-width font. At the same time it must be noted that the transition may not be without problems, depending on your current personal style. But I can definitely recommend giving it a try.
-
GhostDoc Progress
After a pretty long break from working on GhostDoc I'm now back on track. My goal is to have a release ready for entering Roy's add-in contest and now that the deadline has been moved to June 30, I'm pretty sure I can make that happen.
-
Sometimes it's Better to Check Even Really Obvious Dialog Defaults
If you only have a C# project file named e.g. "foobar.csproj" in a directory, opening it in the Visual Studio IDE (VS.Net 2003) will create a solution file for you. Either when saving or exiting you'll be asked for the file name, with the default name being e.g. "foobar.sln".
After being asked for solution file names over and over again, I never looked at the default name again - I simply hit Ok as soon as the dialog popped up.
Tip: You shouldn't do this if your project filename contains a dot. Because for a project named e.g. "foo.bar.csproj", the default name of the automatically generated solution file is "foo.sln", not "foo.bar.sln" as one would expect. For "X.Y.Z.csproj" the default name is "X.Y.sln", for "A.B.C.D.csproj" the default name is "A.B.C.sln", and so on.
In contrast, if you create a new project from scratch, the solution name is the same as the project name, even if the project name contains a dot.
-
Don't Underestimate the Benefits of "Trivial" Unit Tests
Take a look at the following example of a trivial unit test for a property. Imagine a class
MyClasswith a propertyDescription:public class MyClass
{
...
private string m_strDescription;
public string Description
{
get { return m_strDescription; }
set { m_strDescription=value; }
}
...
}And here's the accompanying unit test:
...
[ Test ]
public void DescriptionTest()
{
MyClass obj=new MyClass();
obj.Description="Hello World";
Assert.AreEqual("Hello World", obj.Description);
}
...Question: What's the benefit of such a trivial test? Is it actually worth the time spent for writing it?
As I have learned over and over again in the past months, the answer is YES. First of all, knowing that the property is working correctly is better than being "really, really sure". There may not be a huge difference in the moment you write the code, but think again a couple weeks and dozens or hundreds of classes later. Maybe you change the way the property value is stored, e.g. something like this:
public string Description
{
get { return m_objDataStorage.Items["Description"]; }
set { m_objDataStorage.Items["Description"]=value; }
}Without the unit test, you would test the new implementation once, then forget about it. Now another couple of weeks later some minor change in the storage code breaks this implementation (causing the getter to return a wrong value). If the class and its property is buried under layers and layers of code, you can spend a lot of time searching for this bug. With a unit test, the test simply fails, giving you a pretty good idea of what's wrong.
Of course, this is just the success story... don't forget about the many, many properties that stay exactly the way they were written. The tests for these may give the warm, fuzzy feeling of doing the "right thing", but from a sceptic's point of view, they are a waste of time. One could try to save time by not writing a test until a property's code is more complicated than a simple access to a private member variable, but ask yourself how likely it is that this test will be written if either a) you are under pressure, or b) somebody else changes the code (did I just hear someone say "yeah, right"? ;-). My advice is to stop worrying about wasted time and to simply think in terms of statistics. One really nasty bug found easily can save enough time to write a lot of "unnecessary" tests.
As already mentioned, my personal experience with "trivial" unit tests for properties has been pretty good. Besides the obvious benefits when refactoring, every couple of weeks a completely unexpected bug gets caught (typos and copy/paste- or search/replace mistakes that somehow get past the compiler).
-
XML Documentation Comment Tooltips (Wouldn't it be cool, part 5)
While I do write XML documentation comments for all my code (except throwaway stuff), I rarely actually read e.g. the CHM file generated by NDoc. But as we all know, a cool feature of VS.Net is that the content of XML documentation comments is used in various situations to display tooltips, which may look something like this:
Unfortunately, if users of my code (i.e. either other developers, or me after a couple of weeks) read only the tooltips, they may miss valuable information, e.g. descriptions of return values or remarks. The problem is that there's no way to tell whether additional information is available, so one usually assumes that it is not -- especially if you have looked a couple of times into a CHM documentation file for a specific topic only to be disappointed.
So I think it would be a cool feature if tooltips could display more information, maybe like this:
Of course the texts should be truncated to a reasonable maximum size (in order to avoid something like the sometimes screen-filling tooltips of the NUnit GUI ;-).
Other "Wouldn't it be cool" posts:
- Wouldn't it be cool...? (about editing XML documentation comments
- Intellisense (Wouldn't it be cool, part 2)
- Find (Wouldn't it be cool, part 3)
- XML Documentation Comments (Wouldn't it be cool, part 4) (doc comments e.g. for interface implementations).
-
Selecting String Literals in the VS.Net Editor
A colleague stumbled across this feature of the text editor by accident:
Move the mouse cursor on the opening quote character of a string literal:
Double-click and the whole string literal will be selected:
Pretty cool.
-
XML Documentation Comments (Wouldn't it be cool, part 4)
Each time I implement an interface or override methods in a derived class, I have to copy XML documentation comments for methods and properties manually. This is quite annoying - especially for interfaces, considering the fact that VS.Net 2003 has this cool feature of creating the outline of an interface implementation automatically. So why not create the documentation comments as well?
Note that I don't want the original documentation referenced using some sort of complicated mechanism. Just Copy and Paste - in many cases the documentation should be tweaked anyway (at least if you want to write readable documentation; who doesn't hate those generic sentences describing "actions" that are "performed" on "items")
Man, this is something I really would like to see in a future version of VS.Net.
-
Nice WinXP Style Icons for Customizing Folders
For quite some time I had planned to set up my home machine from scratch; last weekend I finally bit the bullet and did it. One week later I'm still in the "add and tweak" phase (the days after a re-installation when you notice some tools/hotkeys/settings are missing), but things are on their way back to normal.
While configuring my system I played around with customizing folder icons in Windows Explorer ("Customize" tab on a folder's property dialog). Nice feature -- if you have icons matching the look of your system. Searching the web for folder icons I noticed that people seem to be obsessed with changing the look of their GUI completely, often to a point where I can only wonder whether these systems are used for any actual work...
If you're looking for some "Standard Windows XP" folder icons for typical document types, you should visit Foood's Icons. The folder icons can be downloaded on this page under "XP Folders (1,2,3, 4 & 5)".
-
Nasty little Difference between "Find" and "Find in Files" in VS.Net 2003
I'm a keyboard shortcut junkie; at the same time there's a large variation of how fast I pick up a hotkey. While I used Ctrl-F / Ctrl-H (find / find and replace) and Ctrl-Shift-F / Ctrl-Shift-H (find / find and replace in files) for what seems like ages, I only recently started using Alt-F / Alt-A (find next / replace all) in the Find dialog -- don't ask me what took me so long...
Now sometimes you simply use the wrong shortcut, especially if it's pretty new for you and not completely burnt into your brain. Maybe you're tired or distracted or whatever.
So what happens if you hit Alt-A (replace all) in a Find dialog? Nothing, because there's no button "Replace All" in this dialog. Sounds reasonable.
But what happens if you hit Alt-A in a "Find in Files" dialog? Well... it replaces everything you wanted to find with some text you entered in the "Replace in Files" dialog five minutes ago!
Fortunately I had the "keep modified files open" option checked, so could use Undo...
-
GhostDoc Delay
As the public interest regarding GhostDoc was next to zero (which isn't necessarily a bad thing at this phase of the project), I've done a quiet release of version 0.9, available only to some of my colleagues at work. The overall reaction was very positive and a lot of "cool, I want more" ideas poured in which showed that they did "get" what GhostDoc is about. Unfortunately, when planning the future direction for GhostDoc, it became pretty obvious that the way the rules for method and properties are currently defined is a dead-end.
So I have decided that there will be no public release of version 0.9. I will completely rework GhostDoc towards a more extensible architecture, even if this means I have to throw away a lot of work done in January. No idea how long this will take, but I try to make several small steps to minize the risk of getting carried away. More details will follow later.
-
GhostDoc has reached Dogfood Status
A lot has happened since my last GhostDoc related posting. The addin version of GhostDoc is pretty close to a first public release. I'm already using it both at home and at work, but it's a bit complicated to keep the two configurations in sync. It's not really rewarding to define more specialized rules if you can't move them to a different machine. So I've decided to delay the release until some very basic import / export functions are implemented. They will be ugly, but straightforward to use and fully sufficient for a 0.9 version.
Here are two screenshots of configuration dialogs:
1. The main dialog
2. The dialog for editing a property rule:
