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

Hello,

Is there some document, that describe the sequence of actions, that result in displaying of a Dialog Window from a .DLL.
One important detail - the Dialog Window is created via resource/toolbox inteface.

Below is code from some example (which works), that displays simple window (with client area inside it).
In this code the window class is ctreated inside of application class.
Here is extract from application class:

Code:

---

class CMyWindow : public CFrameWnd
{
        CStatic* cs;
public:
        CMyWindow();
};

CMyWindow::CMyWindow()
{
        Create(NULL, L"MyWindow", WS_VISIBLE, CRect(0,0,200,200));
        cs = new CStatic();
        cs->Create(L"AAAAA", WS_CHILD|WS_VISIBLE|SS_CENTER, CRect(50, 80, 150, 150), this);
}

BOOL Cvpi_MFC_regularApp::InitInstance()
{
        CWinApp::InitInstance();
        m_pMainWnd = new CMyWindow();
        m_pMainWnd->ShowWindow(SW_SHOW);
        m_pMainWnd->UpdateWindow();
        return TRUE;
}

---

Below is extract from new .DLL application class, which doesn't work (resource IDD_FORMVIEW, associated with class CPixie3_DLG in't displayed).
It's shorter, than previous one, as CPixie3_DLG class is already created.

Code:

---

BOOL CPixie3_GUIApp::InitInstance()
{
        CWinApp::InitInstance();
        m_pMainWnd = new CPixie3_DLG();
        m_pMainWnd->ShowWindow(SW_SHOW);
        m_pMainWnd->UpdateWindow();
        return TRUE;
}

---

Where is my mistake ?

Thanks in advance.

Pavel.

Debug your code, step in the CPixie3_DLG() ctor and see what and where goes wrong.

Besides, it is not clear from your description what exactly did you place into the DLL: dialog resource? some class implementations (which classes)?
And how do you use this dll: using LoadLibrary or somehow else?

Hello Victor,

Thanks for response. I don't beleave, that it would be possible to debug, because .DLL is called from external CAD tool.
The .DLL must provide GUI to external tool.
In its most basic realisation I want .DLL show simple Dialog window IDD_FORMVIEW built in resource editor.
After buiding of the resource IDD_FORMVIEW I associated it with the class CPixie3_DLG (class CPixie3_DLG : public CFormView).

In MFC application (.exe, not .DLL) the dialog resource is attached to window inside of doc template like this:

Code:

---

        CSingleDocTemplate* pDocTemplate;
        pDocTemplate = new CSingleDocTemplate(
                IDR_MAINFRAME,
                RUNTIME_CLASS(CMFC_App1Doc),
                RUNTIME_CLASS(CMainFrame),      // main SDI frame window
                RUNTIME_CLASS(CMFC_App1View));
        if (!pDocTemplate)
                return FALSE;
        AddDocTemplate(pDocTemplate);

---

Should I adapt the same approach for my .DLL application - i.e. create and initialize CSingleDocTemplate object, or there is more simple method.
After all I don't need Doc class neither View ...

Regards,

Pavel.

As I told already for simple window it works fine: inside of window constructor I call function Create:

Code:

---

Create(NULL, L"MyWindow", WS_VISIBLE, CRect(0,0,200,200));

---

Should I do something inside of class constructor (class, that is associated with resource IDD_FORMVIEW).
For the moment this constructor is empty.
Here is class declaration:

Code:

---

#pragma once

// CPixie3_DLG form view

class CPixie3_DLG : public CFormView
{
        DECLARE_DYNCREATE(CPixie3_DLG)

public:
        CPixie3_DLG();          // protected constructor used by dynamic creation
        virtual ~CPixie3_DLG();

public:
        enum { IDD = IDD_FORMVIEW };
#ifdef _DEBUG
        virtual void AssertValid() const;
#ifndef _WIN32_WCE
        virtual void Dump(CDumpContext& dc) const;
#endif
#endif

protected:
        virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support

        DECLARE_MESSAGE_MAP()
};

---

and here is implementation:

Code:

---

// Pixie3_DLG.cpp : implementation file
//

#include "stdafx.h"
#include "Pixie3_GUI.h"
#include "Pixie3_DLG.h"


// CPixie3_DLG

IMPLEMENT_DYNCREATE(CPixie3_DLG, CFormView)

CPixie3_DLG::CPixie3_DLG()
        : CFormView(CPixie3_DLG::IDD)
{

}

CPixie3_DLG::~CPixie3_DLG()
{
}

void CPixie3_DLG::DoDataExchange(CDataExchange* pDX)
{
        CFormView::DoDataExchange(pDX);
}

BEGIN_MESSAGE_MAP(CPixie3_DLG, CFormView)
END_MESSAGE_MAP()


// CPixie3_DLG diagnostics

#ifdef _DEBUG
void CPixie3_DLG::AssertValid() const
{
        CFormView::AssertValid();
}

#ifndef _WIN32_WCE
void CPixie3_DLG::Dump(CDumpContext& dc) const
{
        CFormView::Dump(dc);
}
#endif
#endif //_DEBUG


// CPixie3_DLG message handlers

---

Thanks in advance

Pavel.

Quote:

---

Originally Posted by Pavel_47

