CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 4 of 4 FirstFirst 1234
Results 46 to 48 of 48
  1. #46
    Join Date
    Jan 2013
    Location
    Lausanne, Switzerland
    Posts
    35

    Re: How to call Dialog window (formed as resource) from a .DLL

    How to debug if there is no possibility to enter into function ?
    There is another detail - error message in the VS output window, that appears when .DLL is loaded for the 1st time (vsimk - the program, that calls my .DLL):
    Unhandled exception at 0x77014621 in vsimk.exe: 0xC015000F: The activation context being deactivated is not the most recently activated one.

    I found a trick that partially resolve the problem:
    put in the application InitInstance() the following instruction:
    afxAmbientActCtx = FALSE;

    Partially means, that while the .DLL is loading for the 1st time it's OK, but all posterior loadings generate errors. Only solution - close the "top" application (those, that calls vsimk (this last one calls my .DLL)).

    Regards,

    Pavel.

  2. #47
    Join Date
    Apr 1999
    Posts
    27,449

    Re: How to call Dialog window (formed as resource) from a .DLL

    Quote Originally Posted by Pavel_47 View Post
    How to debug if there is no possibility to enter into function ?
    There is another detail - error message in the VS output window, that appears when .DLL is loaded for the 1st time (vsimk - the program, that calls my .DLL):
    Unhandled exception at 0x77014621 in vsimk.exe: 0xC015000F: The activation context being deactivated is not the most recently activated one.
    All these "details" do not help.

    Seriously, I hope you realize that your problem requires us to have your code, application, and debug the application. Posting pictures here and there will not help. If we could debug an application by looking at a few pictures and a function, then we could fix any program. You know that isn't possible.
    I found a trick that partially resolve the problem:
    put in the application InitInstance() the following instruction:
    afxAmbientActCtx = FALSE;
    And let me ask you -- what is the significance of this variable being set to FALSE? What does it do to help the problem?

    If you just came up with that variable, and just set it to FALSE, then again, you have corrupted memory and all you're doing is changing the executable, thus moving the bug to another area of the program.

    Stop putting these lines of code in the program that have nothing to do with the problem, and let the program crash. Then fix the crashing program by making real changes -- changes that can be explained as to why they fix the problem.

    Regards,

    Paul McKenzie

  3. #48
    Join Date
    Apr 1999
    Posts
    27,449

    Re: How to call Dialog window (formed as resource) from a .DLL

    Take this simple wrong piece of code:
    Code:
    int main()
    {
        char x[10];
        int a = 1;
        int b = 2;
        SomeFunction();
        x[10] = 5;
        SomeFunction2();
    }
    What if you didn't know that you are overwriting memory in the "x[10] = 5" line and the program crashes? Then you start to do this:
    Code:
    int main()
    {
        char x[10];
        int a = 1;
        int b = 2;
        SomeFunction();
        bool c = false;
        x[10] = 5;
        SomeFunction2();
    }
    and now the program no longer crashes, you're happy, right? Did putting "bool c = false" fix the problem? No it didn't, even though the program may now "work".

    The problem is still there, only now it has been moved to another part of the code and has been masked with the bogus line of C++ code.

    Unless you explain why those statements your putting in your code "fix" the problem, all you're doing is what I posted above. You have a bug, and you believe by putting random C++ statements that do nothing, you're fixing the problem.

    Again,

    1) Stop putting in random C++ statements that have absolutely nothing to do with the problem,

    2) Make the program crash -- do not prevent it from crashing by putting in random lines of C++ code.

    3) Actually fix the crash by investigating why the crash occurs. Then make valid, explainable changes to your code to address the problem. Don't just say "I added "x = FALSE" and now my code works". Explain and know why you made the change, and how these changes actually fixed the problem.

    If you can't on your own do all three steps above, then you need to get someone who has access to your application and knows C++, MFC, and debugging techniques using Visual Studio.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; March 15th, 2013 at 06:48 AM.

Page 4 of 4 FirstFirst 1234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured