Using CFile and then (HBITMAP)::LoadImage(..

This is what i want to do...  load a file from disk (using CFile), extract a string (path),close the file, load a bitmap using that path, and then later on load another bitmap from file with a fixed path.  For some magical reason, when i use CFile's pointer to load stuff from the file and then close it and THEN load a bitmap from disk it works fine. BUT when i try to load another bitmap right after, it doesn't work.  Perhaps it will be more clear in code chunks..

//This happens in order:
BOOL CSpritesDoc::OnOpenDocument(LPCTSTR lpszPathName)
{
     if(!CDocument::OnOpenDocument(lpszPathName))
            return FALSE;
      
     POINT* boundary;
     int sizeBoundary;
     int a;
     int sizeofFilename;
     char* buffer;

     UINT filesize;

     newfile = new CFile(lpszPathName,CFile::modeRead);
     filesize = newfile->GetLength();
     
     if (filesize == 0)
     {
         AfxMessageBox("Error!  File size is 0");
         return false;
     }
     else
     {
         newfile->SeekToBegin();

         filesize -= newfile->Read(&sizeofFilename, sizeof(int));
         
         buffer = new char[sizeofFilename];
         filesize -= newfile->Read(buffer, sizeofFilename);

         while(filesize > 0)
         {
             filesize -= newfile->Read(&sizeBoundary, sizeof(int));

             boundary = new POINT[sizeBoundary];

             for (a = 0; a < sizeBoundary; a++)
                 filesize -= newfile->Read(&(boundary[a]), sizeof(POINT));
                 
             appendPoints(boundary, sizeBoundary);
             
             //boundary [] is deleted in the container class
         }

         newfile->Close();

//TEMPORARILY hardcoded the pathname...         if(!background.loadBackground("D:\\WINNT\\Profiles\\Administrator\\Desktop\\MainProgram\\Res\\background.bmp"))
         {
              AfxMessageBox("Could not load background bitmap");
              exit(1);
         }

         delete [] buffer;

     }

      return TRUE;
}






//this function always works fine no matter what i do
//here is loadBackground(..
BOOL Background::loadBackground(char* path)
{
       HBITMAP hBitmap = (HBITMAP) ::LoadImage (NULL, path,
                  IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION);

       if (hBitmap == NULL)
       {
           CString string;
           string.Format(_T ("%s does not contain a DIB"), path);
           AfxMessageBox( string );

           return FALSE;
       }

       bmBackground.Attach (hBitmap); //attach this bitmap to the array

       return TRUE;
}





//BUT this is where the problem arises..
/////////////////and shortly after, i call this:
BOOL Turret::loadTurret()
{
     
       CString path = ".\\TURRET01\\turret.bmp";

       HBITMAP hBitmap = (HBITMAP) ::LoadImage (NULL, path,
                  IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION);

       if (hBitmap == NULL)
       {
           CString string;
           string.Format(_T ("%s does not contain a DIB"), path);
           AfxMessageBox( string );
           
           return FALSE;
       }

       bmTurret[numTurrets].Attach (hBitmap); //attach this bitmap to the array

       return TRUE;
}




NOW, the problem is that in loadTurret, the hBitmap = NULL!
I know this  because that messageBox in that "if" is displayed
BUT, if i don't select OpenDocument from the menu, CFile is not used
and everything works fine! When i do a test run without calling openDocument, i hardcoded the loading of the backgrounds image in the constructor so that is how the background image is loaded without calling OpenDocument. I have no idea why this doesn't work.. it boggles my mind.


PLEASE HELP!!!!!!!!!!!
ChainsAsked:
Who is Participating?
 
mikeblasConnect With a Mentor Commented:
Is it really that hard to understand?

Check out the implementation of Turret::loadTurret():

BOOL Turret::loadTurret()
{
   CString path = ".\\TURRET01\\turret.bmp";

   HBITMAP hBitmap = (HBITMAP) ::LoadImage (NULL, path,
      IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION);

   if (hBitmap == NULL)
   {
      CString string;
      string.Format(_T ("%s does not contain a DIB"), path);
      AfxMessageBox( string );
           
      return FALSE;
   }

   bmTurret[numTurrets].Attach (hBitmap); //attach this bitmap to the array

   return TRUE;
}

The CString declaration you quoted accepts that static string, which is already a part of the executable image. It measures its length, then allocates that much memory. Then copies the static string to the newly allocated memory area.

That's an expensive operation. Sometimes, that expense is worthwhile for ease of manipulation of the string.  But, in this code, _nothing_ is being done with the string.  It would be far more efficient to code the routine like this:


BOOL Turret::loadTurret()
{
   static LPCTSTR path = _T(".\\TURRET01\\turret.bmp");

   HBITMAP hBitmap = (HBITMAP) ::LoadImage (NULL, path,
      IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION);

   if (hBitmap == NULL)
   {
      CString string;
      string.Format(_T("%s does not contain a DIB"), path);
      AfxMessageBox( string );
           
      return FALSE;
   }

   bmTurret[numTurrets].Attach (hBitmap); //attach this bitmap to the array

   return TRUE;
}


Make sense now? I thought the original code was yours (that is, I thought it was your question), but you posted the same CString declaration.  

..B ekiM
0
 
mnewton022700Commented:
This is a stab in the dark. Try writing the full path name instead of
".\\TURRET01\\turret.bmp".

The previous call to LoadImage may have changed the current directory.
0
 
GlennDeanCommented:
Hi Chains:
   I'm sure that was a typo in loadTurret, but just in case it wasn't, that should be

CString path= "..\\TURRET01\\turret.bmp";

i.e. 2 dots not 1 dot.

  Glenn    
0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

 
mikeblasCommented:
mnewton> The previous call to LoadImage may have changed the current directory.

No.  LoadImage() does not change the current working directory.

However, using a relative path in this code is wrong. There's nothing that establishes the path. As such, you've got no idea which directory is being examined for the file.

Why don't you temporarily add a call to GetCurrentDirectory() to see what the CWD really is?  That'll at least educate you about why what you're doing is wrong.

If the CWD really is correct, then you need to examine the *.BMP file--it's probably corrupt. Or start looking at other causes. Even if the CWD is correct, you need to _assure_ it will be correct when this code runs.

It's not going to solve the problem, but I can't let it go without being said: GlennDean's use of CString is very inefficient. There's absolutely _no_ reason to use a CString for the path in Turret::loadTurret().

..B ekiM
0
 
GlennDeanCommented:
Where do you see me using CString?  I was modifying Chains code and simply noting that he has 1 DOT versus 2 DOTs, and one uses 2 DOTs to go from the CWD to the next lower directory.
      Glenn
0
 
mikeblasCommented:
Oops; it's Chains code. You used CString, too, though.  In exactly the same way.

 > where do you see me using CString?

You posted one line of code.  That one line used CString.  It shouldn't be hard to find.

..B ekim
0
 
GlennDeanCommented:
Whatever!
0
 
GlennDeanCommented:
Do not school me on freshmen MFC!  Granted I posted the CString but if you had read the entire question posted it should have been completely obvious I was copying his code.
   Make sense now?

   Glenn
0
 
mikeblasCommented:
> Make sense now?

Nope. I have read the whole question. And you perpetuated the same problem.

In the meantime, Chains is still looking for an answer.

..B ekiM
0
 
GlennDeanCommented:
Give it a rest Mike.  
0
 
mikeblasCommented:
> Give it a rest Mike.  

I really don't know what your problem is, GlennDean.

..B ekiM
0
 
GlennDeanCommented:
It appears you're the one with the problem Mike.  You're the one who didn't read the whole question and started falsely accusing me of very inefficient code.  You're the one who's niggling.  And just to show you how you're being, there is no word perpetuated in the English language!  
   If you would like to continue this trivial discussion in a more appropriate forum like the lounge, please open a question there and we can continue.  BUT I will not respond any longer here.  
   Glenn
0
 
ChainsAuthor Commented:
heh! you guys are fighting over my code! hehehhe

I know it must look like trash to you guys..

But by putting in the whole pathname, it works great!!  I guess CFile changes the dir for some reason. But then again, the background was loaded fine right after the use of CFile.

Who knows. It works.. THANKS GUYS!!!!!!! =)
0
 
mnewton022700Commented:
If my comment answered your question, as it appears to have done, you should have rejected Mike's comment and accepted mine.

On the Glenn vs Mike argument I would have to side with Glenn, although perpetuated is definitely a word.
0
 
mikeblasCommented:
GlennDean> You're the one who didn't read the whole question and
 GlennDean> started falsely accusing me of very inefficient code.  

I read the whole question. I attributed the code to you by a simple mistake--which I admitted immediately after you pointed it out. I'm sorry that's offended you so.

Like it or not, the use of CString is gratuitous in that function. I explained why for the benefit of mnewton. I'm sorry you're so cheesed-off, but I don't know why you've taken such great exception to it.

 mnewton> I guess CFile changes the dir for some reason. But then again,
 mnewton> the background was loaded fine right after the use of CFile.

CFile does not change the current working directory.

..B ekiM
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.