Working Directory

[none]

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.

[none]

none wrote:

> 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.

After rereading my own post, I think an obvious solution might be to use
GetCurrentDirectory() instead of GetModuleFileName(). I am not confident
that this is the correct approach, either.

[David Lowndes]

>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.

You need to decide what is the appropriate relationship between the
executables and these resource bitmaps in your redistributed
application - and then get your development arrangement to fall in
line with that.

If the bitmaps are always needed and you don't allow users to alter
them, stick them into the exe/dll as resources.

Dave