Visual Studio

VSX Add-in Development Adventures: Window.Object returns NULL

Elroy Dsilva — Sun, 30 Aug 2009 01:01:49 GMT

I’m in the middle of developing an add-in for Visual Studio 2008, a simple one that would help our in-house code review process. If you’ve ever written a VS add-in, you’d know the basic routine – Visual Studio creates the basic class Connect derived from IDTExtensibility2, then you put in your code in the methods OnConnection, OnDisconnection, OnAddInsUpdate, OnStartUpComplete and OnBeginShutdown.

I developed a few user controls (UserControl objects) for showing some UI as tool windows. One of them was AddCommentView which is just a dumb UserControl that displays some textboxes and buttons and also takes in some input. I deployed this control as a separate DLL and linked it to the add-in. Then, as usual, the following code should do the job of creating the tool window.

And like always it worked just fine till I tried to test it and that’s when I realized something wasn’t quite right.

The CreateToolWindow2 method has two outputs – the tool window (which is returned by the method) and the hosted user control (the ref parameter ‘objTemp’ in this case). The hosted user control can also be retrieved through the Window.Object property of the returned tool window. The problem was – no matter what I tried the Window.Object property always returned null and so did ‘objTemp’.

The solution – I was acting dumb, very dumb. Visual Studio requires all hosted controls to be visible to COM. After adding the attribute to the entire assembly using [assembly: ComVisible(true)] , everything started working like a charm (you can apply it even to the individual control if you don’t want to make the entire assembly COMVisible).

TaskList in Visual Studio - Making it better

Elroy Dsilva — Sat, 18 Apr 2009 16:59:00 GMT

It was great to come across a new feature in Visual Studio - The TaskList. Well, yes it isn't new but, it certainly was new to me. I had never really come across this wonderful feature until last week when secretGeek blogged that code would suck less if the compiler could raise an error when a // TODO token was detected. A comment from Goran indicated that it was completely possible with the current versions of Visual Studio.

A //TODO: token.

Are shown in VS if you click TaskList. Couldn’t live without this one :)

Yeah, sure. Can’t live without it. Although the compiler doesn’t throw you an error, it indicates all parts of code where such tokens appear and hence can be taken care of easily.

How To Use

You can use the TaskList comments for:

Features to be added
Problems to be corrected
Classes to implement
Place-markers for error handling code
Reminders to check in the file

Add your comment in the code preceded by the token.

Once done, open up the TaskList from the View menu.

Once the TaskList is up you will see something like this.

The TaskList also allows custom tokens to be included. Go to Tools –> Options –> Environment –> TaskList.

User Tasks

You can add your own tasks in the TaskList by selecting the ‘User Tasks’ selection from the dropdown list on the TaskList toolbox. These tasks aren’t associated with code, but will allow users to add their own high level tasks.

Extending the TaskList

I would like to see the following additional options in the TaskList:

Task Alarms – which would associate an alarm with a high priority comment to help just in case you forget to take care.
User Tasks to be more specific (by having a file anchor like ‘Comments’) to allow user tasks to be associated with a particular line in code.

And no, I’m not waiting on Microsoft to extend it in some other version of Visual Studio. I’m starting right away to write a package that would do this for me, hopefully.

More Things to Remember

With Visual Basic projects, the Task List displays all of the comments in the project. With Visual C# and Visual J# projects, the Task List displays only the comments that are found in the files currently opened for edit. With Visual C++ projects, the Task List displays only the comments that are found in the file currently active in the editor.

Personalize your application executable

Elroy Dsilva — Wed, 05 Nov 2008 10:17:52 GMT

You've written programs and created executables, and also probably distributed them. But, it would feel strange to pass on your .EXE as just-another-exe. Windows provides a default executable icon to your generated output EXE file which looks something like this:

Well, there's nothing wrong in having such an icon for your executable file. But, the hard work who put in in implementing the functionality within the EXE certainly deserves some credit and possibly a custom designed icon.

Lets see how we can do this. It's fairly simple. Once you're done with the coding stuff and you're ready to build your exe for release, go to the Project Properties -> Application tab -> Resources Group. Here, you will find the Icon and manifest radio button, select it and select the icon you need to use for your adorable application.

Please note that the above screenshot is the Project Properties tab for VS 2008 and it would look slightly different from the one you would see in VS 2005.

You now build the application and have a look at the generated executable which would look something like:

I created this icon by adding a resource (.resx) file to my project and then adding an icon to that resource file. Scribbled a bit using an MS Paint kind of pencil and here we go, I have a brand new icon (looks familiar, something like an inverse of Red Cross, but I could only think of this one right now).

Developer's Stash - ClearCase and My uncontrolled Source

Elroy Dsilva — Fri, 29 Aug 2008 05:33:14 GMT

I had some really funny time working with the Rational ClearCase source control software yesterday.

I'm not a regular ClearCase guy. In fact, I hate source control softwares. They're always a pain until you realize it's power. I've been working on ClearCase for like, five months or something, but, I still don't feel comfortable with it, especially when it's installed with Visual Studio 2005.

Yesterday, I tried renaming a file from "abc.cpp" to "xyz.cpp". Some crap happened in there and BOOM!!, the file was gone. Nowhere to be seen neither in the Clearcase Explorer nor using Windows Explorer. My mouth was left open and my lungs deflated by the very thought of writing 1000 lines of code again. Where did the file go?? I don't know!

The only thing I could think about then was to search for it. But how? Not manually through each directory, of course. Pop! I opened up Windows Explorer Search(which was unbelievably slow, considering the fact the my files were stored on a "high-speed" processing server connected by a "high-speed" network). Was it an attack by some freaky terrorist trying to destroy my valuable work? Windows search disagreed to my thoughts. Results showed that there a file named "xyz.cpp.04ac136e421d4108b617d79bf2aec045" in a directory called "lost+found". Now, what does that mean? Was my file lost?? Probably, it was, which is in turn very very strange and no one likes such surprises.

Thanks anyways to ClearCase for preserving a copy of the file before it lost it and folks, remember, to take care of this when renaming files using Visual Studio which are managed by ClearCase. Did you have any such crazy experience? More ClearCase and Visual Studio fun coming up from a developer's stash.