I had a great PDC. I arrived with a schedule filled with sessions I intended to go to, and (shhhhh!) I skipped them all (except, ScottGu’s keynote and Scott Hanselman’s BabySmash both of which were (predictably) great).
The reason I skipped all the others (and there were a lot of excellent talks that I will now have to settle for seeing the recordings) is that I had the singular opportunity to not only talk with, but truly engage with some amazing developers.
Microsoft puts on 3 major shows a year, and PDC is the most “forward looking” of the three, which means, ultimately, that a lot of what you see at PDC you probably can’t put into production code today. Given that and the “all in” cost of attending (admission, transportation, accommodations and missed work) it tends to attract some very serious geeks. And that can make for some very interesting conversations on any number of topics.
Terse, Complex or Dead Simple?
One topic that came up a lot was the universal sense of being overwhelmed by the sheer volume of new technology, and how each developer coped with learning all the new material. This lead to some fascinating discussions about how technology is taught, documented, and explained. It was very clear that there would never be consensus on the "best" method; there can be no one best way to teach because there is no single learning style. That said, there did seem to be two schools of thought about examples. One group seemed to strongly favor real-world examples even at the cost of a little complexity; the other to strongly favor incredibly simple examples even at the cost of being overtly artificial.
It is clear that I favor dead-simple examples, and I can trace that directly to learning to program what turned out to be a terrific ISAM package in C in the mid 1980s. The problem, though was in their documentation. Each of their examples was incredibly cool, but amazingly opaque. It was only after I stripped away all the indirection and programming elegance that I realized that there were just half a dozen relatively straight-forward function calls to manage. I ended up creating my own set of examples that were 1/10 the size of theirs and 10 times easier to grok. It was a lesson that is seared into my writing center.
Revisiting the Controls Toolkit Examples
The incredible folks in Shawn Burke’s group have released the Silverlight Control Toolkit and it comes with what I consider to be really terrific documentation, plus source code plus examples and so Bob’s Your Uncle and you’re done. But while I really like what they’ve done, I’m going to take a shot at revisiting some of the samples to really tear it down to the simplest and most visible moving parts, and along the way I’ll also take a look at using the controls in both Blend and Visual Studio. This will be an on-going effort, over a few weeks and depending on your comments and what else comes up, we’ll take some detours and delve into some of the nuances of how these controls can be used in unexpected ways.
|Please click here to download the Controls Toolkit|
I set out today to begin work on the AutoComplete control, which has all sorts of interesting nooks and crannies, but I quickly discovered that I wanted to create my own data to explore this control (and others), and this is where ADD is either a curse or a blessing, because I spent quite a bit of time spelunking through the open file dialog, and the scroll viewer (not to mention deciding on the right kind of generic collection. So, since it is the weekend, let’s actually start there and we’ll get to the AutoComplete control (part 1 of many) in the next entry.
Creating A Data Set of Words
What I wanted was a very large set of words (so that when we’re working with the auto-complete you can start typing (e.g., ) acc and get quite a few words that match (accent, accompany, accordand, accordingly, accosted, account, accounted, accumulate, accurate, accustomed) That lets you continue to narrow, adding an o knocks out accent and accumulate, accurate and accustomed. adding an r gets you down to just two words: accordand and accordingly. You see the point.
On the other hand, I did not want you to have to download a large file just to make this work, and besides, it is more interesting if you can put in your own set. So! it doesn’t take much to write a program that reads a file from your disk (Silverlight doesn’t mind reading from your disk, it is writing to your disk where it is very careful). We take the file and read in all the words and after a bit of hocus pocus create a collection of unique words (that is, we eliminate all the duplicates and all the punctuation). Sort the collection and we have just what we need.
Here is how I chose to do it.
First, i needed a file, so I went to Project Gutenberg (a wonderful project well worth your time) where I was able to download a text version of Swan’s way by Marcel Proust (public domain). That will serve nicely as a source of words (and some interesting words at that!)
Second, I created a very simple UI as this is really just a utility. The UI has a button to open the file dialog, a TextBlock to let me know what is happening, and then two large TextBlocks encased inside ScrollViewers to show me the words I’ve retrieved. The left ScrollViewer displays the words in the order they were retrieved, the right displays them in alphabetical order,
Notice that I’ve only captured 4,298 unique words. That is because I told the code to stop retrieving words once it hit 100,000 characters – why sit around all day on a weekend and 4K words is plenty.
Here’s the code walkthrough; nothing terribly complicated, though with luck you’ll find something new or useful…
The key to having a nice scrolling block of text is to have the width of the text box be less than the width of the scrollViewer – enough to allow for the scroll bars.
In Page.xaml.cs I declare two private members, a StringBuilder and a List<String> and in Page_Loaded I provide the button’s event handler, which opens the file dialog,
The job of the event handler is to present the file dialog and then if hte user picks a file to open that file as a file stream, read through each line and using the string builder create a nice long string of up to 100,000 characters.
(Notice that this is not exactly industrial-strength code. )
In any case, once I have my string I break it into words by using the regular expression "\b" which separates the string into words which I put in an array of strings called AllWords.
|If you are interested in regular expressions but you find books and articles on them too abstract, I can’t recommend RegEx Buddy highly enough. You put in some text, and it (a) helps you build up your regular expression and (b) lets you test and (c) explains what works, what doesn’t and why. Caveat: it is not free.|
(Regex Buddy at work – from their site)
In any case, once my string is broken into words, I then iterate through each word to see if I have it already (I want only one copy of each word) and if not, I check to see if it is "junk" (has punctuation, numerals, etc.). If it passes muster, I add it to my list<string> and once done I display the results,
To be able to display and use the words, I’ve created two properties,
Here are the two missing helper methods:
The very next thing to do (now that this works) is to refactor into three classes: the original page, the code that opens the dialog box and the code that creates the data structure of words. I’ll do that next time and use that data structure to illustrate how to use the autocomplete box.