Red-Gate's SqlPrompt is an utility that makes you wonder how could you live without it. It is basically an application that runs in the background and adds "intellisense" support for Sql Server. In brief: (after 2 mins of testing)

• it adds "intellisense" support to a variety of editors that deal with T-Sql (Query Analyzer, Sql Server Management Studio, Enterprise Manager, VS 2003, VS 2005, UltraEdit and EditPlus2 are on the current list). And not only name completition. It can add relations, too. Plus other not listed features.
• it just works as one would except
• free until 1st September 2006

I can't even describe of how great help is this utility for all of us who type t-sql statements over and over. How could I live without it?

Download it here.

Found via Slovene Developer Users Group forum.

I just run across this valuable article. It talks about how to debug Windows Forms Designer errors you get on the screen when something goes wrong and I am pretty sure you get them here and there. So, if the error message that appears on the screen is not informative enough to solve the problem, or you are just plain curious, you can debug entire VS IDE and find the reason for the error WFD is throwing at you.

BTW, debugging whole IDE has other benefits, such as finding problems in components at design time.

Have fun digging into VS IDE.

I've just uploaded slides from my presentations on NTKonferenca 2006. Find them here.
Sorry for the delay.

These days I’ve came across this situation – related to [DevEx]' XPO:

XPCollection<Customer> coll = new XPCollection<Customer> (session, false); // false means LoadingEnabled = false; coll.Criteria = new BinaryOperator(“SomeColumn”, “SomeValue”); coll.LoadingEnabled = true;

This piece of code creates an instance of generic XPCollection that deals with Customer list. Next I set the condition to use for data retrieval and at the end I say that it is OK to load the data (note that XPCollection does lazy load). However it won’t work like that. Second line will throw an exception: can't reload collection with disabled loading. The solution is quite simple but perhaps it won’t work always for you - just switch second and third row to get code like this:

XPCollection<Customer> coll = new XPCollection<Customer> (session, false); // false means LoadingEnabled = false; coll.LoadingEnabled = true; coll.Criteria = new BinaryOperator(“SomeColumn”, “SomeValue”);

If you ignore the fact that it doesn’t allow you setting the condition before loading (unless you do it in constructor), which I struggle to understand why, you’ll see another issue. The guidelines for creating properties say something like (out of my memory):
It shouldn’t matter the order of setting properties
Properties shouldn’t perform any actions and should return the same value when called multiple times in a row

Clearly the way that XPCollection works is against first rule but not against second rule as one would assume from the exception text as it really doesn’t perform any action when setting Criteria – it just throws an exception if LoadingEnabled is disabled. I hope that this behavior will change in the future as it is against guidelines and it doesn’t allow you to construct Criteria before loading is enabled.

Dejan has an interesting commentary on this year's NT konferenca. I have to say that I agree with him - he is getting old. Just kidding. I agree with his assertions. The conference was really well organized. I haven't had a single problem related to organization (I just forgot my id card on first day - my fault) and everything really run smooth. I can't comment on presentations since I didn't have much time to attend them but they looked fine to me (from agenda) and those which I've attended were really great.

And the description of sponsors circus is an accurate one and I won't repeat it as Dejan described it well and I, also a speaker, agree with him.

During my presentation on BackgroundWorker I got a smart and obvious question: What kind of thread does BackgroundWorker create or use. I saw this coming it is just I haven't had time to check it out before the presentation. This was first thing I did once I got home. I fired up Reflector (as usual) and examined the inside of BackgroundWorker. My guess was that BackgroundWorker is creating a worker thread internally. Since the long operations are rare and one needs to run them asap this would be the behavior I expect. However, this is not the case. It is using a delegate and its BeginInvoke method internally. This makes BackgroundWorker depending on the ThreadPool. ThreadPool worker thread pool size is by default 25 on my machine and I assume it is more than enough for most of the WinForms applications so you don’t need to worry about. But if you run out of available threads BackgroundWorker won’t start the operation until a thread is available again. If you have this situation then you have three options:

1. leave it as is – the user will just have to wait a bit more
2. increase max thread pool size (ThreadPool.SetMaxThreads static method).
3. use a worker thread directly instead of BackgroundWorker

It is up to you which path you'll go in this rare, but possible situation.

If you are using either GPSDash or GPSTuner image GPS navigation software you'll notice that their map database isn't nearly as huge as OziExplorer's. That's why I've created a free utility that converts OziExplorer's map file to other formats.

Note: It converts only map file but not the images.

Download it from here.

For the third consecutive year I'll be speaking at Microsoft NT konferenca 2006 in Portorož.

I'll speak about Windows Presentation Foundation and DataBinding (tuesday at noon) and DLinq (thursday at 13:00) plus a small but useful presentation for my SLODUG - Slovene developer users group on wednesday at 18:00.

See you there!

Did you ever write a code like this:

public void SomeMethod() { StreamWriter writer = new StreamWriter("c:\\temp\\tubo.txt"); writer.Write(1); }

Of course not. It should look like

public void SomeMethod() { using (StreamWriter writer = new StreamWriter("c:\\temp\\tubo.txt")) { writer.Write(1); } }

The difference is that the first sample doesn't invoke Close() or Dispose() on StreamWriter while the later does. Needless to say that you have to call them (Dispose is enough as implicitly calls Close if necessary) and the first sample might result in loss of data because StreamWriter implements buffered write that is flushed on Close.

But still it might happen even to you that you forget to Close the StreamWriter (I know, I know it won't happen to you, but just in case). The good news is that VS2005 will help you to find this bug through one of its so called Managed Debugging Assistants (MDA) named StreamWriterBufferDataLost. MDAs are watching your code for various kinds of bugs while it executes. Find more about MDAs in this excellent MSDN Magazine article. Anyway StreamWriterBufferDataLost MDA isn't turned on by default - you have to turn it on explicitly: open Debug/Exceptions window and expand Managed Debugging Assistants node.

That's it. Next time debugger steps over such bug you'll get this nice exception:

A StreamWriter was not closed and all buffered data within that StreamWriter was not flushed to the underlying stream. (This was detected when the StreamWriter was finalized with data in its buffer.) A portion of the data was lost. Consider one of calling Close(), Flush(), setting the StreamWriter's AutoFlush property to true, or allocating the StreamWriter with a "using" statement.

Having exception right at the time instead of seeing some strange behaviour here and there is of tremendous help, isn't.

And I am pretty sure that few people noticed these precious helpers. So now you know - use them and they'll help you a lot.

One of the biggest Linq improvements from the last CTP is IQueryable<T> which allows polymorphic and dynamic queries. Matt explains it well in this post.