According to Wikipedia, a kludge (or, alternatively, kluge) is a clumsy or inelegant solution to a problem or difficulty. In engineering, a kludge is a workaround, typically using unrelated parts cobbled together. Especially in computer programs, a kludge is often used to fix an unanticipated problem in an earlier kludge; this is essentially a kind of cruft.

When I first stumbled upon the concept of anonymous methods in C# 2.0 the first thing I thought of was …jeez it’s just another name for GOTO!  I’ve since changed my mind.  Have any of you ever used the Gosub…  Return programming construct from way back in the GW-Basic days?  I’m dating myself but in a former life I had the responsibility of maintaining a servo controller program that ran a servo motor (a DC motor that is capable of moving in programmed increments forward and backward) for a plant that made flour tortillas.  (yes - for Taco Bell no less!)  But I digress.  This particular brand of “Servo Basic” as it was called did not have the ability to address function calls.  It was all done with line numbers.  The program started at 10 and ended at the highest line number.  The only way to program a function in this version of basic was to use the Gosub… Return construct.  For instance “Gosub 100″ would jump to line 100 in the program and start executing code until a “Return” statement was hit then control would return to the line after the calling “Gosub” statement.  It was all very archaic but very versatile when it was all you had. 

Now I tell you that story so I can tell you this one:  I was happily coding one fine day when I encountered a problem that I needed to solve and it occurred to me that a Gosub… Return would be perfect here!  It was a function with lots of values passed in that needed to perform the same processing multiple times but I didn’t want to pass all that data around on the stack.  This, my friends, is the perfect case for an anonymous method.  You can define an anonymous method anywhere inside a function and when you call the method, it has the same scope as the code that defined the method.  The example here uses a SqlDataReader to populate an object.  The reader may or may not have some columns in it.  Since the only way to determine the columns in the reader is to use the GetSchemaTable() function and look at the results, I wrote an anonymous method to perform the search and was able to use the search to check for the existence of the questionable columns. 

Notice the placement of the definition within the function.  It is defined after the definition of the ReaderSchema DataTable.  The executing code in the function has scope at the point of definition and so it “knows” about the DataTable.  The syntax is a little funny but makes sense once you work through it.  The name of the anonymous method is “HasColumn” and can now be called from anywhere in the function after its definition.  It returns a boolean and accepts a string as designated by the delegate it is based upon.

Now I could have simply put the HasColum() in its own function and passed the table in to it along with the column name I’m searching for but then I wouldn’t have this totally cool use of an anonymous method, now would I?  However, the question remains:  elegance or kludge?

This post goes out to all you VB geeks that are wondering what happened to Printer.Print in VB.  This may be a dated topic but I have a feeling there are a few out there longing for those VB6 days when the printer was always sitting there loyal and waiting.  The VB6 programmer’s best friend.  Well, when you needed to print something anyway.   Once upon a time you could just write a few lines of code and *poof* you created a page of information for your users.  Now you have this PrintDocument thing and PrintDialogs and PrintPreviewDialogs and Graphics objects and the list just goes on and on.

Let me re-introduce you to printing in .NET.  Once you get through the slight grade of the learning curve, you’ll be convinced that .Net printing is better than anything you did with the printer object in VB6.

The task - print a smiley face on a piece of paper.  Lines of code in VB6 - about 6.  Lines of code the .net way - about 22 (but you could consolidate…).

That doesn’t sound like a good trade off.  It seems its easier in VB6.  However - what if you wanted to create a bitmap of the smiley face and then use that bitmap in various places as well as print it here and there?  How many line of code do you need now?

 In VB6 - I have no idea.  You would need to drop down to the API level and call graphics functions against a Device Independent Bitmap device context making sure you clean up after yourself in those places where cleanup is necessary.  Then you would need to save that bitmap to a file and/or have an image control somewhere that you could set using the memory bitmap (again using API calls).  Then perhaps you could print the smiley here and there using some similar printing code.

In .NET - its the same 22 lines of code and you can run those lines of code against any “Device Context” (using API terminology) by simply passing a Graphics object to the code that actually creates the smiley.  You could even create a bitmap object and simply use that bitmap throughout your program without ever getting close to the windows API.
Here are my CreateSmiley functions:

private void DrawSmiley(Graphics g, int Width)
{
  Pen p=new Pen(Color.Black);
  SolidBrush b = new SolidBrush(Color.Black);
  SolidBrush YellowBrush = new SolidBrush(Color.Yellow);
  Point Origin = new Point(0, 0);
  Size HeadSize=new Size(Width,Width);
  Rectangle Container=new Rectangle(Origin, HeadSize);
  Point LeftEye=Origin;
  Point RightEye=Origin;
  Point SmileTopLeft = Origin;
  LeftEye.Offset((int)(HeadSize.Width*.25), (int)(HeadSize.Width*.20));
  RightEye.Offset((int)(HeadSize.Width*.65), (int)(HeadSize.Width*.20));
  SmileTopLeft.Offset((int)(HeadSize.Width *.20), (int)(HeadSize.Width * .40));
  Size SmileSize = new Size((int)(HeadSize.Width*.60), (int)(HeadSize.Width*.40));
  Size EyeSize=new Size((int)(HeadSize.Width * .10),(int)(HeadSize.Width * .10));
  g.FillEllipse(YellowBrush, Container);
  g.DrawEllipse(p, Container);
  g.FillEllipse(b, new Rectangle(LeftEye, EyeSize));
  g.FillEllipse(b, new Rectangle(RightEye, EyeSize));
  g.DrawArc(p, new Rectangle(SmileTopLeft, SmileSize), 180, -180);
  b.Dispose();
  YellowBrush.Dispose();
  p.Dispose();
}

