Create User-Defined Environment Variables (Macros) in Visual Studio

Due to difficulty on the Google Docs side, I cannot easily publish my note from it here (at least in the good old way). So, please follow this link to read my note in a full screen mode. If you have any comments or suggestions, please let me know.

Note: there is a discussion about this difficulty in this link. I resort to an iframe tag, but it is not as good as I want. Please see below. I think I will have to do this for a while.

TracExplorer and VS 2010 Integration

(Nov 27, 2010)

Introduction

Caveat: I'm new to an issue tracker system.  How I use Trac and TracExplorer, as described here, may not be a good practice, but it worked.
(you can skip the introduction if you already know Trac and TracExplorer well)

Trac is an interesting issue tracking system.  Its default feature set provides what many software developers need.  Trac's plugin architecture also allows us to add more features to the system if we need them.  Therefore, default Trac is useful and relatively simple.  Extended Trac is more powerful, but may be complicated.  Using Trac inside the Visual Studio can also be convenient, provided that the integration provides adequate features and user interfaces.

TracExplorer has a fascinating idea for VS 2005 and 2008 integration.  However, the available binary in source forge does not work with VS 2010.  In addition, TracExplorer (as of version 0.20 beta) is not feature rich.  It is rather inadequate and not improved for months.  For example, TracExplorer does not allow the user to create a new ticket.  A typical web-based user interface is needed.  Yet, it allows us to quickly view and modify tickets.  Many people may be satisfied with the available features.

This integration contains two parts: installatiion of Trac's XML-RPC plugin, which is a requirement of TracExplorer, and VS 2010 integration.

Installation of XML-RPC plugin

1. Get the plugin by downloading its source package.  Don't worry that you do not get the binary. The actual installation is simple.
   
   
2. Extract the source package to a preferred folder.  Inside the package, we mainly use the source inside the trunk.  Other folders usually contain outdated version provided for compatibility.
   
   
3. Generate an 'egg' package. This step requires Python, but we should already have it installed as Trac's prerequisite.  A default Python's folder from BitNami is "C:\Program Files\BitNami Trac Stack\python\python."
   Therefore, in the command prompt of the trunk folder, type
   
   "C:\Program Files\BitNami Trac Stack\python\python" setup.py bdist_egg  [Note: the double qoutes are needed to dealing with a path with space.]
   
   
4. The necessary outputs is in the newly created 'dist' folder.  Copy all *.egg files (typically, there is only one egg file for this plugin) from there to Trac's plugin folder.  An example of the plugin folder is
   "C:\Users\username\BitNami Trac Stack projects\InitialProject\plugins"
   
   
5. change trac.ini of a project that wants to use the plugin by including lines
   [components]
   tracrpc.* = enabled
   
   Note that if the [components] section already exists, there is no need to create a new one.  Just append 'tracrpc.* = enabled' to the section.
   
   
6. Restart the apache service.  It is important to note that the service name is tracApache if you use BitNami.  If you need to run this service from a command line, use
   "C:\Program Files\BitNami Trac Stack\apache2\bin\httpd.exe" -k runservice

If you want to install this plugin for every project, try using easy_install descriped in Trac website.

Visual Studio 2010 Integration

This section is probably why you come to this page.  You may think that you need an installer for integration, but it is not necessary at all.  All you need are compatible add-in binaries and add-in description file.

1. Download the package I built from this link.  This package includes binaries and description file.  If you are interested in how I prepared the package, see the next section. 
   
   
2. Unpack it to your preferred folder.  No need to bother with "Program Files".  Any folder will do.
   
   
3. Open VS 2010.
   
   
4. Go to 'Tools->Options.'
   
   
5. In the 'Add-in/Macros Security' in the 'Environment' node.  Then, 'Add..' the path to the folder in you chose in Step 2.
   
   
6. Close and reopen VS 2010.
   
   
7. Verify add-in installation: (1) Go to 'Tools->Add-inManager'.  You should see TracExplorer.VSTrac listed there; (2) By clicking 'View' in the menu bar, you should see 'Trac Explorer.'
   

Preparation of Binary Package

This part is for those who are curious about how I built the add-in from the source code provided in SourceForge.net.

Note: I do not modify any source code.  I just rebuild the binary and add a proper add-in description file.

