#### Archived

This topic is now archived and is closed to further replies.

# Opening Files: very weird error.

This topic is 5630 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi! I have modified the function included in TOTWGPG to load bitmap files and today I discovered a very weird erro while I was using this function in my app. Here´s the section that´s giving me a headache: int LoadBitmapFile(BITMAP_FILE_PTR Bitmap,char *lpFileName,DDPIXELFORMAT &ddPixel) { int iFileHandle, iCounter; UCHAR *lpTempBuffer = NULL; OFSTRUCT FileData; memset(&FileData,0,sizeof(OFSTRUCT)); if(-1==(iFileHandle = OpenFile(lpFileName,&FileData,OF_READ))) { DWORD d = GetLastError(); return BMP_FAILED; } // More code. } // End LoadBitmapFile(). One function call might look like this: LoadBitmapFile(&Bitmap,"cdabc.bmp",ddPixel); The weird thing is that if I write for the name "cdab.bmp" (assuming there´s such a BMP, of course), the iFileHandle var inside LoadBitmapFile gets a proper value (different from -1). But if I pass "cdabc.bmp" (or "bitmap24.bmp", a longer name), iFileHandle gets the value -1. GetLastError() returned the error code 111 which, according to MSDN, is 111 The file name is too long. ERROR_BUFFER_OVERFLOW Does somebody have a clue of what´s going on in here? If you need more pieces of the code just ask me. Thanks in advance!!

##### Share on other sites
Try sticking with dos 8.3 format. Or write a new bmp loader.

##### Share on other sites
quote:
Original post by goldsword
Try sticking with dos 8.3 format.

The book has examples with files with more characters than 8.

quote:
Original post by goldsword
Or write a new bmp loader.

I don´t want to write another one, I´d like to know what´s going on here.

Anybody can help me? Thanks!

##### Share on other sites
It seems like every day 10 people have trouble with the code in this book. I wouldn''t trust it too much. You might want to look into CreateFile, fopen, or fstream to open the file. Maybe they''ll solve the problem.

How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

##### Share on other sites
No, I think the code is really trustable. I´m pretty sure it´s me who´s making a silly mistake. Anyway, I´ll try to make it work in another way. Is it possible that some other function in the program is causing this problem? Thanks!

##### Share on other sites
From MSDN: "The OFSTRUCT structure contains a pathname string member whose length is limited to OFS_MAXPATHNAME characters. OFS_MAXPATHNAME is currently defined to be 128. Because of this, you cannot use the OpenFile function to open a file whose path length exceeds 128 characters. The CreateFile function does not have such a path length limitation."

##### Share on other sites
quote:
Original post by dalleboy
From MSDN: "The OFSTRUCT structure contains a pathname string member whose length is limited to OFS_MAXPATHNAME characters. OFS_MAXPATHNAME is currently defined to be 128. Because of this, you cannot use the OpenFile function to open a file whose path length exceeds 128 characters. The CreateFile function does not have such a path length limitation."

I don´t think "cdabc.bmp" exceeds 128 characters. The problem must be somewhere else.

##### Share on other sites
I can't tell you why it's not working, but I can tell you to switch over to CreateFile. MSDN says OpenFile is there to support 16-bit versions of Windows, which not a lot of people use anymore

[edited by - Zipster on August 19, 2002 3:58:27 AM]

##### Share on other sites
quote:
Original post by Ignacio Liverotti
I don''t think "cdabc.bmp" exceeds 128 characters. The problem must be somewhere else.

Read my post again, MSDN said: "you cannot use the OpenFile function to open a file whose path length exceeds 128 characters". And with path I think they mean the full path to the file including the drive, subdirectories and the file itself.

##### Share on other sites
Thanks for your posts! I´ll rewrite the function using CreateFile.

dalleboy: I think my path exceeded the 128 characters, because it is c:\archivos de programa\microsoft visual studio\... a lot more. When I read your first post I tought you referred to the file´s name.

Thanks for your answers again! During my next section (I have a dialup connection) I´ll tell you if CreateFile did the trick.

##### Share on other sites
Ok, I tried to rewrite the function using the Win32 File I/O functions, but there´s a little tiny thing I don´t understand about one of them: ReadFile(). Its 4th parameter:

MSDN says:

Pointer to the number of bytes read. ReadFile sets this value to zero before doing any work or error checking. If this parameter is zero when ReadFile returns TRUE on a named pipe, the other end of the message-mode pipe called the WriteFile function with nNumberOfBytesToWrite set to zero.
Windows 95 and Windows 98: This parameter cannot be NULL.

I read the explanation many times but I´m not sure about what to pass in this parameter. Can you help me with this one? Thanks a lot!

##### Share on other sites
quote:
Original post by Martee

Do I have to use that pointer later? Is it useful?

##### Share on other sites
Well in Windows 95 & 98 you need to pass a dummy variable. Regardless of whether you use it or not, a variable must be passed on those Windows versions. It could be useful later when debugging your code however.

##### Share on other sites
You pass a reference to a DWORD and the function stores the number of actual number of bytes read into your buffer. So a check on the function working correctly might look something like this

//error handling code here.

Hope this helps fatty
Aface

##### Share on other sites
Thanks for all the replies! The functions is working fine now.