private Bitmap CreateSmiley(int Width)
{
  Bitmap Smiley = new Bitmap(Width, Width);
  Graphics g=Graphics.FromImage(Smiley);
  DrawSmiley(g, Smiley.Width);
  g.Dispose();
  return Smiley;
}

Pretty basic stuff and different than you did in VB6. You have access to all the API stuff without dropping down the the API level. Now as far as printing goes - there are a few objects that need your attention. The PrintDocument, PrintDialog, and PrintPreviewDialog objects. The PrintDocument object is the container for all your drawing methods. It handles paging and rendering of the stuff you are printing. The PrintDialog and PrintPreviewDialog objects manage the actual device you are printing to. The PrintDialog as you may have guessed will print to a printer while the PrintPreviewDialog prints to a preview window.

Here is some code that uses a PrintPreviewDialog and calls the printing methods above:

private void button1_Click(object sender, EventArgs e)
{
  PrintDocument pdoc = new PrintDocument();
  // hook up the event handler for the printpage event
  pdoc.PrintPage += new PrintPageEventHandler(pdoc_PrintPage);
  PrintPreviewDialog pdialog = new PrintPreviewDialog();
  pdialog.Document = pdoc;
  pdialog.ClientSize = new Size(640, 480);
  pdialog.Show();
}
void pdoc_PrintPage(object sender, PrintPageEventArgs e)
{
  Bitmap smiley=CreateSmiley(300);
  e.Graphics.DrawImage(smiley, new Point(150, 150));
  e.HasMorePages = false;
}


The VB.Net code is virtually the same. Just change the declaration variables around, change the curly braces to Sub/End Sub, remove the semi-colons and your 80% done.
This method of printing is easy to hook up and offers a great deal of flexibility but if you want real reporting power - there is no substitute for a good reporting engine such as SQL Server Reporting Services or Business Objects’ Crystal Reports. There are others.  I’m a convert.  I was a Crystal Reports bigot but if you’re using a SQL Server database - you get reporting services for free and I must admit after running SQL RS through its paces - I like it better than Crystal Reports.  That, of course, is my opinion.

If you have upgraded from Visual Studio 2003 to Visual Studio 2005, you have probably noticed one of the major annoyances: they took away the sounds.

With VS 2003, you could set things up so that your computer made a happy little sound at you when a build succeeds. This was great because I could turn away from the monitor for a moment, if only to rest my eyes, until the sound brought me back. Or I could check email, get another glass of cold caffeine, etc.

I’d even gone a step further by making my app play the sound of a bell ringing, when it had finished booting itself after a successful build in the dev environment. This extended the time I could gaze out my window at the tangle of weeds we call a lawn.

But in VS 2005, all you can do is hear a sound when you hit a breakpoint. Big deal. I want the cheerful news that everything is copasetic. So why did they take out the sounds? To save a few hundred milliseconds. That appears to be the official word.

And the official word, back in April 2006, was that they were working on fixing this “bug” for the next release. Well, the next release has come and gone. Still no sounds. In the meantime, they suggest, you can write an add-in.

In Service Pack 1, there is a new control called SoundPlayer, which appears to do the same thing a simple two-line function can do. Yes, without it you have to declare an API function, which means unmanaged code and wild-eyed people grabbing you by the collar to tell you what a mistake this is, but I’ve been using API calls very carefully since .NET appeared and have yet to suffer (I am knocking on my desk top with both fists). I guess it comes down to this: I’d rather have my sounds back than a relatively useless control.

I saved much more time when I had that happy sound than the hundreds of milliseconds they were worried about. At least my app still rings a bell when it’s up and running.

But they could have told me.

There are a lot of handy Visual Studio 2005 add-ins out there that, for a variety of perfectly legitimate reasons, have yet to be updated for Visual Studio 2008.

Before you go looking for replacement add-ins, though, you might want to check out a recent blog post by Mohamed Ahmed Meligy called Tip: Try this to make a VS 2005 add-in work with VS 2008. As the title implies, the author discovered a quick process for making sure that his Visual Studio 2005 add-ins would work on the newer version of the IDE.

The caveat here, of which Meligy is quite aware, is that this process may not work with all Visual Studio 2005 add-ins. Nonetheless, it certainly can’t hurt to try it out, especially if you have come to rely on a particular add-in so much that you think it’s part of the IDE itself.

So I put together my setup project using the in-grown version of MSI (don’t get me started on how cumbersome it is to add files!) and then built it. Looked good.

But when I tested it, the suggested path was “C:\Program Files\Default Company Name”. Whaaa? Where was it getting that from? And how could I get it to show the correct name? I figured I needed to modify some properties somewhere.

I right-clicked on the project in Solution Explorer, and then chose Properties. That brought up the configuration properties, not the project properties. Next I clicked on Project | Properties. That brought up the configuration properties again. So did View | Property Pages.

Then light dawned on Marblehead, as they say in New England. In Solution Explorer, I clicked on the name of the project. Then I clicked View on the menu bar and found the entry for Properties Window and clicked that. There it was—the manufacturer was set to Default Company Name. (Maybe I should buy that domain name….) At least it was an easy fix, once I found the right place.

I also noticed that I could choose an icon for my app’s entry in the Add/Remove Programs applet, as well as pre- and post-build events. I got all excited for a minute, thinking these were pre- and post-install events, but no such luck. Now wouldn’t that be nice!

The Deployment Project Properties window (as it is officially called) is very much like the properties windows for controls such as listboxes and buttons. Controls are objects, and so are projects, so I suppose it makes sense that you’d get to their properties the same way.

But they could have told me.