As I mentioned in an earlier post, I’ve been helping some fine developers port over FIT from Java to C#. The SpreadsheetRunner is part of that, but there are other core ones that SpreadsheetRunner inherits from, namely CustomRunner and MakeParse. Since I could find the existing unit tests for those I gave it the ol’ try of porting those first.
Here were my steps:
1) Open the file in Eclipse (or Wordpad, depending on my mood)
2) Create a class with the same name in VS.NET
3) Copy everything between the class declarations from the Java class to the C# class
4) change static finals to consts
5) remove any throws BlahException
And build. And except for some minor tweaks (like the Java standard using lowercase first letters for method names vs C#’s uppercase) it pretty much worked. Yes, I had to stub some classes (like PrintWriter).
Actually, the funny thing was that I stubbed the classes and couldn’t figure out why my NUnit tests were failing with expected: <"Blah\nBlahBlah"> but was: <"Blah\n\r\nBlahBlah"> which I first chalked up to an MS encoding problem. But then I realized that in my stub PrintWriter I had done:
public void print(string msg)
{
if(writer == null)
{
Console.WriteLine(msg);
}
else
{
writer.WriteLine(msg);
}
}
Instead of:
public void print(string msg)
{
if(writer == null)
{
Console.WriteLine(msg);
}
else
{
writer.Write(msg);
}
}
So, *I* was adding in the extra line break. Once I caught that, All greens for the TestMakeParse tests! Progress is in hand.
Speaking of silly things, today I was working on a WinForm app. I had a task to fix an issue where our window that tells the user that something is downloading wasn’t defaulting the focus back to the Ok button once the download was finished. Basically we have an Ok and Cancel button, and only the Cancel button is enabled while the stuff is downloading. When it finishes, we reenable the Ok button so the user can continue on. “Simple enough fix,” I thought to myself, “I’ll just focus it!” So I tried:
buttonOK.Focus();
Hmmm, nope. lessee, how about:
buttonOK.Select();?
Ok, not that either. Google, Google, Google…ah, how about:
this.ActiveControl.buttonOK?
Sigh. Fine. I’ll just pull the cancel button off:
buttonCancel.Visible = false;
Which meant that if the user hit Enter, at least they would continue. It still didn’t put the dotted outline focus indicator over the Ok button though. I finally stumbled across the solution. Since I only had two buttons, and Ok was TabIndex 1 and Cancel was TabIndex 2, I used SelectedNextControl:
SelectNextControl(
Control ctrl,
bool forward,
bool tabStopOnly,
bool nested,
bool wrap
);
Nice. At least it worked. Another card in the finished stack.