I don't beleave, that it would be possible to debug, because .DLL is called from external CAD tool.

---

You'd better believe that. Or, which is even better, read some good book on debugging in Windows. :) This DLL debug is kinda trivial: you Attach To Process of your "external CAD tool" and set a breakpoint in your DLL sources wherever you need that. When your DLL code gets executed, the breakpoint is hit.

Quote:

---

Should I adapt the same approach for my .DLL application - i.e. create and initialize CSingleDocTemplate object, or there is more simple method.

---

You have to decide what your goal is, SDI+CFormView or just a dialog, plain and simple. If you decide to go with SDI, you should adopt the CSingleDocTemplate approach you mentioned. Otherwise the code is going to be different. But this is your decision as well as your design and your requirements that we have no idea about. And again, you'd better get some good reading on MFC programming to understand approaches, differences and implications.

What books do you recommend for debugging in Windows and MFC programming? I would value your opinion.

John Robbins, Debugging Applications
Jeff Prosise, Programming Windows with MFC

Additional reading:
Shepherd, Wingo, Programming Microsoft Visual C++
Mickey Williams, Programming Microsoft Windows 2000 Unleashed
White, Olafsen, Scribner, MFC Programming with Visual C++6 Unleashed

Quote:

---

Originally Posted by Igor Vartanov

You have to decide what your goal is, SDI+CFormView or just a dialog, plain and simple. If you decide to go with SDI, you should adopt the CSingleDocTemplate approach you mentioned. Otherwise the code is going to be different. But this is your decision as well as your design and your requirements that we have no idea about. And again, you'd better get some good reading on MFC programming to understand approaches, differences and implications.

---

Hello Igor,

Thank you for response. Unfortunately I have no time to follow your advise and study in depth MFC programming, as the CAD interface isn't the main part in project, there is a lot of work outside of C++ programming. I've already studied "Beginning Visual C++® 2010", Ivor Horton. I don't know if it's good book or not but there I didn't find answer to my problem. Can you, please, advise me the simplest way to show some dialog window (created with resource editor and toolbox). I know already how to do it when window is created without resource editor ... But my GUI can be quite complicated and I would like to build it resource editor rather than create all controls writing the code.

Best Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

Below is extract from new .DLL application class, which doesn't work (resource IDD_FORMVIEW, associated with class CPixie3_DLG in't displayed).
It's shorter, than previous one, as CPixie3_DLG class is already created.

Code:

---

BOOL CPixie3_GUIApp::InitInstance()
{
        CWinApp::InitInstance();
        m_pMainWnd = new CPixie3_DLG();
        m_pMainWnd->ShowWindow(SW_SHOW);
        m_pMainWnd->UpdateWindow();
        return TRUE;
}

---

Where is my mistake ?

---

Well, except the fact that you go with technology you are not familiar with... These are two typical snippets for dialogs:
1.

Code:

---

BOOL CPixie3_GUIApp::InitInstance()
{
        CWinApp::InitInstance();
        CPixie3_DLG * pDlg = new CPixie3_DLG();
        m_pMainWnd = pDlg;
        pDlg->Create(IDD_FORMVIEW);
        pDlg->ShowWindow(SW_SHOW);
        pDlg->UpdateWindow();
        return TRUE;
}

---

The code implies the dialog class is adapted to be destroyed explicitly by calling DestroyWindow(), but not CDialog::OnCancel() or CDialog::OnOK(). And C++ object is deleted explicitly in PostNcDestroy() handler.

2.

Code:

---

BOOL CPixie3_GUIApp::InitInstance()
{
        CWinApp::InitInstance();
        CPixie3_DLG dlg;
        dlg.DoModal();
        return FALSE;
}

---

The code implies the dialog is destroyed by OnOK or OnCancel, and C++ object is destroyed automatically on leaving InitInstance scope..

BTW, creating window in C++ constructor is a bad style in MFC.

Quote:

---

Originally Posted by Igor Vartanov

BTW, creating window in C++ constructor is a bad style in MFC.

---

thanks Igor. I adapted 1st solution. Now it's much better, but still not perfect.
When I load my project, the dialog window doesn't appear (from VSIM27 to VSIM29 on the picture).
It appears only when I restart already loaded project (from VSIM29 to VSIM30). It was not the case when I excersized with simple window (not resource-based).
Moreover CAD tool becames instable ... after about 2 min its window dissappeared.
Probably it's due to destroy issues, that I didn't yet implement.

I'll try to advance in this way. I appologize in advance for stupid questions:
1. Shoud I call DestroyWindow() in the Dialog class destructor?
2.

Quote:

---

And C++ object is deleted explicitly in PostNcDestroy() handler

---

Could you, please develop a little bit more this issue. Unfortunately I'm not aware of PostNcDestroy().

Thank you in advance,

Pavel.
Attachment 30853

Quote:

---

Originally Posted by Pavel_47

1. Shoud I call DestroyWindow() in the Dialog class destructor?

---

No. In OnClose() handler I believe. Of course you add ON_WM_CLOSE() to message map and send WM_CLOSE on OK or Cancel.

Quote:

---

2. Could you, please develop a little bit more this issue. Unfortunately I'm not aware of PostNcDestroy().

