If you dabble into Regex-driven processing, this one can come in handy. For those of us who don't consider Regular Expressions regularly (ba-dum-tshh), coming up with one from scratch can take a little time... but I digress.

This particular regular expression should result in a match for all inputs, except those containing the specified string:

^((?!ipsum).)*$

The expression above will return a match for all inputs, except those that contain letter sequence 'ipsum'. 

Salt and pepper to taste, test it here.

Cheers!

Sometimes it can be handy to expose a directory on your hard drive as a 'virtual' drive. That is, make a directory appear as if it were another hard drive on your computer such that you can refer to it as 'D:\' for example.

Well, for honesty's sake, this is really rarely handy but hey.. One case I ran into recently involved sharing some files via Remote Desktop session. Unfortunately, RDP allows you to share drives, but not specific directories. Sharing all of C-drive did not make me feel warm and fuzzy, so I opted to just share specific directory, and that involved making Windows perceive it as a hard drive.

My solution is rather silly:

It can frequently be quite useful to ask the user to confirm their submit request in an ASP.Net page. There are a lot of code samples out there that "emit" javascript in the server-side function once the postback has been issued. This can be appropriate if you need to do parameter validation or any background processing before asking for confirmation. However, for situations where you just want to make sure the button was not clicked by accident, this works quite well:

<asp:Button ID="bnTruncateDB" runat="server" OnClick="bnTruncateDB_Click" 

Text="Truncate The Database" 

OnClientClick="return confirm('Are you sure you want to remove all DB entries?');" />

Recently, I ran into another candidate for the WTF files having to do with an error message similar to the one in the title of this post. Here is the scoop.

I created a WCF service library implementing some basic functionality. Actually, to verify the error I am describing, I just created a new WCF Library project and used the default code contained therein.

Subsequently, I created another project that would become the WCF client. Here comes the iffy part..

Typically, I do not like keeping default file names generated by Visual Studio (i.e. Program.cs). Reasons for this include search ambiguity, dislike of non-descript code files, and just personal taste.

However, one of the things that Visual Studio offers during the name change, is to change the name of the class contained in the code file. So, if you rename Program.cs containing the following:

This is a silly little UI feature that used to be default on previous versions of Visual Studio - navigating to and highlighting the code file that is currently being edited in Visual Studio in the Solution Explorer tree. Well.. Apparently it is not the default in Visual Studio 2008, and every time I install the Studio on a new box, I have to recall exactly what I did to get the task accomplished. So I figured I'd post it

So, in Visual Studio, go to Tools->Options, select 'Projects and Solutions' on the left hand side, select 'Genera' sub-item and make sure 'Track Active Item in Solution Explorer' is checked off.

Hope this helps,

Cheers!

Remote Debugging is not something that typically comes into play when working on standalone applications. Well, maybe that's not entirely true. My first exposure to remote debugging actually came about during some driver development I did back in the day - debugging a BSODing driver is best from a remote machine (and nowadays from a VM host..)

However, in the ever expanding world of distributed systems development, remote debugging can be key when the application being debugged is just a single node in a distributed system. 

When it works, remote debugging is amazing. Well, actually it's exactly the same as debugging a local application, but given that the application is actually running on a remote machine, which does not need to even have Visual Studio installed, it's pretty cool.

However, there are numerous gotchas to getting remote debugging to work, and by talking about the blogtitle error message,  I am starting somewhere in the middle. The exact message is:

In my rapidly diminishing spare time, from time to time I engage into ridiculous activities such as programming microcontrollers similar to the one pictured here (check out this site for similar goodies). Typically, the data exchange with these devices occurs via a serial port and I use a USB to serial adapter since COM ports are hard to come by these days.

For the terminal emulator software, I personally like to use Tera Term. However, as with other emulators, one of the annoying things is that it requires you to specify the COM port (i.e. COM5) for the connection, but any given time you plug the USB cable, you may not know what the resulting COM port is. Similarly, if you have multiple devices connected, things get confusing as well.

I've recently encountered this error in my error logging component. Naturally, an exception inside an exception handler is rarely a good thing and I was left scratching my head about what was going wrong.

There are numerous schools of thought in regards to what the best approach is to logging application errors. Consumer issues aside, when applications are administered by me or my team, I prefer using Windows event log or a file. In fact, I've written a general purpose library that allows an error, warning, or info to be logged in event log, text file, or displayed via user interface. 

Recently I was developing a little application that needed to enumerate existing COM ports on a machine and then display them in a menu. Generally, this task is quite simple to accomplish:

System.IO.Ports.SerialPort.GetPortNames();

I believe under the hood, this method simply enumerated the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM key.

However, the tricky part was that I wanted to display human-friendly names that identify the device similar to they way they are displayed in the Device Manager. Well, this turned out to be a little more complicated than I thought.

Google revealed a couple of strategies that turned out to be limited. 

1. WMI

There are a couple of WMI objects that one could enumerate to get a list of ports. However, none seem to produce a complete set.

SELECT * FROM Win32_SerialPort
or
SELECT * FROM Win32_PnPEntity

Sometimes enhanced security translates to enhanced frustration. I think the exception gracing the title of this post is a decent example of this phenomenon...

This exception occurs in a couple situations involving creation of an EventLog object. Legitimate causes include: