Why bother with the TabletPC SDK?

Tablet

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#

dotNET

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.

Hanselman comes in 3rd in Think In Ink Power Toy contest

Community Cheerleading

It just figures! He’s a star — get used to it! He spent 15 minutes writing a tool and came in 3rd place!

Here’s the article on the announcement from PCMag this morning. (thanks to TabletPCTalk for pointing that out.)

Peter Rysavy has a nice write up on the 3 winning powertoys.

There is still the full blown app contest going on – $100,000 prize! Deadline is July 31st. I had a long talk with the person who is in charge of this contest when I was at Redmond and will post about that…

Bear in the hood

Vermont

All of my neighbors saw the bear wandering around here yesterday but I missed it. And I’m the one who works at home in front of a hug set of windows. We don’t have garbage pickup so maybe that’s why he was at my next door neighbors and across the street but never here.

It’s just a yearling – probably pushed out by mama – “go find your own territory” and apparently poses more threat to my bird feeders than to my cat but I think we’ll just keep him in for a few days (and put the bird feeders in the garage).

When I lived in the Hudson Valley (NY State/Southern Catskills area) I was friends with the “bear guy” from the Region 3 NYS Fish & Wildlife Dept. He’s the guy that would get called any time a bear was where bears shouldn’t be. Usually to just tranquelize it and move it back to the mountains.

The more you know, the harder it is to solve problems (sometimes)

Just Rambling

I was talking with my neighbors last night about an embarrassing problem I had with my server a few months ago when rebuilding it. It was not recognizing my hard drive. I was almost in tears trying to solve this problem (remember tears = so mad my head is going to explode). My husband came along and said, check your cables. I said oh, it’s not the cables, it’s something really complicated. It was the cables. I had 5 gazillion ideas of things to check when I had this problem. What do you choose first? Second? 100th? Rich only knew of a few possible things. Isn’t it always like that when you are trying to solve a problem? Where to start….?

The Great DataSet Debate

Tools

Speaking of Scott Hanselman, he started a fantastic discussion about datasets. His issue was returning datasets from webservices (public ones) that may have subscribers that are not .NET clients and don’t grok datasets. There are a bunch of discussions that spun off of this as well as a pointer to a February discussion and incredible debate in the comments on Barry Gervin’s site.

Being a database developer for a gazillion years, I love working with data in my apps so I thought I’d add my 2 cents into here of some of the things that crossed my mind while reading through some of this stuff.

For the last few years, .NET has defined a choice of web services vs. remoting. Basically the prescription was if you are using nothing but .NET in your solution (client and server), then go for remoting and use strongly defined objects (though there were still some interesting perf #s when it came to datasets..). If you were creating something public that could be subscribed to by non .NET clients, then use a web service. That definition also presumes that datasets might not be the thing to return from the web methods since you would be dealing with clients that need to do a lot of work to read the dataset. (by my read, this is Scott’s main point).

I should mention here that I use web services for a lot of applications that are strictly .NET based and I have never implemented remoting. This was not an explicit decision based on some deep investigation, rather because I learned web services first (since Microsoft marketing really forgot the remoting message for the first 6 months) and stuck with them.

With Indigo coming down the pipes, that prescription changes. Basically the message is that if you are creating something new, use web services. Period. Regardless of an unknown or a strictly .NET defined client. So now many more strictly .NET solutions will be using web services and returning datasets will not pose that particular problem (client not understanding datasets) and the question will come down to perf. As Scott Swigart points out “Hanselman lives in an arena where there’s no such thing as fast enough, but few applications live under this constraint.”

There is definitely a choice to be made, but I think the bigger problem is that many developers are not aware of the choice. The dataset has become their tofu – an all purpose, maleable tool that can be used as every data container. I wonder how many people know that you can even fill a datatable from a dataadapter? Or how about just using a dataset/datatable/datareader as a translator….to get data out of a database and then push it into another type of object.

Many developers do not understand the baggage that comes along with a dataset. It’s good/useful/handy/helpful baggage if you need that functionality. But it can be dead weight if you are not using it. 

ADO.NET 2.0 is going to help more too, of course, with the datatable becoming a first class citizen (readxml and writexml), dataset can now load data in from a datareader (though you can’t return a datatable or datareader from web services with the same simplicity of dataset), lots of new merging functionality and more.