Whenever I have trouble finding an example on the internet of how to do something in .NET, I usually throw the solution up here so that all of the other poor, unfortunate souls (like myself) have a little better chance of finding it in the future.

Today's solution is a quick one. It involves applying a format to a databound textbox. I recently delved into the wonderful would of Visual Studio Data Binding. I have always done all of my db calls manually in my code. But on this project, I was looking to basically replace an app that I wrote years ago in Access (which consisted of several forms bound to database tables), and the forms had a ridiculously large amount of fields on them (in the hundreds, all told)... so I didn't feel like coding all that myself.

As a result, I started learning how to use the "wizards" in VS.NET to add connections to a database. I created a Data Connection, a Data Source, a DataSet, dragged some controls on to my form (which created a BindingSource and TableAdapter)... and voila... my form is connected to a database.

But this simplicity is not without its problems....

OK... here's the problem. I'm lazy. But aren't all programmers? I mean... if it wasn't for laziness, we wouldn't have jobs. The whole point of programming is to find something that people don't want to have to do, and write code that will do it for them so they can keep being lazy. Am I right?

So when I run into an obstacle while programming, I like to find the simplest way to get around it. If the solutions that are already out there on the internet are cumbersome and complicated, then chances are, I'm not gonna use 'em. And that was the case when I ran into this little problem.

The thing is... most of my applications start new threads. Who wants to wait around staring at a frozen Windows form while something gets processed in the background? But at the same time, you can't just kick off a thread and hope that the user doesn't try to do something else while the thread is running. You have to control the work flow... keep the user in line. So you display some kind of "Please Wait..." dialog and use it to show them the progress of what's going on in the background. But what happens if something goes wrong in the background thread? You can handle the exception in that thread, but how will the main/GUI thread (the one that created the new thread) know that an exception occurred?

....I know how.

So I took a dive (head first, of course) into a new area of programming this week: The wonderful world of uber-large file processing. Now, I've worked with large files before... don't get me wrong... but I'm a database guy. Most of my file experience involves figuring out ways to get data into a database quickly and efficiently (and I've gotten fairly adept at it, if I do say so myself ). Recently, however, I needed to write some code to process a file, and as usual, my first assumption was that I would just load it into a db (using one of the bagillions of methods at my disposal), run a few SQL statements against the table, and be done with it. Then I found out that the file was almost 2GB. The problem with that is twofold: 1) Importing a 2GB file into a database would take a really freaking long time and then you'd still have to run queries on it to do your processing, which would take even longer. And 2) Putting the file in a db would have the net effect of doubling the file size on disk... because now it exists as the original file and as records in your db. And since most db's aren't super efficient at file storage, chances are that it'll take up more than 2GB in the db. So you're looking at turning your 2GB file into 4-6GB (if not more).

So anywhoo... once I realized that a database was not the way to go, I had to figure out how to process this huge monster in an efficient manner...

OK. Here's the problem... I want my .NET application (in this case, TaskRunner) to open a new instance of the user's default browser and direct it to a URL. Sounds simple, right? Well of course not.... this is Microsoft we're talking about.

Now, this is the part where you offer your pointless suggestions and ask irrelevant questions and tell me how I'm being an idiot for ignoring the oh-so-obvious solution to this problem... ("Hey stupid... just use Process.Start and pass it the URL!!"). But  notice that I said that I want to open a NEW instance of the user's browser. Unfortunately, if the user has Internet Explorer as their default browser, Process.Start (with a URL) will very often... not always, but sometimes (for reasons only known to Bill Gates himself) reuse an existing browser and direct it to the URL. So let's say you're sitting there replying to an email.... you've been up all night typing out some sappy love note to your girlfriend to try to get her to change her mind about dumping you... and you open TaskRunner's "WebSearch" app so you can search for snippets of crappy poety to include in your letter. Well, if IE is your default browser, then the WebSearch may very well commandeer the browser that you were using to compose that masterpiece of an email and direct you away from the work that you've spent hours pouring your heart into, thus erasing all that effort (and waste of emotion ).

Why, you ask? Because Process.Start(URL) does NOT always open a new instance of IE... but fortunately, I figured out how.... so you don't have to go through all the pain and emotional anguish of losing that email.