---

You just add to your dialog class this virtual member function:

Code:

---

void PostNcDestroy()
{
    delete this;
}

---

MSDN provides lots of simple sample projects. ;)

Quote:

---

Originally Posted by Igor Vartanov

No. In OnClose() handler I believe. Of course you add ON_WM_CLOSE() to message map and send WM_CLOSE on OK or Cancel.

You just add to your dialog class this virtual member function:

Code:

---

void PostNcDestroy()
{
    delete this;
}

---

MSDN provides lots of simple sample projects. ;)

---

I tried your proposition as I understood it. Unfortunately nothing changed.
Here is declaration of Dialog Class:

Code:

---

#pragma once

// CPixie3_DLG1 dialog

class CPixie3_DLG1 : public CDialog
{
        DECLARE_DYNAMIC(CPixie3_DLG1)

public:
        CPixie3_DLG1(CWnd* pParent = NULL);  // standard constructor
        virtual ~CPixie3_DLG1();

// Dialog Data
        enum { IDD = IDD_DIALOG };

protected:
        virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support
        void PostNcDestroy()
        {
                delete this;
        }

        DECLARE_MESSAGE_MAP()
public:
        afx_msg void OnClose();
        afx_msg void OnBnClickedOk();
};

---

and here is its implementation:

Code:

---

// Pixie3_DLG1.cpp : implementation file
//

#include "stdafx.h"
#include "Pixie3_GUI.h"
#include "Pixie3_DLG1.h"
#include "afxdialogex.h"
#include "vpi_user.h"

// CPixie3_DLG1 dialog

IMPLEMENT_DYNAMIC(CPixie3_DLG1, CDialog)

CPixie3_DLG1::CPixie3_DLG1(CWnd* pParent /*=NULL*/)
        : CDialog(CPixie3_DLG1::IDD, pParent)
{
        vpi_printf("Inside of CPixie3_DLG1 consructor\n");
}

CPixie3_DLG1::~CPixie3_DLG1()
{
}

void CPixie3_DLG1::DoDataExchange(CDataExchange* pDX)
{
        CDialog::DoDataExchange(pDX);
}


BEGIN_MESSAGE_MAP(CPixie3_DLG1, CDialog)
        ON_WM_CLOSE()
        ON_BN_CLICKED(IDOK, &CPixie3_DLG1::OnBnClickedOk)
END_MESSAGE_MAP()


// CPixie3_DLG1 message handlers


void CPixie3_DLG1::OnClose()
{
        // TODO: Add your message handler code here and/or call default

        CDialog::OnClose();
}


void CPixie3_DLG1::OnBnClickedOk()
{
        OnClose();
        CDialog::OnOK();
}

---

I also tried the second option:

Code:

---

vpi_printf("Initialization starts ...\n");
CWinApp::InitInstance();
CPixie3_DLG1 dlg;
dlg.DoModal();
vpi_printf("Initialization finishes ...\n");
return FALSE;

---

Unfortunately it doesn't work at all. I think DoModal function cannot be used in my case, where there is no parent window.
Here is CAD tool output window (with vpi_printf function messages):
Attachment 30855

As you can constate, the dialog constructor didn't accomplish his job (message "Initialization finishes ...\n" didn't appear.

Best Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

...
As you can constate, the dialog constructor didn't accomplish his job (message "Initialization finishes ...\n" didn't appear.

---

Pavel, the dialog constructor did accomplish his job.
Perhaps DoModal() had some problems... What did it return?

Quote:

---

Originally Posted by VictorN

Pavel, the dialog constructor did accomplish his job.
Perhaps DoModal() had some problems... What did it return?

---

Of course, I've been mistaken ... Surely it's DoModal(), that causes problem. As I noted before, probably it cannot be used in my case ... So, the 1st solution, proposed by Igor (using Create function) probably is the only one. The "restart run" issue must be resolved for correct functionnality.

Regards,

Pavel.

Quote:

---

Originally Posted by VictorN

Pavel, the dialog constructor did accomplish his job.
Perhaps DoModal() had some problems... What did it return?

---

Of course, I've been mistaken ... Surely it's DoModal(), that causes problem. As I noted before, probably it cannot be used in my case ... So, the 1st solution, proposed by Igor (using Create function) probably is the only one. The "restart run" issue must be resolved for correct functionnality.

Concerning return value, I can't get it, because the control isn't returned from it because the next message isn't displayed. Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

Of course, I've been mistaken ... Surely it's DoModal(), that causes problem. As I noted before, probably it cannot be used in my case ...

---

Why "it cannot be used"?
What does DoModal() return? What is the value of GetLastError() in this case?

Sorry Viktor,

I sent answer before completing it properly. Here is missed message from previous answer:
Concerning return value, I can't get it, because the control isn't returned from DoModal because the next message isn't displayed. Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

So, I think, the GetLastError function can't be useful here. Or I missed something ?

Quote:

---

Originally Posted by Pavel_47

Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

---

No, it isn't the only solution.

The bottom line is this -- you are using Visual Studio. By using Visual Studio, you can attach to any running process and see why it's hanging by using the "Break All" menu option. There is no need for you to use Task Manager to kill the process. Doing things like killing a process because you don't know what else to do shouldn't be an option if you have Visual Studio and you're debugging an application.

