What is different between the systems on which it runs OK and where it
gives the error besides that they are physically different computers?
What version of the run-time library is on one and the other?  Perhaps
when you know that, you can answer your own question.

V

I sure don't have enough info to provide a useful answer. Instead, I
will suggest ways to help you find the answer.

1) Liberally sprinkle your code with ASSERTs. Use them to check
whether pointers are null, array indeces are out of bounds, and
anything else that's likely to give _early_ warnings of trouble.
Definitely a _pain_ (all that extra typing, grumble, grumble). And
they do make your code less readable.

2) Check function return values and use GetLastError whenever
relevant, according to the documentation. Not just when you think you
might need help. Use ASSERTs to look for unexpected returns. Reading
the documentation well enough to know when these are relevant _does_
take extra work. For various reasons, I don't use exceptions, but they
might be appropriate here. Same objections as for ASSERTs.

3) Use lint every once in a while. This is much like _asking_ a very
fussy editor to look at your writing. Tuning lint takes time. Adding
comments to quiet lint selectively takes time and adds clutter to your
code. I use Gimpel PC Lint.

4) Use BoundsChecker or some other deep snooper. They cost a few
hundred dollars. When I turn on full debugging, my program runs slowly
enough (well, I am still using a 300 MHz CPU) that I can watch some
screens paint. I've actually taken advantage of that effect to spot
some problems.

5) Build with error level 4 at least once in a while, and take time to
tune your code to eliminate _all_ of the messages. Some will be very
scary false alarms. Some will be for code beyond your control. Use
tools (such as pragmas) to eliminate the false alarms, and maybe for
the code beyond your control (depends on its source). You will almost
certainly get some messages that address real problems you need to
solve.

6) Use multiple compilers. I've found that each compiler catches
different errors in _my_ code. This is far less likely to catch errors
than the others, so it isn't worth a lot of effort. I stumbled on this
when I was working on a program that targeted IBM mainframes, OS/2,
and Macintosh. Now that I target primarily Windows CE, but debug
primarily on NT, it is an inherent part of my work life.

I've pointed out some of the pain involved with each of these methods.
But they _will_ avoid and/or help you solve problems such as the one
you describe. They don't always pinpoint the problem, but they can
seriously narrow down the list of suspects.

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

Hi

There are possibilities to link MFC statically and dynamically, the
difference is that one uses the MFC dlls on all machines, the other builds
the MFC code into your exe -> your exe will not depend on the version of
MFC. If I were you, I would play a bit with those settings, maybe it could
solve your problem.

Jozsef

Hi, Robert, Jozsef, and Victor,

Thank you very much for your kind help. The problem was finally solved.

I traced down the software, and finally understood what happened in my
computer and other computers. The DLLs are all the same, so the run-time
libraries should not be blamed. However, I still choose to link MFC
statically as Jozsef suggested, just for double insurance. The culprit is
the write permission of the network drivers. My software will create a
subdirectory in the current driver automatically, since my computer have the
write permission to both the local drivers and network drivers, so I can run
my software virtually anywhere. To share my software with my colleagues, I
copy it to a network driver, and my colleagues ran the software directly
from the network driver, unfortunately they did not have the write
permission, and it caused the problem. If they copy the software to their
local drivers and run it there, it should work properly.

However, I think the error messages provided by MFC are very misleading.

John