Hi,
Seems like this is probably a FAQ but I searched and found nothing. I
have a solution (VS2005) that contains lots of projects. Some of the
projects create DLLs, some of them create EXEs. All of their output is
set to:
$(SolutionDir)$(ConfigurationName)
Which is typically something like
C:\projects\VC\myproject\Debug
So I end up with a lot of EXE and DLL files in that directory. When the
application needs to load a DLL, it succeeds because Windows has certain
rules for finding a DLL and one of the rules is to look in the same
directory as the program's EXE file (regardless of the current working
directory).
Now, I also have a lot of other files, like bitmaps. These are located
in the directory above the EXE, so, for example:
C:\projects\VC\myproject
When I need to load them, I just use the current working directory. By
default, Visual Studio sets this to exactly the path shown above, so
everything is loaded correctly.
The problem is that if I allow the user to change the current working
directory (for example, via a "File Open" dialog), I'll need to be able
to get back to that initial working directory. My first thought was
this:
1) When the application starts up, call ::GetModuleFileName() to get the
path to the executable
2) Strip off everything after the last '\' character
3) Save that value as the path to the executable
4) When loading resources, get the path to the executable and go up one
level
5) Load the resources from there
This works correctly as long as I'm running the application from within
Visual Studio. It does not work if a user has installed the
application, because the executables, DLLs, and other resources are all
dumped into the same directory.
I could hack a fix by just having the installer put the EXE and DLL
files in a subdirectory, but it seems like there must be a more robust
way to handle this problem.