Second, are you single-stepping through the program using the debugger? Why can't you debug into DoModal() to see what is going on? If something doesn't return, just go to the Debug main menu and choose "Break All".

Quote:

---

Here is CAD tool output window (with vpi_printf function messages):

---

Use the debugger -- forget about the console output.

Looking at console output from a CAD tool isn't going to get you very far -- you need to know how to debug a DLL and step into the code using the debugger (as Igor already mentioned). Are you debugging your DLL? If not, please spend the time to set this up correctly -- the time spent to learn how to debug a DLL is far much better than waiting for a response from CodeGuru.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Pavel_47

Of course, I've been mistaken ... Surely it's DoModal(), that causes problem. As I noted before, probably it cannot be used in my case ... So, the 1st solution, proposed by Igor (using Create function) probably is the only one. The "restart run" issue must be resolved for correct functionnality.

---

The word "probably" must be eliminated from engineer's vocabulary. To accomplish your job you have to understand your solution. You have to find out why "restart run" works, but first run does not. You have to try different type clients for your DLL. Finally, it's just a DLL that can be loaded to any client, not CAD only. Try to make it working in the simplest environment, and only then move to real situation. Man, there are lots of things that you can do except asking on forums.

Quote:

---

Concerning return value, I can't get it, because the control isn't returned from it because the next message isn't displayed. Moreover, the CAD tool nomore controlled - only solution - go the task manager and close it there.

---

The highlighted part makes me sure you don't understand very basic things about DoModal. Seems you cannot go forward without getting the most basic knowledge about how MFC works.

You know, I met this kind of situation several times before. People say they have no time to learn the backgrounds, just because the technology they are to use is not their primal whatever, and they have a lot of things to do in their main task/job, and one thing they just want is to do a little (or not so little) thing in an exotic environment along with weird requirements that anybody else on this forum couldn't ever met in their lives.

The combination of exotic environment, weird requirements, knowing nothing about technology in use and not willing to learn the technology they consider be something secondary and hardly necessary in future - this all has no chance to be anything else but a real danger for the whole project. People just don't understand what they do, why what they do behaves like it does, and how to diagnose and where to look at. Dead end. You're not prepared for this task. Try to go with some other technology you're really good at. Or put aside your assignment and get to learning the basics.

Dear Paul,

I've followed your advise and tried to debug with WS. Here below is situation after "Break All". What useful information can I extract from this ? As I've already mentionned, this GUI interface is important, but not principal part of the project. I have merely no time to become guru in MFC development, study in depth dbug techniques, etc. I would like to terminate this phase as soon as possible - other part, essential one is waiting for me. Thank you for your comprehension.

Attachment 30857

So I dare to reformulate the problem hoping that there is more simple solution.
Here is the project that is work properly - at least as I want.
Application Class declaration

Code:

---

// vpi_MFC_regular.h : main header file for the vpi_MFC_regular DLL
//

#pragma once

#ifndef __AFXWIN_H__
        #error "include 'stdafx.h' before including this file for PCH"
#endif

#include "resource.h"                // main symbols


// Cvpi_MFC_regularApp
// See vpi_MFC_regular.cpp for the implementation of this class
//

class Cvpi_MFC_regularApp : public CWinApp
{
public:
        Cvpi_MFC_regularApp();

// Overrides
public:
        virtual BOOL InitInstance();

        DECLARE_MESSAGE_MAP()
};

---

Application class implementation:

Code:

---

#include "stdafx.h"
#include "vpi_MFC_regular.h"
#include "vpi_user.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

// Cvpi_MFC_regularApp

BEGIN_MESSAGE_MAP(Cvpi_MFC_regularApp, CWinApp)
END_MESSAGE_MAP()

// Cvpi_MFC_regularApp construction

Cvpi_MFC_regularApp::Cvpi_MFC_regularApp()
{
        vpi_printf("Inside of Application Constructor\n");
}


// The one and only Cvpi_MFC_regularApp object

Cvpi_MFC_regularApp theApp;

class CMyWindow : public CFrameWnd
{
        CStatic* cs;
public:
        CMyWindow();
};

CMyWindow::CMyWindow()
{
        Create(NULL, L"MyWindow", WS_VISIBLE, CRect(0,0,200,200));
        cs = new CStatic();
        cs->Create(L"AAAAAAAAAAAAAA", WS_CHILD|WS_VISIBLE|SS_CENTER, CRect(50, 80, 150, 150), this);
        vpi_printf("Inside of Window Constructor\n");
}

// Cvpi_MFC_regularApp initialization
BOOL Cvpi_MFC_regularApp::InitInstance()
{
        vpi_printf("Inside of Application InitInstance\n");
        CWinApp::InitInstance();
        m_pMainWnd = new CMyWindow();
        m_pMainWnd->ShowWindow(SW_SHOW);
        m_pMainWnd->UpdateWindow();
        return TRUE;
}

---

The problem with this realization - it doesn't use resources, so all controls and theirs handler on windows must be created manually. As interface can be quite comlicated it could take considerable time. So, the question:
What should I change in this working application in order to add resource building facility ?
Sure there will be additional class. But what about application class - what changes should I do there ??

