Daily Archives: June 5, 2004

VB Refactoring Menu: Don’t click that link!!

Back in November, Leon Bambrick posted his now famous VB Refactoring Menu on his little Brinkster hosted weblog. The links to this post were so many that Brinkster shut him down. As soon as the site came back up, I copied and pasted the image to my own blog (with all credit to Leon of course). He finally moved to his own domain a month or so ago.

Don Box just discovered the menu on the Brinkster site and pointed to it. Then Chris Sells saw Don’s post and did it again.

Eeek! This for SURE will do Leon’s site in again. If you haven’t seen it, do him a favor and follow this link instead. And definitely subscribe to this guy’s blog!

Erasing Ink and Undo

The proper method of erasing ink with the Tablet PC SDK is to set the pen to delete or Eraser mode. There are two methods of erasing: stroke, which deletes whatever stroke you touch on (ink collection is a collection of strokes) or point by point. The point by point method works like an eraser. As you move the mouse around it affect the touched strokes by breaking them apart. So if you have a stroke that goes from point a to point b and erase in the middle, the original stroke is modified to end where the eraser started and a new stroke is created that begins at the end of the erasure and ends where the original stroke ended.

Since I have an UNDO method in my BLInk application, this is important to me. My method of undoing is to go to the top of the stack of strokes and remove them one at a time. Those get stored and can be used to “redo” as well. However, this method of erasing totally mucks up my stroke collection and without a lot more work, I can’t “undo” erasures.

The other way I can go about this is by sleight of hand. Rather than breaking up the strokes, my “eraser” can be an additional stroke that is the same color as the background. That way, I can undo and redo to my hearts content. The only consideration is the affect that this method will have on my resources and the size of my image when all is done.

There is probably a better way – or just the harder way of creating an additional store to capture all strokes and all erasures. ANd then undo and redo from that stack instead. I think I’m going to have to do a little more research on this one.

Why bother with the TabletPC SDK?

This is probably the most common question that I hear from developers:

“Why do I need to program with the SDK if the tablet already does handwriting recognition? I can just put my existing data entry forms on a tablet pc without having to change a thing and they will work, so what’s the point of learning to program for tablets?“

There is a LOT of information collected when someone works in ink on a TabletPC. The SDK gives you access to this information whether you want to read it, store it or even manipulate it. And there is a lot more to the ink than just handwriting recognition. But even if that is all you are interested, looking at the object model of the tablet api might give you some ideas to think out of the box even with this one particular function.

I’m curious about how other people would answer this question…. what does the API give you that the O/S doesn’t already do on it’s own?

Nullable Types in VB and C#

I read with great interest Paul Vick’s post on “The truth about Nullable types in VB“ vs. C# as I am talking about nullable types in my revised Whidbey BCL talk that I am doing at VTdotNET in a week and then at DevTeach in a few weeks.

I have played with nullable in the March preview bits, but not yet in the May and disappointed with the current (but slated for serious improvement by the bcl team!!!) performance when I compared the using nullable<t> over current options. So for example with value types: 

 – comparing myNullableInt.HasValue to (in VB) is myInt < 0

or with reference types

 – comparing myNullableThing.HasValue to “if not myThing=null”

the nullable type is currently much much slower. I have been promised by a few on the BCL team that the plan is to make the nullable MUCH more performant as it is their “best practices” suggestion (see Krzysztof’s Generics guidelines) to use nullable types.

I have also been given the hint that in the future, the following will be possible:

Nullable<T> Parse(string value);
Nullable<Int32> i = Int32.Parse( some String );

And will be more performant than TryParse. So that, too will be interesting.

It’s interesting to see all the groovy little shortcuts that C# is getting now and VB will be getting someday hopefully, though for now, all we really get of value (please correct me if there is more…) is the “hasvalue“ property which benefits us mostly for the value types coming back from databases.