settings for VS 2005 debug vs. command line  
Author Message
Mr S





PostPosted: Visual C++ General, settings for VS 2005 debug vs. command line Top

Hi,

I'm working on a C++ application in Visual Studio 2005 under Windows 2000. When I run the app from within VS in debug or release mode everything is fine, but when I try to run the executable from the VS command prompt I get a null-pointer error.

What is the difference between these two modes of execution Could there be paths to certain dll-files which are unavailable outside of VS Any other relevant environment variables The app uses two 3D models which are opened at run-time. I tried putting these files in the same catalogue as the executable, but that didn't do anything.



Visual C++9  
 
 
cgraus





PostPosted: Visual C++ General, settings for VS 2005 debug vs. command line Top

Gosh - why did you ask in the VB forum then

If you're not explicitly working out the folder you load files from, the running directory can be different depending on how you run it.

I'll move this to a C++ forum. :-)



 
 
Viorel.





PostPosted: Visual C++ General, settings for VS 2005 debug vs. command line Top

One of difference between starting an executable from Windows and from Visual Studio is the working directory.

 

By default, the working (current) directory of executable started from Visual Studio is the directory containing the project file, i.e. your source files.

 

When you start the program manually, from Debug or Release output directories, the working directory is different, therefore if you are using relative paths in your application, the files will not be found.

 

As a check, you can try to start your application in different manner. Go to your project directory and start your application manually using a relative path like "Debug\MyApplication.exe" or "Release\MyApplication.exe". If it works, then the problem is in relative paths used in your program.

 

In addition, you can put some messages in your application, like printf("Opening file...\n"); in order to see where the program stops.