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. Pointer problems in MFC Extention DLL

Pointer problems in MFC Extention DLL

Scheduled Pinned Locked Moved C / C++ / MFC
c++visual-studiohelpquestion
6 Posts 2 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.
  • D Offline
    D Offline
    D D de Kerf
    wrote on last edited by
    #1

    I made myself a MFC Extention DLL and I seem to be having a couple of pointer problems, event though I don't know what it is exactly. Perhaps you've got an idea... The situation is as follows.... In-dll functions: CString Trim(CString sInput); CString EatString(CString * pInput1, CString sInput2); CMyOwnObject()::CMyOwnObject(CString sInput); // constructor Now, this is what happens when I call the in-dll functions from outside the dll: CString s = Trim(" my string "); // this works fine! CString s2 = EatString(&s, " "); // this gives a crash inside EatString at the point where I try to set the value of s (like this: *s = "new string"); CMyOwnObject * pNew = new CMyOwnObject("new"); // This gives a crash at the point where the constructor ends... for SOME reason it goes into the desctructor of CString (probably for "new") and there it crashes on FreeData() ) I don't want to completely rewrite all my code to BSTR's and so for the moment. Is there another way to fix this? (Trim works just fine!) Structured programming vs. chaotic mind boggling

    T 1 Reply Last reply
    0
    • D D D de Kerf

      I made myself a MFC Extention DLL and I seem to be having a couple of pointer problems, event though I don't know what it is exactly. Perhaps you've got an idea... The situation is as follows.... In-dll functions: CString Trim(CString sInput); CString EatString(CString * pInput1, CString sInput2); CMyOwnObject()::CMyOwnObject(CString sInput); // constructor Now, this is what happens when I call the in-dll functions from outside the dll: CString s = Trim(" my string "); // this works fine! CString s2 = EatString(&s, " "); // this gives a crash inside EatString at the point where I try to set the value of s (like this: *s = "new string"); CMyOwnObject * pNew = new CMyOwnObject("new"); // This gives a crash at the point where the constructor ends... for SOME reason it goes into the desctructor of CString (probably for "new") and there it crashes on FreeData() ) I don't want to completely rewrite all my code to BSTR's and so for the moment. Is there another way to fix this? (Trim works just fine!) Structured programming vs. chaotic mind boggling

      T Offline
      T Offline
      Tomasz Sowinski
      wrote on last edited by
      #2

      Are you absolutely sure that your DLL uses shared MFC? Set dll as active project, go to Project->Settings->C/C++ and check if you have _AFXDLL in the 'Preprocessor definitions'. Tomasz Sowinski -- http://www.shooltz.com.pl

      D 1 Reply Last reply
      0
      • T Tomasz Sowinski

        Are you absolutely sure that your DLL uses shared MFC? Set dll as active project, go to Project->Settings->C/C++ and check if you have _AFXDLL in the 'Preprocessor definitions'. Tomasz Sowinski -- http://www.shooltz.com.pl

        D Offline
        D Offline
        D D de Kerf
        wrote on last edited by
        #3

        Just checked it, but the _AFXDLL wasn't in there... So I put it there, but that didn't seem to have any effects on the result (even after clean rebuilding a couple of times)... I just created the project with the classwizard, selecting an extention DLL... And everything works, except this... It crashes on the destructor of the input string! I found that putting LPCTSTR in the header, instead of CString, resolves the problem, but then I have to rewrite all my headers to use LPCTSTR... And what do I do with CString * then? I can't use LPCTSTR *, right? Structured programming vs. chaotic mind boggling

        T 1 Reply Last reply
        0
        • D D D de Kerf

          Just checked it, but the _AFXDLL wasn't in there... So I put it there, but that didn't seem to have any effects on the result (even after clean rebuilding a couple of times)... I just created the project with the classwizard, selecting an extention DLL... And everything works, except this... It crashes on the destructor of the input string! I found that putting LPCTSTR in the header, instead of CString, resolves the problem, but then I have to rewrite all my headers to use LPCTSTR... And what do I do with CString * then? I can't use LPCTSTR *, right? Structured programming vs. chaotic mind boggling

          T Offline
          T Offline
          Tomasz Sowinski
          wrote on last edited by
          #4

          > Just checked it, but the _AFXDLL wasn't in there... So it wasn't the MFC Extension DLL. You should read MFC Technical Note 033 to learn more about this. The rule of the thumb is: .exe *and* .dll must 'Use MFC in shared DLL' - you set this in 'General' pane of the 'Settings' window. Tomasz Sowinski -- http://www.shooltz.com.pl

          D 1 Reply Last reply
          0
          • T Tomasz Sowinski

            > Just checked it, but the _AFXDLL wasn't in there... So it wasn't the MFC Extension DLL. You should read MFC Technical Note 033 to learn more about this. The rule of the thumb is: .exe *and* .dll must 'Use MFC in shared DLL' - you set this in 'General' pane of the 'Settings' window. Tomasz Sowinski -- http://www.shooltz.com.pl

            D Offline
            D Offline
            D D de Kerf
            wrote on last edited by
            #5

            Hmm, actually, I don't want to use 'MFC in Shared DLL', because a business policy of ours is to always use MFC in static DLL (to avoid MFC version conflicts)... BTW, it works if I put both projects in MFC as shared DLL. If I use MFC in a static DLL, then what is the correct way to handle input-ouput string characters? My function does the following: CString EatString(CString * pString, LPCSTR sInput); pString gets completely mixed up inside the function, but somehow this keeps on leading to errors. I've tried the following things: CString EatString(CString& pString, LPCSTR sInput); CString EatString(CString * pString, LPCSTR sInput); CString EatString(LPCSTR * pString, LPCSTR sInput); none of these seem to work well.... What's the standard way, anyway? Structured programming vs. chaotic mind boggling

            T 1 Reply Last reply
            0
            • D D D de Kerf

              Hmm, actually, I don't want to use 'MFC in Shared DLL', because a business policy of ours is to always use MFC in static DLL (to avoid MFC version conflicts)... BTW, it works if I put both projects in MFC as shared DLL. If I use MFC in a static DLL, then what is the correct way to handle input-ouput string characters? My function does the following: CString EatString(CString * pString, LPCSTR sInput); pString gets completely mixed up inside the function, but somehow this keeps on leading to errors. I've tried the following things: CString EatString(CString& pString, LPCSTR sInput); CString EatString(CString * pString, LPCSTR sInput); CString EatString(LPCSTR * pString, LPCSTR sInput); none of these seem to work well.... What's the standard way, anyway? Structured programming vs. chaotic mind boggling

              T Offline
              T Offline
              Tomasz Sowinski
              wrote on last edited by
              #6

              > If I use MFC in a static DLL, then what is the correct > way to handle input-ouput string characters? There's no such thing as static DLL - 'D' in DLL means dynamic. If you use static lib version of MFC, your .dll and .exe will have two different heaps. Memory allocated in .exe can't be freed in .dll and vice versa. Using CString::operator= may cause heap operations, and this is going to crash when MFC isn't shared. So the declaration for EatString should look more or less like this: int EatString(char *szOutput, int cbOutput, const char *szInput); You can return number of characters in szOutput after completing the operation. Or the error code, or whatever. Tomasz Sowinski -- http://www.shooltz.com.pl

              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