1. Install TortoiseSVN in its default folder.  You need TortoiseSVN, as the build script uses a file from TortoiseSVN.  The file is specified by the default path of TortoiseSVN. If you already installed it elsewhere, see note at the end of this section.
   
   
2. Check out the source tree from SourceForge.  The SVN command is 'svn co https://vstrac.svn.sourceforge.net/svnroot/vstrac vstrac.'  If you use TortoiseSVN to do this, just enter the URL https://vstrac.svn.sourceforge.net/svnroot/vstrac.
   
   Do not use GNU tarball, as the build script needs to obtain some information of the SVN source tree.  This information is automatically available if you use SVN to check out the source tree.
   
   
3. Go to the 'trunk/src' folder.  Use VS 2010 to open TracExplorer2008.sln.
   
   
4. Rebuild the solution in a release mode.  Whatever you try to do, you will get x86 binaries compatible with VS 2010 in the 'trunk/bin' folder.
   
   

Note: What if I installed TortoiseSVN in a non-default foder?
In this case, version_scm.bat in the 'build' folder will not work.  You, however, can specify your TortoiseSVN path by modifying the batch file.

Trivia: In SourceForge, this software is called TracExplorer, but in Visual Studio's view, it becomes Trac Explorer (with space added).

Hope this helps,
Pinyo

VTK Installation on Windows 64-bit for Visual Studio

VTK Installation on Windows 64-bit for Development in Visual Studio

VTK installation in Windows 32-bit is typically painless, as the platform was already tested by many developers and became mature.  (Yet, if you have a problem with it, the troubleshooting note at the end of this page might help.)  For Windows and VTK 64-bit, however, we may encounter a few issues.  This note describes what I did to install VTK 5.6 on my MS Windows 7 Home Premium 64-bit.  This note should be applicable to those who need to do the same thing.

The first part is for installation with default VTK build options.  These options are VTK_USE_CHARTS, VTK_USE_GEOVIS, VTK_USE_INFOVIS, VTK_USE_N_WAY_ARRAYS, VTK_USE_RENDERING, and VTK_USE_VIEWS.

1. Download VTK 5.6 source from http://vtk.org/VTK/resources/software.html.
2. Extract it to create a source folder.
   
3. Open CMake (I used 2.8.1, and it is supposed to work with the most recent version at cmake.org).
4. In CMake, choose a source and binary folders (Figure 1).
   
   
   
   
   Figure 1.  CMake 2.8.1 after source code and binary folder selected.
   
   
5. Click the 'Configure' button.
6. CMake asks about generator (compiler) we want to use (Figure 2).  The one we want to use is Visual Studio 9 2008 Win64 (the one without suffix Win64 is 32-bit) with 'Use default native compiler'.  We can also use Visual Studio 10 Win64 if a target development platform is Visual Studio 10.  Using MinGW will generate incompatible binary for Visual Studio development.  In addition, 64-bit MinGW is quite tricky to use as of Aug 2010.
   
   
   
   
   
   Figure 2. 'Choose compiler' dialog
   
   
7. If initial configuration goes fine, there will be no critical errors and VTK build options will be available for us to choose (Figure 3).
   
   
   
   
   Figure 3.  Build options for VTK after the initial configuration.  Red regions in CMake highlight new options since the previous configuration.  As this is the first time, every option is new and highlighted.
   
   
8. I used the default options.  This option builds a static libraries, which is what I prefer.
   
9. I think options VTK_USE_PARALLEL may help speed up processing in a multi-core system, but I need to learn more about it.  Also, VTK_USE_QT is probably good for me, as I have used Qt a lot recently.  Yet, I need to know what it does first.
10. Click the 'Configure' button again when options are settled.
11. Click the 'Generate' button to generate a proper visual studio solution tree.
12. Go to the output folder specified earlier, you should see 'VTK.sln'.
13. Open the solution and 'Build Solution'.  It will take a while to finish (around 5-10 minutes).  Note that if you only want to use VTK and do not intend to debug into its source code, it is recommend to build it in the release mode.
    
14. In the solution tree, right click on the 'INSTALL' project and 'Build'.  Update Dec 15, 2011: some systems may experience a build error due to write permission to C:\Program Files (x86).  This depends on your Windows settings.  One way to solve this issue is to close Visual Studio and run it 'as administrator' (credit to Alex Southern, see his comment below).
15. The outputs are kept in C:\Program Files (x86)\VTK.  Both include and lib folders are what we are going to use in further software development.
    
16. If you want to build both 32- and 64-bit packages, move the outputs to another folder and repeat the process.  Only the generater in step 6 is needed to change.  We have to move the current outputs because new outputs will be saved to the same folder.
    
    

Build VTK with parallel-processing and Qt-support options