Here is the result of previous working approach:
Attachment 30859

Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

I have merely no time to become guru in MFC development, study in depth dbug techniques, etc.

---

Then you need to hire a consultant, since there is nothing "in-depth" in learning how to debug a DLL. Have you placed a breakpoint and have the breakpoint hit by the debugger? If not, then you need to go back and learn how to do this simple thing. If you can't do this simple thing, how are you going to advance from there?

You are using an environment that requires knowledge of debugging, developing, and maintaining. This isn't HTML, Perl, or some other script or script-like environment where everything is easy or with a couple of hours practice, becomes easy. You cannot get away with attempting to write a Windows/MFC C++ application with no knowledge.

As to your screenshot, how is that going to help us? First, it's too small to read. Second, unless you set a breakpoint and step through the program, showing console windows or screen shots isn't helping you or us.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Pavel_47

The problem with this realization - it doesn't use resources, so all controls and theirs handler on windows must be created manually. As interface can be quite comlicated it could take considerable time. So, the question:
What should I change in this working application in order to add resource building facility ?

---

That question alone demonstrates that you have little idea of what you're dealing with.

Creating controls dynamically and have them useful is non-trivial, even for persons experienced in MFC programming. So even if experienced persons need to do research, test, debug, etc. to accomplish this, how do you think you'll be able to accomplish this?

Regards,

Paul McKenzie

I can't use breakpoint inside my .DLL: when I attach to process, the breakpoint becomes inactive (empty circle with triangle and tooltip "The breakpoint will not currently be hit. No symbols have been loaded for this document"). I've serched for hours on the web for a solution, but without success. Probably reason (appologize in advance for employment the word "probably") - the tool executables have no accompagniing .PDB database files. With "Break all" I succeeded (not without difficulties) to have CallStack.
Here it is
Attachment 30863
Regards

Quote:

---

Originally Posted by Pavel_47

I can't use breakpoint inside my .DLL: when I attach to process, the breakpoint becomes inactive (empty circle with triangle and tooltip "The breakpoint will not currently be hit. No symbols have been loaded for this document").

---

Did you build the DLL with debugging information?

Quote:

---

I've serched for hours on the web for a solution, but without success. Probably reason (appologize in advance for employment the word "probably") - the tool executables have no accompagniing .PDB database files.

---

The PDB files exist if you build the DLL with debugging information. If you did build the DLL yourself with debugging information, then the reason most likely that you cannot debug it is that the DLL that's running is not the one you built, but some other version.

Look, it's very easy.

1) Rebuild the DLL, making sure that debugging is turned on (both compiler and linker settings).

2) Start the CAD program. Make sure that your CAD program is using that same DLL you built. If the CAD program is using some other DLL that happens to have the same name, then of course you won't be able to debug the one you just built. Using Process Explorer from sysinternals.com shows you what DLL's are loaded when the program is running.

3) Set a breakpoint in the DLL function in Visual Studio.

4) Attach to the CAD program. Then do something in the CAD program that invokes the DLL function you set a breakpoint in.

5) Done.

It can't be any easier than that.

You don't need to attach to the CAD process. The other way to debug is to start the CAD program from the DLL project itself. If you know the command to start the CAD program, then enter the name there, set a breakpoint, and start debugging.

If you want proof, don't make any changes, go to your DLL project and try to debug by hitting F5 or F10. What do you see? Don't you see Visual Studio asking for the name of the application? So what is the name of the application you're trying to debug? You don't need google or hours of searching to see this -- just by accident hitting F5 or F10 would have given you a clue on how to debug a DLL project.

Regards,

Paul McKenzie

Here it is:

Quote:

---

1) Rebuild the DLL, making sure that debugging is turned on (both compiler and linker settings).

---

For compiler it should be Ok:
Attachment 30865
For linker also:
Attachment 30867

Quote:

---

2) Start the CAD program. Make sure that your CAD program is using that same DLL you built. If the CAD program is using some other DLL that happens to have the same name, then of course you won't be able to debug the one you just built. Using Process Explorer from sysinternals.com shows you what DLL's are loaded when the program is running.

---

This is checked in point 4 (you will see). When the CAD starts some process, called "elaboration", it loads specified .DLL, that is specified in project conf. file. The name of the .DLL is displayed in the CAD console window

Quote:

---

3) Set a breakpoint in the DLL function in Visual Studio.

---

Attachment 30869

Quote:

---

4) Attach to the CAD program. Then do something in the CAD program that invokes the DLL function you set a breakpoint in.

---

Attachment 30871
Now what's hapenned with breakpoint:
Attachment 30873
Here is VS output window:

Code:

---

'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\vish.exe', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files\AVAST Software\Avast\snxhk.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\tk84.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\shlwapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\comdlg32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcr90.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\tcl84.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Windows\SysWOW64\wsock32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\ws2_32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\nsi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\winspool.drv', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\imagehlp.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\apphelp.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\reg1.1\tclreg11.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Windows\SysWOW64\uxtheme.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\dwmapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\clbcatq.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\oleaut32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\ABBYY Lingvo x5\LvHook.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\ABBYY Lingvo x5\Detoured.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\version.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\userenv.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\profapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\itcl3.2\itcl32.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\Img1.3\img1384.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\png.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\zlib.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\itk3.2\itk32.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\tkdnd\libtkdnd.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Windows\SysWOW64\nlaapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\NapiNSP.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\pnrpnsp.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\mswsock.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\dnsapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\winrnr.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\Bonjour\mdnsNSP.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\IPHLPAPI.DLL', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\winnsi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\wshbth.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\Tclxml2.6\Tclxml26.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\Tclexpat2.6\Tclexpat26.dll', Binary was not built with debug information.
'vish.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\propsys.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\ntmarta.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\Wldap32.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\WindowsCodecs.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\EhStorShell.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\Microsoft Office\Office14\GROOVEEX.DLL', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\msvcp90.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc90.atl_1fc8b3b9a1e18e3b_9.0.30729.6161_none_51cd0a7abbe4e19b\ATL90.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\Common Files\microsoft shared\OFFICE14\Cultures\OFFICE.ODF', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Program Files (x86)\Microsoft Office\Office14\1033\GrooveIntlResource.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\ntshrui.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\srvcli.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\cscapi.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\slc.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\FWPUCLNT.DLL', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\rasadhlp.dll', Cannot find or open the PDB file
'vish.exe': Loaded 'C:\Windows\SysWOW64\WSHTCPIP.DLL', Cannot find or open the PDB file
The thread 'Win32 Thread' (0xff4) has exited with code 0 (0x0).

---

Now I elaborate design (action, that provokes loading of .DLL. Here is output of the CAD console:
Sorry I exceeded the limit of uploaded images (will be in the next post)

Regards.

Pavel.

Here is CAD console output:
Attachment 30875
As you can constate from the 1st line the .DLL is taken from Debug, not from Release.
All the staff until Loading work.xxxxxxxxx - diagnostic messages from my .DLL.

Regards.

Pavel.

Quote:

---

Originally Posted by Pavel_47

With "Break all" I succeeded (not without difficulties) to have CallStack.
Here it is
Attachment 30863

---

You have to learn copying CallStack as text.

And as long as the stack shows that InitInstance is executed within DllMain, you must not use DoModal in this context, as the latter blocks thread normal execution while DllMain must never be blocked.

The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.

You have to place some code to InitInstance that will collect information about process (timestamp, .exe path and PID) and dump that to some file where you can inspect that (or console if you prefer that way). Please note that such offline debugging is the oldest debugging technique, but it still remains to be the most reliable one.

As well, you may try with DebugBreak and see if JIT debugger window shows up.

Quote:

---

Originally Posted by Pavel_47

Here it is:

---

What is the full path name of the DLL you are trying to debug? Do you see it in the list of modules that are loaded? So far I have no idea the name of the DLL that you're trying to debug, or the full path of that name. Why are you showing us names of DLL's that are not relevant?

Please show only the full path name of the DLL that you claimed you built, and that it was or was not loaded with symbols. It doesn't matter whether "vsim.exe" was built with debugging information or not. What matters is the DLL you built and whether that is being loaded with debugging information.

Moreover, this issue has nothing to do with debugging -- do you really know yourself what DLL's are being loaded by which process? Forget about Visual C++, do you know how your application really operates? Honestly, I don't think you know for sure which DLL's are being loaded and where they are being loaded from.

You should be using Process Explorer from sysinternals.com or some other application that shows you exactly what DLL's are being loaded by a process. These are basic system tools, regardless of whether you know MFC/C++ or not.

Regards,

Paul McKenzie

Thanks Igor,

Quote:

---

The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.

---

When I run CAD tool it doesn't load automatically my .DLL. The linking process is executed when in the CAD (already running) I do some particular procedure called "design elaboration" (I won't go into details what it is). Probably (sorry again) during this procedure the initial CAD tool runs some other module and "this other module" links my .DLL. But Ok, I'll try your proposition concerning InitInstance.

Quote:

---

as the latter blocks thread normal execution while DllMain must never be blocked.

---

Beside the dubugging issue, should I reject "DoModal approach" in favour of one, based on Create function ?

Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

Thanks Igor,



When I run CAD tool it doesn't load automatically my .DLL. The linking process is executed when in the CAD (already running) I do some particular procedure called "design elaboration" (I won't go into details what it is). Probably (sorry again) during this procedure the initial CAD tool runs some other module and "this other module" links my .DLL.

---

That's the problem -- do you know what module loads what DLL's? Again, please run your application, and use Process Explorer to tell you what module has loaded which DLL's.

http://technet.microsoft.com/en-us/s...rnals/bb896653

From the link above:

Quote:

---

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded.

---

You need a complete understanding of how your program works. Otherwise, you will never be able to debug it.

Regards,

Paul McKenzie

Quote:

---

The fact that breakpoint appears inactive, and loading dll does not result in breakpoint hit makes me think that you have attached to process other than the one that actually loads your DLL. It's very unlikely that your CAD somehow prevents debugger from normal working.

---

Quote:

---

That's the problem -- do you know what module loads what DLL's? Again, please run your application, and use Process Explorer to tell you what module has loaded which DLL's.

---

Igor, Paul you had reason - the process I attached to, is not that, which calls my .DLL. Please see below
Attachment 30879

