Product Feedback woes and yet another macro

A while back, we received a suggestion via our product feedback website. The site lets anyone log bugs and/or suggestions for our product, which feed directly into our internal bug tracking mechanism. In other words, the site is not simply a façade but a direct input into our development, supplementing our internal testing (it’s hard to find every bug in a piece of code as large as Visual Studio) and helping us prioritize issues.

The upside of this website is that we have received valuable feedback, fixed real customer bugs (many of these fixes will be in our upcoming service pack) and identified certain features that are lacking and others that are slowly becoming superfluous. For example, many users voted on the fact that we lack support for code snippets in C++, a feature I would love to have and we are investigating providing this support in Orcas (our next release). When so many customers show their desire for the feature, it helps us allocate resources, something which is always in scarce supply

The downside of the product feedback is the simple fact that we can’t handle the quantity of bugs and suggestions that people submit (my personal opinion) and we’ve had to make some tough decisions with prioritization. While we fight to keep our product bug-free, we also understand the inescapable need to implement our customers’ suggestions. It’s one of the most simultaneously loathsome and attractive aspects of being a program manager at Microsoft. After all, few people in the industry can say they decide whether some feature will make it into a product used by millions

All this rambling has me straying from this post’s purpose. Yet another piece of (macro) code. Today’s macro was inspired by a suggestion we received via product feedback, which I deemed unworthy due to how easy it is to add using our extensibility model. Without further ado, here is a macro to preprocess the current file and bring it up in the editor.

Sub RunPreprocessor()

Dim doc As Document = DTE.ActiveDocument

Dim docname As String = doc.Name.ToLower

Dim project As Project = doc.ProjectItem.ContainingProject

If doc.Language = "C/C++" Then

' not the most accurate way of identifying a cpp file

If docname.EndsWith(".cpp") Then

Dim vcproj As VCProject = project.Object

Dim projfiles As IVCCollection = vcproj.Files

Dim vcfile As VCFile = Nothing

' find the file in current project

For Each f As VCFile In projfiles

If f.Name = doc.Name Then

vcfile = f

Exit For

End If


Dim activeconfigname As String = DTE.Solution.SolutionBuild.ActiveConfiguration.Name

Dim fileconfig As VCFileConfiguration = vcfile.FileConfigurations(activeconfigname)

Dim filecompiler As VCCLCompilerTool = fileconfig.Tool

' toggle preprocessing on, compile, toggle preprocessing

filecompiler.GeneratePreprocessedFile = preprocessOption.preprocessNoLineNumbers

fileconfig.Compile(True, True)

filecompiler.GeneratePreprocessedFile = preprocessOption.preprocessNo

Dim preprocessedpath = doc.Path + docname.Replace(".cpp", ".i")


DTE.ItemOperations.OpenFile(preprocessedpath + ".cpp")

End If

End If

End Sub

And the required helper function:

Sub ClearEmptyLines(ByVal filepath As String)

Dim line As String

' iterate through a file and write out non-empty lines into a new file

Using sr As New IO.StreamReader(filepath)

' out file name is <filename>.i.cpp (for highlighting)

Using sw As New IO.StreamWriter(New IO.FileStream(filepath + ".cpp", IO.FileMode.Create))

While Not sr.EndOfStream

line = sr.ReadLine()

If line.Length > 0 Then


End If

End While

End Using

End Using

End Sub

The implementation has two issues in its current form. The first is that changing the compiler property on the file causes the project file to change, which in turn requires checking out the project file and probably re-linking the project. The second is that the macro always rebuilds the preprocessed file even when there is no need to. I will post a follow-up, solving both of these issues.