Next, I will discuss installation of VTK with additional options for Visual Studio 2008.  These options are VTK_USE_QT and VTK_USE_PARALLEL.  We can jump to step 7 discussed in the last section. At this point, we only need to check the QT and PARALLEL options and then, hit the 'Configure' button the project again.  CMake will configure the project and comes up with two new options highlighted in red (Figure 4).  Once you set QT_QMAKE_EXECUTABLE to your target version, hit the 'Configure' button for the third time.  If every thing goes fine, you will get a refreshed dialog with message "Configuring done", as depicted in Figure 5.  There are chances that you did not succeed or get a wrong Qt version.  If the latter is your problem, read the caption of Figure 4.  If it fails for other reason, please see the troubleshooting note at the end of this document.  I hope it has what you need.

The rest of the process is generally the same.  If you encounter linking errors when you build VTK in Visual Studio, see Topic 2 in the troubleshooting note provided below.

Figure 4.  CMake after the second configuration with QT and PARALLEL.  QT_QMAKE_EXECUTABLE is selected by what you do with Qt integration for Visual Studio.  In other words, CMake checks the path of default Qt version you set in Visual Studio and use it here.  In fact, CMake and VTK build script strictly use the default Qt version.  You cannot effectively change Qt version here, as it will be eventually reset to the VS default version. Therefore, you may need to open VS and change Qt default version to set QT_QMAKE_EXECUTABLE.

Figure 5. A successful configure dialog.

Troubleshooting Note for Qt Option

1. Problem: "I specified qmake path correctly, but it seems that CMake looks for qmake in a wrong path."

Solution:
You may set QT_QMAKE_EXECUTABLE to point to qmake correctly, but this problem may arise since CMAKE will use outdated qmake properties, such as QT_INSTALL_PREFIX and QT_INSTALL_BINS.  For example, you build Qt in one path and later on you move it to another.  The properties, however, is fixed at the time you build Qt.  You can confirm this issue by going to qmake's make folder and using the command prompt to type 'qmake -query' to see all qmake properties.

If the issue is confirmed, you need to compile qmake again (not the whole Qt library set).  Alternatively, you can just move or copy your Qt directory to the old place to resolve the issue.  If moving or copying Qt folder is not an option, you can quickly re-compile qmake by

• Rename the bin and qmake folders of Qt to something else.
• Copy the pristine bin and qmake folders from the Qt source to the Qt folder.
• Configure Qt from Visual Studio command prompt.  For example, by using 'configure -platform win32-msvc2008 -release -static -opensource -nomake demo -nomake examples -no-qt3support -fast'.  You probably did this before when you compiled Qt libraries.
• Copy things from the old bin and qmake folders to your current bin and qmake folders, but make sure you do not replace the new qmake you just compiled.
• Now, you have qmake with updated qmake properties.  I hope you can configure VTK in CMake as usual from this point.
  
  
  

2. Problem: "I got linking errors when I build VTK in Visual Studio.  It complained about PlaySoundW, WSAAsyncSelect, and many more."

Solution:
Based on my experience, this problem is platform specific.  You may encounter this issue if you use static library version of Qt and the problems in 32-bit and 64-bit platforms are not the same.  These linking problems, however, are related to Windows libraries and occurs when your VTK build script does not correctly include them.

Fortunately, you can include corresponding libraries yourself with ease by following the guidelines described below.

• Identify problematic projects.  Potential problematic projects are QVTKWidgetPlugin, QVTK, QtChartCxxTests, ChartCxxTests, and QVTKCxxTests.
• Search the Internet (or use your prior knowledge, or your MSDN documents) to identify corresponding libraries.  For example, the corresponding library of PlaySoundW is Winmm.lib and that of WSAAsyncSelect is Ws2_32.lib.
• Add the libraries to the Visual Studio project properties, as you do normally.  Basically, you can right click the project in the Solution Explorer of Visual Studio and select 'Properties'.  Then, go to node 'Configuration Properties -> Linker -> Input' and insert the library name to 'Additional Dependencies'.

3. Problem: I checked 'VTK_WRAP_PYTHON' and CMake errors occurred.  It complaint about PYTHON_INCLUDE_DIR AND PYTHON_LIBRARY.

The error message looked like:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake files:

PYTHON_INCLUDE_DIR

PYTHON_LIBRARY

Solution:
The two CMake variables seem to come and go and not consistent over VTK versions.  You might want to add them yourself to CMakeLists.txt.
First, locate IF(VTK_WRAP_PYTHON).  Then, modify the section to something like

IF(VTK_WRAP_PYTHON)
  SET(VTK_LANGUAGES ${VTK_LANGUAGES} PYTHON)
  #Addition by Pinyo
  SET(PYTHON_INCLUDE_DIR "C:/Python31/include")
  SET(PYTHON_LIBRARY "C:/Python31/libs/python31.lib")
ENDIF(VTK_WRAP_PYTHON)

Please note that PYTHON_LIBRARY is the actual library file, not just a folder (although you sometimes see the term python libraries and think that it is a lot of libraries, not a single file.).
Finally, configure and generate make files as usual.


4. Problem: I used VS 2010 64-bit and CMake 2.8.3 and got Q4VTKWidgetPlugin.h(57): error : Undefined interface.  This corresponds to line Q_INTERFACES(QDesignerCustomWidgetCollectionInterface).

Solution:
This is, in fact, a CMake problem.  To be exact, the QT_QTDESIGNER_INCLUDE_DIR is not set correctly.  An example of the value is include/QtDesigner/.  This option is available if we want to generate MinGW Makefiles.  This option also was automatically set in the past and it was correct.  For an unknown reason, it does not work on some machines (VTK 5.6.1 as of Feb 18, 2011).

To solve the problem, go to folder GUISupport\Qt and open CMakeLists.txt.  Then, add a line
SET (QT_QTDESIGNER_INCLUDE_DIR "G:/Workspace/Qt/qt-release-4.7.1-vs2010/include/QtDesigner")
Make sure you adjust the ad hoc path to what suits your computer.

The above line should be added right after FIND_PATH(QT_QTDESIGNER_INCLUDE_DIR QDesignerComponents ...), as the function FIND_PATH may not work correctly in your build.

Hope this helps,
Pinyo Taeprasartsit
(Aug 2010, Feb 2011)

Importance of WINVER definition in Visual Studio 2008

(Mar 19, 2008)

Recently, MIPL starts to port stuff to VS 2008. It turns out that code compiled on Vista worked 100% correct only on Vista, but on Windows XP, it showed some glitches.

This is because the default WINVER in VS 2008 is 0x0600 (Vista). Thus, when we build our code, it will perform some Vista specific links, and an executable file may not work correctly on XP.

To solve this problem, just go to StdAfx.h and put the definition of WINVER to XP:

#define WINVER 0x0501

With this definition, built executable files should work on both XP and Vista.

Suppressing First-chance Exception in Visual C++ 2005

(Feb 1, 2008)

I encountered a lot first-chance exceptions in my program when I debugged my program in Visual C++ 2005. Exception messages in the output window can be annoying if they cloud other important messages. After searching the Internet for a while, I found a simple solution about this on http://www.helixoft.com/blog/archives/24 . I can tell a window output not to show 'exception messages' by right clicking within the output window and uncheck 'Exeption Messages'.

If you want to know more about first-chance exceptions, follow links in the http://www.helixoft.com/blog/archives/24

Visual C++ and LNK2005 Problem

Sep 16, 2007

Today, I badly got strucked with LNK2005 error in Visual C++. According to linking error messages, it was a conflict between nafxcwd.lib and uafxcwd.lib. This issue will arise if one module (library or executable) "Use Unicode Character Set" and another "Use Multi-Byte Character Set".

It is important to note that LNK2005 normally arises because of two or more projects are set differently. There are two spots worth looking:

1. General Setting
2. Code Generation Setting

Notice that there is nothing to do with linking setting, although this issue is linking problem.

More info at:
http://www.velocityreviews.com/forums/t285209-lnk2005error-in-visual-c-v-60.html
http://support.microsoft.com/kb/q148652/

valarray problem in Visual Studio

(Apr 16, 2007)

I tried to use valarray in Visual Studio and got some compile errors and warnings:
"warning C4003: not enough actual parameters for macro 'min'
warning C4003: not enough actual parameters for macro 'max'

error C2059: syntax error : ')'
c:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\include\valarray(427) : see reference to class template instantiation 'std::valarray<_ty>' being compiled

error C2334: unexpected token(s) preceding ':'; skipping apparent function body
...
"

These problem will occur only when we try to use statically linked MFC library. In http://www.codeguru.com/forum/archive/index.php/t-342787.html, Paul suggested that we need to make sure that valarray is included before afx stuff. This is because MS implements min and max macro and defines them in afx pre-compile header file. Any class that has min and max will have this problem.

However, if I switch the order, it seems that all declaration of valarray will be removed and I just got other compiler errors. It seems that the solution from Paul could not work for my situation.

After trying for a while, I finally decided to rename valarray.h to valarray_mod.h and change the function names from min and max to minimum and maximum instead.