There is problem - vsim, .DLL is attached to doesn't appear in the list of processes when the CAD is just running. It's called by parent process vish.exe - the one I attached to. Is there some workaround ?

Regards,

Pavel.

Here are zooms:
Attachment 30881

Attachment 30883

Quote:

---

Originally Posted by Pavel_47

Here are zooms:

---

It is impossible to read when the highlight is purple.

Place a DebugBreak in your code, as Igor already mentioned:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Then when the DebugBreak is called, you are then given the option to debug.

Or do something that delays the application vsimk.exe, so that you have time to attach to it.

Regards,

Paul McKenzie

Quote:

---

It is impossible to read when the highlight is purple.

---

Here it is:
Attachment 30885

Quote:

---

Place a DebugBreak in your code, as Igor already mentioned:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Then when the DebugBreak is called, you are then given the option to debug.

---

Here is extract of code with DebugBreak:
Attachment 30887

Unfortunately it doesn't catch control, at other side it has impact on .DLL loading. It's failed:
Attachment 30889

Regards,

Pavel.

Quote:

---

There is problem - vsim, .DLL is attached to doesn't appear in the list of processes when the CAD is just running. It's called by parent process vish.exe - the one I attached to. Is there some workaround ?

---

Attaching a debugger at startup
Debugging Process Startup

Quote:

---

Originally Posted by Igor Vartanov

Attaching a debugger at startup
Debugging Process Startup

---

Thanks. With this approach I could debug. As I've told already my primary aim became Create-based approach. Here is CallStack on the BreakPoint:
Attachment 30891

I stepped 4 function on the stack:
1. InternalDllMain
2. DllMain
3. __DllMainCRTStartup
4. _DllMainCRTStartup

During this stepping I've just controlled dwReason parameter (that was equal to 1 (means DLL_PROCESS_ATTACH, what seeems to be correct)) and also hDllHandle, which wasn't NULL. The retcode from DllMain was 1.

As I've already mentionned in one of my previous mails, the window doesn't appear. To get it diplayed I should "restart" already loaded design. During restart there is also break in the .DLL. Here is VS2010 output window content between 2 breaks:

Code:

---

vsimk.exe has triggered a breakpoint
'vsimk.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\imagehlp.dll', Cannot find or open a required DBG file.
'vsimk.exe': Loaded 'C:\Program Files (x86)\QuestaSim_SE_10b\win32\dbghelp.dll', Cannot find or open a required DBG file.
The thread 'Win32 Thread' (0x193c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xa50) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x484) has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp(4553) : {299} client block at 0x087FF758, subtype c0, 56 bytes long.
a CObject object at $087FF758, 56 bytes long
d:\proj_modelsim\pli_vpi\pixie3_vpi\pixie3_gui\pixie3_gui.cpp(68) : {289} client block at 0x087FF1E0, subtype c0, 148 bytes long.
a CPixie3_DLG1 object at $087FF1E0, 148 bytes long
Object dump complete.
'vsimk.exe': Unloaded 'D:\PROJ_ModelSim\PLI_VPI\PIXIE3_VPI\Debug\Pixie3_GUI.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\mfc100ud.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\msimg32.dll'
'vsimk.exe': Unloaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\msvcr100d.dll'
'vsimk.exe': Unloaded 'C:\Windows\SysWOW64\mfc100enu.dll'
'vsimk.exe': Loaded 'D:\PROJ_ModelSim\PLI_VPI\PIXIE3_VPI\Debug\Pixie3_GUI.dll', Symbols loaded.
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\mfc100ud.dll', Symbols loaded.
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
'vsimk.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll', Cannot find or open the PDB file
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\msimg32.dll', Cannot find or open the PDB file
'vsimk.exe': Loaded 'C:\Windows\SysWOW64\mfc100enu.dll', Binary was not built with debug information.
vsimk.exe has triggered a breakpoint

---

As you can see there is memory leak issue. After second break I didn't step through code - merely clicked on Continue. At the end the Dialog Window appeared, but after some short time (about 2...3 min) the CAD window and Debug Window crashed.

Is there some particular parameter inside mentionned functions that should be checked in order to unmask the problem ?

Regards

Pavel.

Quote:

---

Originally Posted by Pavel_47

Is there some particular parameter inside mentionned functions that should be checked in order to unmask the problem ?

---

First, no one can solve memory leaks without the entire code and running it.

Second, you should be checking the return code of those functions you're calling, instead of assuming that they work. You say the window isn't displayed, so where is your check for the return value of pDlg->Create() and other functions?

Regards,

Paul McKenzie

Here they are:
Attachment 30893

Attachment 30895

Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

As I've already mentionned in one of my previous mails, the window doesn't appear. To get it diplayed I should "restart" already loaded design.

---

And as I already mentioned before you should find out the reason why your first launch fails. Your first suspect is pDlg->Create. Please debug it through.

And do us a great favor, please stop sending us your screenshots, and get to real investigation on your side. When you find something suspicious, first try finding relevant info with Google and MSDN. Then try to ask your team. I don't believe that CG is your only source of knowledge. But if it is, please ask questions specific to your current problem(s). When you are asked to provide a code, the code should be a project, concise and compilable. It must not be your full project you are working on. Instead it must be a demo that specifically focuses on your problem. Please take this point very seriously.

