May 2006 - Posts
A couple of weeks ago, I got an email from
Builderau describing
how to use snippets in Visual Studio 2005. I was kind of amazed to see that they provided two links to "snippy" editor, but not a single one link to the VB Snippet Editor. That's despite the
VB Snippet Editor being open source and also linked to from MSDN. Other magazines, MSDN magazine, Code magazine, DevX to name just a couple have all linked to the VB Snippet Editor. Perhaps I am too close to the project, but I would say the VB Snippet Editor is a far superior tool, providing compilation testing, snippet management, code coloring etc, etc. But in any case, you'd think that BuilderAu would as their name suggest at least highlight work done by fellow Aussies !!
Okay so I let that one go pass (until now that is) as I thought perhaps I am too close to the matter at hand. But today's email just totally pissed me off…
Apart from the fact the article was incredibly shallow, barely even touching the surface of the differences, the author clearly doesn't know sh*t about VB.NET. He goes on about how VB.NET does not have unsigned integers. Seriously, where has he been, or what orifice has he got his head in ? How hard is it for them to stop and
RTFM before writing such trash.
Have you ever wanted to display the data connections dialog to your end user ? Well in VS 2005 there's a set of new controls you can use to do it…
First add references to the following two assemblies:
- Microsoft.Data.ConnectionUI
- Microsoft.Data.ConnectionUI.Dialog
You'll find these two assemblies in your Visual Studio IDE folder. You'll need to distribute them with your app, 6KB and 384KB respectively, if the user doesn’t have Visual Studio installed, but As David pointed out these assemblies are not listed in the redist.txt, so you probably are NOT allowed to redistribute them. That is, you can only use these if the user has Visual Studio installed, which of course is totally ridiculous as these files come with FREE versions of Visual Studio !!!
Once you have got these assemblies then you can easily add a connection control to a from and have your own connection dialog. For example to add the dialogue as you'd see it for a SQLconnection, you can just add a new
Microsoft.Data.ConnectionUI.SqlConnectionUIControl
control to your form.
The only other thing you need to do is initialize the SqlConnectionUIControl. You do this by supplying the control with an IDataconnectionProperties implementation, in this case an
Microsoft.Data.ConnectionUI.SqlConnectionProperties
is the perfect fit :)
So assuming you named your SqlConnectionUIControl as SqlConnectionUI and declared it WithEvents, your code to intialise it might look something like this:
Private props As New Microsoft.Data.ConnectionUI.SqlConnectionProperties
Private Sub SQlConnectionUI_Load(ByVal sender As Object, ByVal e As EventArgs) _
Handles SQlConnectionUI.Load
SQlConnectionUI.Initialize(props)
EndSub
And there you have a simple SQL connection dialog.
With the onset of winter here I haven't been riding my
bike much (at all !!). I've got too much on, and the weather is rarely conducive to an enjoyable ride. So since my last
1000 km for the season post, I think I've only added 500 or 600 km. Anyway, what I really wanted to talk about was lubricants.
I ride a lot on gravel tracks, some dirt and some sand. Sand is really a lot of fun, it's an art to itself, and just about always makes me laugh. but with wet lubricants I was running into a lot of gear problems, and even had chain follow through a couple of times. Chain follow through is when the chain sticks to the front cog and tries to wrap around it.
So 500 km or so ago I changed to a dry lube,
ProLink. My first impressions was it was really good. I didn't say anything at the time though as I really wanted to "road test" it. It really is a fantastic lubricant. I can give the bike a quick hose down and it's fine to ride again, instead of having to just about degrease it like you do with wet lubes. Really easy to maintain. But alas, there's no free lunch…
today was/is such a beautiful day I thought I'd ride to the shops. It's a 24 km round trip, although I can make it more, and vary the intensity depending which hills I decide to take. Thing was I hadn't ridden in weeks, and my bike had been sitting in the shed all this time, and I had probably washed it down quickly after my last ride, but hadn't stopped ot lubricate it. The result … CHAIN RUST !!
I've heard others say the same about ProLink, as in it is not a good lube if you are going to over winter your bike. That being said, it only took me 3 or 4 minutes to get the chain clean again and in top condition by just applying some ProLink and then wiping the chain down with a rag (running the chain backwards through it). And because ProLink cleans as it lubes, the chain was nice and shiny again in no time and ran perfectly.
So all in all, I highly recommend ProLink, with of course the caveat of over wintering your bike, or leaving it for a long time after it got wet without re-lubing. Oh, speaking of which, re-lubing is basically put a few drops of oil on a rag and run the chain backwards through it. No mess, and your chain is always nice and clean and well lubed !!
I was just reading
Avner's blog entry about the latest LINQ bits and VB 9.0, in particular the bit about the Value Extension Property. How cool is that !!!! :)
So it occurred to me that perhaps extension properties are better than "normal" properties. Because an extension property is basically a shared property that get's passed an instance of the type being extended, it allows the testing for null to be encapsulated in the property itself.. This allows you to write cascading statements without needing to break them into temporary variables and null tests, eg:
consider this code using normal properties:
Dim doc as Documents = MyDocs.ActiveDocument
Dim hdr as Header
If doc IsNot Nothing Then
hdr = doc.Header
End If
Dim style As Style
If hdr IsNot Nothing Then
style = hdr.Style
End If
Now look at it if all those properties were extension methods :
Dim style As Style = MyDocs.ActiveDocument.Header.Style
Because extension methods allow null propagation, we don't need to test for null along the way. that is, rather than focusing on the wiring, we can instead focus on the task :)
The From ..Select syntax has many advantages, the biggest being a great intellisense story. I also think it is good is distinguishes itself from TSql, because although DLinq may use TSql, LINQ itself does not.
Dim WACusts = _
From c In Customers _
Where c.State = "WA" _
Select c
Could be written as :
Dim WACusts = _
From c In Customers _
Where c.State = "WA"
As the Select c is really superfulous.
Further we can even make the "From" bit implied when doing loops:
For Each c As Customer In Customers Where c.State = "WA"