🚀 go-pugleaf

Marco wrote:

> My problem is that if i try to open file on my PC sometimes
> error occours but if i copy all my folder on another PC all 
> work correctly (always).
> Could WinXP (API or somethingelse) give the problem?

>   FILE *file = fopen (".\\Cfg\\CompCod.dat", "w"); 
>   if (file == NULL)
>     {
>     ShowMessage("Error! Can't open file CompCod.dat");
>     return;
>     }

Oh dear, oh dear - I see so many programs that handle file I/O like
that. Even Borland are guilty of that kind of sloppy I/O
implementation. I/O operations usually provide a mechanism for
obtaining an error code and if they don't IMO programmers shouldn't use
them :)

In this case Borland's help seems to be a bit poor. The help for
fopen() doesn't bother to mention 'errno'. This variable will contain
an error code from whatever runtime library function last failed. You
even get a textual message for a code by using it as an index into the
'_sys_errlist' array.

Alternatively if you are coding for Windows you can just use
GetLastError() - this should probably be your first port of call when
you get any kind of I/O or API related problems. If you are using the
VCL it can be combined with SysErrorMsg() to get a system error message
for a system error code.

If you aren't using the VCL you can use FormatMessage():

// From the help

LPVOID lpMsgBuf;
 
FormatMessage( 
    FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
    NULL,
    GetLastError(),
    MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
    (LPTSTR) &lpMsgBuf,
    0,
    NULL 
);

// Display the string.
MessageBox( NULL, lpMsgBuf, "GetLastError", MB_OK|MB_ICONINFORMATION );

// Free the buffer.
LocalFree( lpMsgBuf );


Try changing your code to be:

  FILE *file = fopen (".\\Cfg\\CompCod.dat", "w"); 
  if (file == NULL)
  {
    ShowMessage("Error! Can't open file CompCod.dat:"+
                SysErrorMsg( GetLastError() ) );
    return;
  }

And see what reason is given.

One other thing that I also dissapprove of is your use of a relative
path in a call to fopen(). It's okay (essential in fact) if you have a
collection of files that all relate to each other (such as a project
group) but then the path should be relative to a central file and
should be resolved into a fully qualified path internally at the first
opportunity. Several serious faults with the BCB IDE can be attributed
to Borland programmers using relative paths and not resolving them.
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html