I suggested you to launch your DLL in a simple C++ client to eliminate effects from CAD. Well, did you?

Quote:

---

Originally Posted by Pavel_47

Here they are:

---

As Igor mentioned, how do you know your code even works in a very simple environment? Where is your test stub executable to see if the DLL works? Where is the application that is very simple that loads your DLL and tests it? Where is your version of a "vsimk.exe" application that loads the DLL? It isn't that difficult to write one that just loads your DLL and sees what happens.

Right now, you're trying to figure out all of these extraneous processes, executables, who calls what, etc. That is not the way a programmer develops a DLL. You write a very simple application, whether it is a Win32 that calls LoadLibrary()/GetProcAddress() and calls a couple of the exported functions, or an app generated by MFC wizard and use your DLL, etc. Then you debug that application to see how your DLL works with it. All of this extra CAD stuff is totally not necessary, and only adds to the confusion.

If it does not work in a simple application, then get it to work in a simple application. Once you have it working, then you apply it to the larger, more complex application.

Regards,

Paul McKenzie

Hello,

Here (in attachment) is the project where DLL that works properly (in the solution there is also test application).
Here is its diagnostic output:

Code:

---

InitInstance starts ...
PreCreateWindow starts ...
TestDLL.exe has triggered a breakpoint
PreCreateWindow        Last error: 0
PreCreateWindow finishes !

TestDLL.exe has triggered a breakpoint
OnCreate starts ...
'TestDLL.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Cannot find or open the PDB file
Warning: Creating a pane with no CDocument.
OnCreate RecalcLayout        Last error: 0
OnCreate ShowWindow        Last error: 0
OnCreate OnInitialUpdate        Last error: 0
OnCreate SetActiveView        Last error: 0
OnCreate ResizeParentToFit        Last error: 0
OnCreate finishes !

InitInstance LoadFrame        Last error: 0
InitInstance ShowWindow        Last error: 0
InitInstance finishes ...

---

Here is test application execution result:
Attachment 31063

When I try the same code (with #define CAD_TOOL in the application class definition) with my CAD tool, the window TODO:layout doesnt appears. Here is DLL diagnostic in the CAD output window:
Attachment 31065

The error 1421 (control ID not found) occurs while executing of the m_pMainView->ShowWindow(SW_SHOW) command inside of Frame class OnCreate function.

Regards,

Pavel.

Hello,

After a lot of different attempts I'm hampered an obstacle, that apparently without issue.
The application that calls my .DLL is stopped on the following command (with some error message informing that it's just stop working, without any detail):

Code:

---

CWnd* pNewView = this->CreateView(&ccx);

---

Here is the whole code of function, where it appears:

Code:

---

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
        vpi_printf("Inside of OnCreate ...\n");
        if (CFrameWnd::OnCreate(lpCreateStruct) == -1)
                return -1;

        Sleep(20000);

        //DebugBreak();
        CCreateContext ccx;
        ccx.m_pNewViewClass = RUNTIME_CLASS(CMainView);
        vpi_printf("RUNTIME_CLASS\tLast error: %d\n", GetLastError());
        CWnd* pNewView = this->CreateView(&ccx);
        vpi_printf("pNewView\tLast error: %d\n", GetLastError());
        m_pMainView = DYNAMIC_DOWNCAST(CMainView, pNewView);
        vpi_printf("DYNAMIC_DOWNCAST\tLast error: %d\n", GetLastError());
        if(!m_pMainView)
        {
                vpi_printf("Creation of view failed !!!\n");
        }

    RecalcLayout();

    m_pMainView->ShowWindow(SW_SHOW);
    m_pMainView->OnInitialUpdate();

    SetActiveView(m_pMainView);

    m_pMainView->ResizeParentToFit(FALSE);

        return 0;
}

---

When I uncomment DebugBreak() and during pause of 20sec attach to process I can pass through the suspected code.
But the problem is - in debugging mode evrything is OK !

Does anybody can propose some work around ?

Regards,

Pavel.

Quote:

---

Originally Posted by Pavel_47

When I uncomment DebugBreak() and during pause of 20sec attach to process I can pass through the suspected code.

---

Those lines did nothing except move the problem somewhere else. Adding in a Sleep() is a sure sign that either you've corrupted memory and the Sleep() just moves the bug to another place, or you have a multithreaded program and your code causes a race condition.

All you're doing when you add and remove lines is to change the executable so that the bug is in another place. I bet if you added a few "int i = 0; ++i", the code would also magically "work".

Quote:

---

But the problem is - in debugging mode evrything is OK !

---

You have either

1) Corrupted memory or
2) Caused a race condition to occur or
3) Using uninitialized variables or
4) A combination of 1), 2) or 3).

Quote:

---

Does anybody can propose some work around ?

---

You have a function, it doesn't work. The only "workaround" is for you to debug and fix the function. Putting in Sleep() is no fix, as right now, it is no different than adding some local variables and incrementing them.

Regards,

Paul McKenzie

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.

Quote:

---

Originally Posted by Pavel_47

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.

Quote:

---

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

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