But wouldn’t it be great if… VSCmdShell Progress

I spent Thursday night with the VSCmdShell code.  Having just released v0.6 that now defaults to the VS environment paths I was determined to clean some stuff up before the next release.  I refactored the code a bunch to make it more readable, I made issuing VS commands actually work reliably by removing my hack that had been calling them through the Command Window and now just calling dte.executecommand(...) while parsing arguments, and I fixed bugs to the point where I said “Wow, I could see someone using this on a daily basis without cursing me now”.  What did I do next?  Did I upload this stable code?  Did I at least post v0.7 so users could try out a good stable build?  No...

I said “Wow, this is really cool, but wouldn't it be great if I went all out and supported intellisense and defined a settings file to store configurable options in?”.  A classic trap.  So now I'm in the middle of this transformation with a product that proves my concepts but is not yet worth using again.  Nothing is checked in yet, but I'm hoping to check some of this stuff in and release a much improved v0.7 Monday.  For now here is a preview.  The intillisense box, you should imagine, would be filled with available VS command like “File.Openfile” or directory information depending on context. (Yes, this is all running as a tool window inside VS!)

Comments (8)
  1. Todd Spatafore says:

    Wow! That is an incredibly cool feature. While reading this entry I thought of about 50 uses for it in my day to day work.

  2. Bob Archer says:

    Gee… keep going! Some day you may even get close to the command window that Visual FoxPro provides. A place where I can test one or more lines of code, open data tables and manipulate their data, run add-in’s that put themselves on the menu.

  3. jledgard says:

    Todd: Thanks for the encouragement. You might want to try out the current build that is released. I’d love to get your feedback on what else I should be doing to make it easier to use.

    Bob: Hard to tell if there is sarcasm there or not. Have you tried out the current command/immediate windows in VS 2002/3? All the features you mentioned there seem possible today. The only thing I’m really adding is putting a cmd shell into the mix as well.

  4. This looks like a really nice project. It could be really useful for running a few Perforce commands without switching windows. I did have a few problems though:

    – I couldn’t find the window! (the only way I could make it appear was by unloading and reloading the add-in – am I missing something?)

    – Running commands in the window caused a crash (for example, typing "cl" with no arguments displayed the complier banner then crashed Visual Studio. The same thing happened if I ran "p4 diff").

    – It would be nifty to have a keyboard shortcut to insert the file name of the active tab into the command window (so I could type things like "p4 edit " then press some magic key to insert a file name)

    I was going to download the source code so I could give you a better bug report but I failed. Either I am being stupid (again) or getting source code from GotDotNet is like extracting blood out of a stone. First it wanted me to sign in with Passport then it told me my browser (Firefox) wasn’t good enough and then when I did tried to download the files with Internet Explorer I couldn’t find a link to download the whole project.

    Jonathan (not having a good day)

  5. josh ledgard says:

    Jonathan: I haven’t optimized the install/uninstall/command placement yet. So I know there are some bugs around where the command is and having it show up. I plan on adding it to the view menu and being more robust about keeping the command there in a final release.

    I think the command handling is better in the code I haven’t checked in yet. But I’ll investigate.

    Getting code currently does require signing up through gotdotnet for the workspace. I’ll make no comments about GDN browser compliance. For the next release I’ll include the release source in the zip. Look for this today or tomorrow.

  6. Bob Archer says:


    Yes, a little sarcasm and a major ER.

    I misunderstoed your Shell window which looks like a way to control VS itself. In VFP the command window does this also. I can run any command to perform any task in the IDE that needs to be performed. I can also run any code that I might put in a program to test and try out.

    Perhaps you could point me to more information on the Immediate window… I really haven’t seen alot on how to use it. My understanding those is it is just an expression evaluator.

    My understanding is in VS the immediate windows is only available while debugging. In VFP the command window is available all the time. For example, if I want to debug a method of a business object I just built, in the VFP command window I can:

    1. Create an instance of the bizobj:

    oX = createobj(‘CustomersBO’)

    2. Call a method which brings up the debugger:


    3. I can print the value of properties:

    ? oX.FirstName

    4. I can process a loop that creates a collection of customer objects:

    oBOColl = createobj(‘collection’)

    For X = 1 to 100

    oBOColl.Add( createobj(‘CustomerBO’,x) )

    Next X

    5. List all the names of the customers:

    For Each oCust in oBOColl

    ? oCust.LName + ‘, ‘ + oCust.FName


    In VS, if I want to test a bizobj, I have to create a console app or web page to do the testing. In VFP, I can use almost 100% of the language. (Language macros don’t work.)

  7. jledgard says:

    Your right about it only being availible during debugging. Unfortunatly that’s not something I’ll be able to easily enable in my project. Controlling VS (non-Code) is something I do support just like the current command window.


Comments are closed.

Skip to main content