Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. CFile::GetFilePath() setting error

CFile::GetFilePath() setting error

Scheduled Pinned Locked Moved C / C++ / MFC
helpquestionannouncement
14 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Jamie Hale

    I've got code that calls this method on an open file. GetFilePath() returns the string as expected, but it sets the last error to 87 (Invalid parameter). It seems to only be happening in a release build with an open file on a CD (read-only). Does this make sense to anyone? J

    "I am the Lorax. I speak for the trees."

    D Offline
    D Offline
    David Crow
    wrote on last edited by
    #2

    How are you verifying this error is being set?


    Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

    J 1 Reply Last reply
    0
    • D David Crow

      How are you verifying this error is being set?


      Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

      J Offline
      J Offline
      Jamie Hale
      wrote on last edited by
      #3

      I inserted GetLastError() calls before and after the GetFilePath() call. Then I traced it. J

      "I am the Lorax. I speak for the trees."

      D 1 Reply Last reply
      0
      • J Jamie Hale

        I inserted GetLastError() calls before and after the GetFilePath() call. Then I traced it. J

        "I am the Lorax. I speak for the trees."

        D Offline
        D Offline
        David Crow
        wrote on last edited by
        #4

        Like this? int x = GetLastError(); CString str; str = file.GetFilePath(); x = GetLastError();


        Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

        J 1 Reply Last reply
        0
        • D David Crow

          Like this? int x = GetLastError(); CString str; str = file.GetFilePath(); x = GetLastError();


          Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

          J Offline
          J Offline
          Jamie Hale
          wrote on last edited by
          #5

          Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath(). J

          "I am the Lorax. I speak for the trees."

          D A 2 Replies Last reply
          0
          • J Jamie Hale

            Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath(). J

            "I am the Lorax. I speak for the trees."

            D Offline
            D Offline
            David Crow
            wrote on last edited by
            #6

            Strange, as I see no calls to SetLastError() in filest.cpp. And for GetFilePath() to return data whilst also setting the error value is odd. Usually when a functions sets an error, no useable data is returned.


            Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

            J 1 Reply Last reply
            0
            • J Jamie Hale

              Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath(). J

              "I am the Lorax. I speak for the trees."

              A Offline
              A Offline
              Alvaro Mendez
              wrote on last edited by
              #7

              Have you tried rebuilding your release version with Debug information and stepping into the MFC code to see which API is failing? Another option is to copy the CFile::GetStatus into your own code (temporarily), sprinkle that with diagnostic code, and then call it instead of GetFilePath. Regards, Alvaro


              Hey! It compiles! Ship it.

              J 1 Reply Last reply
              0
              • D David Crow

                Strange, as I see no calls to SetLastError() in filest.cpp. And for GetFilePath() to return data whilst also setting the error value is odd. Usually when a functions sets an error, no useable data is returned.


                Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

                J Offline
                J Offline
                Jamie Hale
                wrote on last edited by
                #8

                DavidCrow wrote: Strange, as I see no calls to SetLastError() in filest.cpp. Well, GetFilePath() makes several API calls. These typically return a value indicating an error has occurred and set the last error value. DavidCrow wrote: And for GetFilePath() to return data whilst also setting the error value is odd. Hence my confusion. DavidCrow wrote: Usually when a functions sets an error, no useable data is returned. There are no documented error conditions in CFile::GetFilePath(). According to MSDN it shouldn't even throw any exceptions, although the example wraps the call in a try/catch block. My code throws no exception. We only found the problem because a GetLastError() call later in the process was giving the error code when the API call legitimately didn't fail. J

                "I am the Lorax. I speak for the trees."

                D 1 Reply Last reply
                0
                • A Alvaro Mendez

                  Have you tried rebuilding your release version with Debug information and stepping into the MFC code to see which API is failing? Another option is to copy the CFile::GetStatus into your own code (temporarily), sprinkle that with diagnostic code, and then call it instead of GetFilePath. Regards, Alvaro


                  Hey! It compiles! Ship it.

                  J Offline
                  J Offline
                  Jamie Hale
                  wrote on last edited by
                  #9

                  Alvaro Mendez wrote: Another option is to copy the CFile::GetStatus into your own code (temporarily), sprinkle that with diagnostic code, and then call it instead of GetFilePath. That's probably the best way to handle it. The way not to handle it is by forcefully clearing the error after the call. Which is what I've done. :~ J

                  "I am the Lorax. I speak for the trees."

                  1 Reply Last reply
                  0
                  • J Jamie Hale

                    DavidCrow wrote: Strange, as I see no calls to SetLastError() in filest.cpp. Well, GetFilePath() makes several API calls. These typically return a value indicating an error has occurred and set the last error value. DavidCrow wrote: And for GetFilePath() to return data whilst also setting the error value is odd. Hence my confusion. DavidCrow wrote: Usually when a functions sets an error, no useable data is returned. There are no documented error conditions in CFile::GetFilePath(). According to MSDN it shouldn't even throw any exceptions, although the example wraps the call in a try/catch block. My code throws no exception. We only found the problem because a GetLastError() call later in the process was giving the error code when the API call legitimately didn't fail. J

                    "I am the Lorax. I speak for the trees."

                    D Offline
                    D Offline
                    David Crow
                    wrote on last edited by
                    #10

                    Jamie Hale wrote: ...a GetLastError() call later in the process was giving the error code... So could SetLastError() be getting called long after GetFilePath() has come and gone? For example, I've see instances of this type of code:

                    MyLoggingFunction("%d\n", SomeFunction());
                    DWORD dw = GetLastError();

                    One of two things can happen here. SomeFunction() could internally call SetLastError(0) but the above call to GetLastError() could be non-zero if MyLoggingFunction() called SetLastError(). Or, SomeFunction() could call SetLastError() with a non-zero value, but by the time MyLoggingFunction() had finished, GetLastError() is 0. Make sense?


                    Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

                    J 1 Reply Last reply
                    0
                    • D David Crow

                      Jamie Hale wrote: ...a GetLastError() call later in the process was giving the error code... So could SetLastError() be getting called long after GetFilePath() has come and gone? For example, I've see instances of this type of code:

                      MyLoggingFunction("%d\n", SomeFunction());
                      DWORD dw = GetLastError();

                      One of two things can happen here. SomeFunction() could internally call SetLastError(0) but the above call to GetLastError() could be non-zero if MyLoggingFunction() called SetLastError(). Or, SomeFunction() could call SetLastError() with a non-zero value, but by the time MyLoggingFunction() had finished, GetLastError() is 0. Make sense?


                      Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

                      J Offline
                      J Offline
                      Jamie Hale
                      wrote on last edited by
                      #11

                      Makes perfect sense. :) But I was tracing through the code in the debugger. The code looked like this...

                      DWORD dwErr = GetLastError(); // returns 0
                      CString strFilename = f.GetFilePath(); // returns a proper path
                      dwErr = GetLastError(); // returns 87

                      It boggles the mind. I have a feeling it could be because the filenames were originally very long, and to write them to a CD the filenames get truncated. The filesystem on the CD could be wackified somehow. But I'm grasping at straws here. J

                      "I am the Lorax. I speak for the trees."

                      D 1 Reply Last reply
                      0
                      • J Jamie Hale

                        Makes perfect sense. :) But I was tracing through the code in the debugger. The code looked like this...

                        DWORD dwErr = GetLastError(); // returns 0
                        CString strFilename = f.GetFilePath(); // returns a proper path
                        dwErr = GetLastError(); // returns 87

                        It boggles the mind. I have a feeling it could be because the filenames were originally very long, and to write them to a CD the filenames get truncated. The filesystem on the CD could be wackified somehow. But I'm grasping at straws here. J

                        "I am the Lorax. I speak for the trees."

                        D Offline
                        D Offline
                        David Crow
                        wrote on last edited by
                        #12

                        Try this:

                        DWORD dwErr = GetLastError();
                        char s[256];
                        lstrcpy(s, f.GetFilePath());
                        dwErr = GetLastError();
                        CString strFilename = s;
                        dwErr = GetLastError();


                        Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

                        J 1 Reply Last reply
                        0
                        • D David Crow

                          Try this:

                          DWORD dwErr = GetLastError();
                          char s[256];
                          lstrcpy(s, f.GetFilePath());
                          dwErr = GetLastError();
                          CString strFilename = s;
                          dwErr = GetLastError();


                          Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

                          J Offline
                          J Offline
                          Jamie Hale
                          wrote on last edited by
                          #13

                          ?? Implying that the SetLastError() might be called in CString::operator=()? J

                          "I am the Lorax. I speak for the trees."

                          D 1 Reply Last reply
                          0
                          • J Jamie Hale

                            ?? Implying that the SetLastError() might be called in CString::operator=()? J

                            "I am the Lorax. I speak for the trees."

                            D Offline
                            D Offline
                            David Crow
                            wrote on last edited by
                            #14

                            Yes.


                            Five birds are sitting on a fence. Three of them decide to fly off. How many are left?

                            1 Reply Last reply
                            0
                            Reply
                            • Reply as topic
                            Log in to reply
                            • Oldest to Newest
                            • Newest to Oldest
                            • Most Votes


                            • Login

                            • Don't have an account? Register

                            • Login or register to search.
                            • First post
                              Last post
                            0
                            • Categories
                            • Recent
                            • Tags
                            • Popular
                            • World
                            • Users
                            • Groups