I fired up Visual Studio today and had a tinker with the code some more. I really want to get this thing out onto a GotDotNet workspace now since I've had quite a lot of feedback from people saying that this is just the tool that they want - a plug in to Whidbey/Express/VS 2003 that lets you work with RegEx expressions.
I had two problems when I last left the code. First up, for some reason the custom control that contains the UI wasn't quite figuring out which VIsual Studio session to attach to. When you fired up the project in debug mode, a second Visual Studio instance would get created, and the plug in would instantiate fine, but then it would start to work with code and windows in the first instance of Visual Studio. Since most people only ever run one copy of Visual Studio at a time I figured this wasn't a big deal if I couldn't fix it, but the anal perfectionist inside me kept on yelling that it had to be fixed. When the Connect event fires on a plug in, you are passed as the first parameter to the handler an object called application. All the example code that I've seen promptly casts this to EnvDTE._DTE, which is just the object I need to refer to the current instance of Visual Studio.
The problem though is that the user interface is hosted inside a rich windows forms user control which is loaded manually by the VSUserControlHost ActiveX shim control. Thankfully, the call that does the hosting (VSUserControlHost.HostUserControl) returns an object that just happens to be the user control that just got loaded. Bingo! I added a readonly EnvDTE._DTE property to my user control and set it from the plug in's Connect() event handler and all was fine.
The next problem I had was figuring out just what is going on inside the text editor. When you key a regex into the plug in and hit the Run button, the idea is that the plug in will run the regex against whatever you are currently looking at in the code editor. That way, you have complete flexibility to load in some sample data, a web page source file, or in fact anything you need to run the regex against and actually see just whether or not the regex works on it's target data. Ultimately you'll be able to scroll down the list of matches and click them to have the code window automatically scroll and show you just the matching string in the code window itself. Now that's slick. It just wasn't obvious exactly how I was going to do that.
Often when faced with a problem like this I find that sleeping on it for a day or three either magically causes the solution to pop into my head, or at the very least allows me to return to the code with a completely fresh perspective. It worked today, and I had the solution (or at least a solution) within a few minutes of sitting down.
EnvDTE._DTE has a great property called ActiveDocument. I'd come across this before but couldn't for the life of me figure out just how to get at the underlying text in the text editor through it. As it turns out, ActiveDocument.ActiveSelection is one possible answer. This returns a TextSelection object, whose Text property can be examined to find out just what text the user currently has selected in the code window. The TextSelection classes also has the fabulously named SelectAll() method. So, RegExinator now grabs the active document's current selection and looks at it's contents. If the contents are empty a quick call to SelectAll rectifies the situation, and the regex itself can then get run against the selected text. This is a great useability win I think. Not only will RegExinator run the regex you are working on against a text file loaded into the IDE, without walking you through any nasty file selection dialogs, but you can even select just a portion of that document to test against and really narrow down just whether or not the regex you are writing works the way you want it to. Result.
Now all I need to do is find a great way to display the regex results to the user in the tool window.
11:05:26 PM 
|
