Multi Dialogs, wizard type application issue and non-repeatitive problem

or else it has direct link in msdn.

follow this.
http://msdn.microsoft.com/en-us/library/wddd3ztw.aspx

So CMyDialog has DoModal and then CSimpleDialog has an own DoModal. When on a button pressed in CSimpleDialog, CMyDialog calls DoModal for CNextDialog.

I hope that CMyDialog exists as a parent for all other dialogs. Without it, this sytem will work exactly as you, Develprog, explains - "sometimes" the Dlg_2 is not closing an it stays.

If it is interesting, please think about CPropertySheet:

http://www.google.com/search?hl=en&rlz=1G1GGLQ_ENIL306&q=mfc+propertysheet+sample&start=10&sa=N

There is an MFC sample (PROPDLG):

http://msdn.microsoft.com/en-us/library/et63ay6a(VS.80).aspx

http://msdn.microsoft.com/en-us/library/482ck6x8(VS.80).aspx

Or this way: http://java.functionx.com/visualc/dialogboxes/proppages.htm

//Main Dialog it never appears
BOOL IPSetupDlg::OnInitDialog()
{
       CDialog::OnInitDialog();

        EndDialog(TRUE);                                <<---------------  1
       
       CDlg_1 Dlg;
       Dlg.DoModal();

        return TRUE;  
}

point 1)
Here you destroy the dialog IPSetupDlg.  Then you wonder why a) IPSetupDlg doesn't appear and b) CDlg_1 doesn't appear.  
Is my understanding of your problem correct?  If it is then just remove the EndDialog(TRUE) line of code.

Hi pgnatyuk. yeah its true to have redesign the application. But its necessary to solve the problem we have. Instead I could have suggested making wizard application.

I think AndyAinscow has found the problem. Please check. You closed the main dialog in OnInitDialog.

If you want go this way, you need just put all dialogs on the same place: same position and same size, so they will cover each other.
You need a visible parent window for your wizard dialogs, because there is a need to restore the background when such dialog closes itself.

One more way: have one main dialog and all other to make with Create and Show as the modaless dialogs.

One more way (maybe): do not have any parent dialog. But this is also leads to the re-design. And you can see a blinking on the screen - one dialog shows up, then it closes itself and dissapears. Then another dialog shows up and so on.

@pramodbugudai: yes, you showed a solution but I'm not sure if that was asked. Probably, that was the original design of the application.
In your case the parent dialog will be always visible and will control all other dialogs. And this is a right way.
But Develprog doea not want to see the parent dialog at all.

AndyAinscow :
>>Here you destroy the dialog IPSetupDlg. Then you wonder why a) IPSetupDlg doesn't
>> appear and b) >>CDlg_1 doesn't appear.
>>Is my understanding of your problem correct?

No in fact I redesign the application so the main Dialog (IPSetupDlg) is not necessary and I don't want to display it. So why first thing i do is to launch Dlg_1 (step 1) and that is working well.

But my problem begins after between step2 and step3, at step3, sometimes, the Dialog from the step 2 is still present but Idon't want to show it.

I thought that problem is du to global variables between the 3 dialogs ( not 4 dialogs because the main dialog is no more relation with others)
I have these globale variables declared on Dlg_1.cpp:

CString gl_IPMASK_retriev="255.255.255.0";
CString gl_IPGAT_retriev="11.1.4.1";

and there are presents on Dlg_2.cpp and dlg_3.cpp  files like extern :

extern CString gl_IPMASK_retriev;
extern CString gl_IPGAT_retriev;  

 
But I think problem becomes of what pgnatyuk said :
>>I hope that CMyDialog exists as a parent for all other dialogs
No I don't do that way because in my 3 dialogs.h I have that (see code)

So how correct it  

// IPSetupDlg dialog
class IPSetupDlg : public CDialog
{
// Construction
public:
	IPSetupDlg(CWnd* pParent = NULL);	// standard constructor
...
 
}
 
 
class CDlg_1 : public CDialog
{
// Construction
public:
	
	CDlg_1(CWnd* pParent = NULL);   // standard constructor
..
}
 
class CDlg_2 : public CDialog
{
// Construction
public:
	CDlg_2(CWnd* pParent = NULL);   // standard constructor
// Dialog Data
...
}
 
class Cdlg_3 : public CDialog
{
// Construction
public:
	Cdlg_3(CWnd* pParent = NULL);   // standard constructor
 
// Dialog Data
...
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:

A technical point - what I posted was accurate based on your code, if you don't use that code then please, in future, post the code you do use.

>>But I think problem becomes of what pgnatyuk said :
I don't  think so.
You often call EndDialog before creating the next dialog.  The EndDialog does that - it destroys the dialog.  Attempting to run code after that inside the dialog is a problem waiting to bite you.

If you don't want two dialogs to be displayed then replace the EndDialog(TRUE) with ShowWindow(SW_HIDE) to hide the calling dialog.  To display it after the DoModal returns you can use ShowWindow(SW_SHOW)

eg.

void CDlg_2::OnPreview() //this button is not pushed, it is a not visible control
                                          //because  in step 3 we can't go back and there are only the next    
                                          //button to close the program
{
       // TODO: Add your control notification handler code here
       UpdateData(TRUE);
       KillTimer(3);

        ShowWindow(SW_HIDE);

        CDlg_1 Dlg1;
       Dlg1.DoModal();
       
//ShowWindow(SW_SHOW);   uncomment to redisplay CDlg_2
       return;
}

Or maybe this is what you want

void CDlg_2::OnPreview() //this button is not pushed, it is a not visible control
                                          //because  in step 3 we can't go back and there are only the next    
                                          //button to close the program
{
       // TODO: Add your control notification handler code here
       UpdateData(TRUE);
       KillTimer(3);

        ShowWindow(SW_HIDE);

        CDlg_1 Dlg1;
       Dlg1.DoModal();
       
EndDialog(TRUE);  //Now you can destroy CDlg_2 safely
       return;
}
 
 

Yes, I think AndyAinscow gives a point - to create all dialogs on the application start and just show and hide them when needed. I'd go this way.

AndyAinscow:
Ok, I explain wrongly my self, it has confusing with. The code I posted is the used one when I said No I
would say no for that : "Then you wonder why  IPSetupDlg doesn't "  only.

Ok in fact I tried several thingwhen passing from step 2 to step 3 like here (see code).

but it is true I don't think to use Endialog(TRUE) just after so I'll try it and inform you.

 

 
void Cdlg_3::OnSave() 
{
 
   // TODO: Add your control notification handler code here
   UpdateData(TRUE);
   CWaitCursor();//090928
 
..
..
..
 
	FreeLibrary(hDLLCOMBO5); 
 
	Sleep(10);
	ShowWindow(SW_HIDE); //091013
	UpdateData(FALSE); //091014
	EndDialog(TRUE); //091002 BUG 
	CDlg_2 Dlg2;
	Dlg2.DoModal();
 
    //UpdateData(FALSE); 
    return; // 
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:

Again NO.

void Cdlg_3::OnSave()
{

   // TODO: Add your control notification handler code here
  UpdateData(TRUE);
  CWaitCursor();//090928

..
..
..

        FreeLibrary(hDLLCOMBO5);
 
       Sleep(10);
       ShowWindow(SW_HIDE); //091013
       UpdateData(FALSE); //091014
       EndDialog(TRUE); //091002 BUG <<<--------------------------------
       CDlg_2 Dlg2;
       Dlg2.DoModal();

    //UpdateData(FALSE);
    return; //
}

Do not put that line BEFORE other code you want to run, it destroy the dialog.

this is what it should be

void Cdlg_3::OnSave()
{

   // TODO: Add your control notification handler code here
  UpdateData(TRUE);
  CWaitCursor();//090928

..
..
..

        FreeLibrary(hDLLCOMBO5);
 
       Sleep(10);
       ShowWindow(SW_HIDE); //091013
       UpdateData(FALSE); //091014
       CDlg_2 Dlg2;
       Dlg2.DoModal();
       EndDialog(TRUE); //091002 BUG   <<-----------------  After the code you want to run

    //UpdateData(FALSE);
    return; //
}

I don't like all the code posted so far. If you create dialog 2 in the button handler of dialog 3, you make dialog 2 a child dialog of dialog 3, what hardly makes any sense.

The best solution probably is the one where all thre dialogs were running same time and by hide and show you make only one of them the current.

But even that seems not so good a solution to me.

I would recommend to create all three dialogs  in the application class by simply making them a member.

// app.h

...
class MyApp : public CWinApp
{
public:
     enum { DLG1 = 10000, DLG2 = 20000, DLG3 = 30000 };
private:
     MyDialog1 dlg1;
     MyDialog2 dlg2;
     MyDialog3 dlg3;
     int myCurDlg;

public:
...

};

// the one and only app instance
extern MyApp theApp;  


Then in MyApp::InitInstance invoke one of them:

// app.cpp

...
// the one and only app instance
MyApp theApp;  
...

BOOL MyApp::InitInstance(...)
{
      ...
      myCurDlg = DLG1;
      while (myCurDlg != IDOK && myCurDlg != IDCANCEL )
      {
         switch(myCurDlg )
         {
         case DLG1:
             myCurDlg = dlg1.DoModal();  break;
         case DLG2:
             myCurDlg = dlg2.DoModal(); break;
         case DLG3:
             myCurDlg = dlg3.DoModal(); break;
         default: return FALSE;    
         }
      }
     
      return FALSE;
}

In all three dialogs you may have buttons and/or menu entries to switch to the others, e. g. implemented like the below

...
void MyDialog1::OnButtonClickSwitchToDialog2()
{
      EndDialog(MyApp::DLG2);
}



If doing it that way, the application was started at begin and call dlg1.DoModal what would bring up the first dialog. That is exactly the same behavior as it would be with one dialog. If the user clicks cancel or ok button the DoModal would return IDCANCEL or IDOK and the while loop was terminated (same as the whole application when returning FALSE from InitInstance). If the DoModal would return DLG2 or DLG3, the dialog 2 respectively the dialog 3 was invoked modal from the application. And so on.

AndyAinscow:
Oh just sorry again.
The code that I pasted here was there with no correction (it arrives when we will do always fast :) )
You are right I did like you wrote and it works well.

But Could you say me if a wizard application use this type of approach.  ( DoModal() , Endialog() ,ShowWindow(SW_HIDE) )
With this approach that I do there must be global variables to communicate data between all dialogs is it coreect way ?

Thank you

It could be a way.  However there is a CPropertySheet/CPropertyPage pair of classes where the sheet contains multiple pages.  The sheet has a 'wizard' mode and a 'tab' mode.  The wizard mode is the usual way of doing this task.

>>itsmeandnobodyelse:
The design you propose seems better but like I did it 's right too.

Or If I  do  like Wizard application approach I can design with sheet mode CPropertySheet/CPropertyPage too.  

>>>> If I  do  like Wizard application approach I can design with sheet mode CPropertySheet/CPropertyPage too.  

Yes, the CPropertySheet/CPropertyPage is the usual way to handle multiple dialog pages.

The min difference to the approach I described was that the dialogs were all open same time, while in my design only one dialog is open at a time. That especially means that when switching you need to store the current contens before calling EndDialog or the changes were lost. With the CPropertySheet the (changed) data in dialogs keeps available even if the user chooses another Tab. But you would actively need to call UpdateData(TRUE) for the current dialog in order to move data from screen to dialog. Also you normallly have to plausify the inputs before switching to the new dialog tab. So, the property sheet probably is more complex than to handling multiple dialogs by the application class.

>>>> but like I did it 's right too.

If you create a new dialog in the handler function of another dialog and call DoModal both dialogs are active though - because of the modal - only the second dialog allows user input. If in the second dialog you have a button to invoke a third dialog it is now three dialogs cascaded what forms a hierarchie which probably isn't wanted. Assume the second dialog would try to start the first dialog. The you either could close the second dialog what would return to the first one, start another copy of the first dialog or refuse to do the requested action. I personally don't like either choice. Another probable issue is that the data in the first dialog neither must be moved from screen to dialog class nor must be plausified. That could cause the second dialog to rely on old or unchecked data if it gets data from tthe calling dialog.
 

>>>> The min difference
The main difference

>>Or If I  do  like Wizard application approach I can design with sheet mode CPropertySheet/CPropertyPage too.  


I would recommend a PropertySheet/PropertyPage approach.  The pages are children of the sheet so accessing choices made on another page is trivial.  Everything is kept together so if you move the wizard the next dialog appears in the same place.  All will be the same size when displayed.

Oh, one other point - the PropertySheet/PropertyPage in wizard mode provides buttons for 'next' and 'back' with choices being preserved if you went back then forward again, doing it your way doesn't allow a 'back' step so easily.

Hi,

So I do by this way ID: 25587791 and it is working well.

But there is a bothering thing I see but this is not because of the design:

So When I start the application the first Dialog is Dlg_1 if I want to see the about (version) of this dialog by clicking right mouse on title window I can see 3 lines :


Move
Close        Alt+F4
---------------------
About  MyApp

but the Third line doesn't show the about dialog, it does nothing , why?  how to show this Dialog window ?

For the Dlg_3 and Dlg_2 I have only 2 lines. but the most important is the first Dialog I think for checking version of the aplication.

Thank you

Sorry I was not clear for the Dlg_3 and Dlg_2, the click mouse right up
those shows these 2 lines :

Move
Close        Alt+F4

And the "About  MyApp" doesn't appear but it no matters, the most important is to have the version on the Dlg_1.

Thank you


 

>>>> but the Third line doesn't show the about dialog, it does nothing , why?  how to show this Dialog window ?

You should have the following code in your Dlg1::OnInitDialog

      ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
      ASSERT(IDM_ABOUTBOX < 0xF000);

      CMenu* pSysMenu = GetSystemMenu(FALSE);
      if (pSysMenu != NULL)
      {
            CString strAboutMenu;
            strAboutMenu.LoadString(IDS_ABOUTBOX);
            if (!strAboutMenu.IsEmpty())
            {
                  pSysMenu->AppendMenu(MF_SEPARATOR);
                  pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
            }
      }

The above would add IDM_ABOUTBOX as 3rd menu entry.


Then class CAboutDlg should be defined in your dialog1.cpp source.

Finally you need the following handler function in dialog 1

void Dlg1::OnSysCommand(UINT nID, LPARAM lParam)
{
      if ((nID & 0xFFF0) == IDM_ABOUTBOX)
      {
            CAboutDlg dlgAbout;
            dlgAbout.DoModal();
      }
      else
      {
            CDialog::OnSysCommand(nID, lParam);
      }
}

... and

BEGIN_MESSAGE_MAP(Dlg1, CDialog)
      ON_WM_SYSCOMMAND()     // for handling the system menu
        ...

>>Then class CAboutDlg should be defined in your dialog1.cpp source.

So I have add in Dlg_1.cpp this definition too (same  one that in the MyAppDlg.cpp) , see code


Now I have this error link :

Dlg_1.obj : error LNK2005: "public: __thiscall CAboutDlg::CAboutDlg(void)" (??0CAboutDlg@@QAE@XZ) already defined in MyAppDlg.obj
./Release/MyApp.exe : fatal error LNK1169: one or more multiply defined symbols found


Thank you

class CAboutDlg : public CDialog
{
public:
	CAboutDlg();
 
// Dialog Data
	//{{AFX_DATA(CAboutDlg)
	enum { IDD = IDD_ABOUTBOX };
	//}}AFX_DATA
 
	// ClassWizard generated virtual function overrides
	//{{AFX_VIRTUAL(CAboutDlg)
	protected:
	virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support
	//}}AFX_VIRTUAL
 
// Implementation
protected:
	//{{AFX_MSG(CAboutDlg)
	//}}AFX_MSG
	DECLARE_MESSAGE_MAP()
};
 
CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
{
	//{{AFX_DATA_INIT(CAboutDlg)
	//}}AFX_DATA_INIT
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:

the constructor of CDlg_1 in cpp file is :

 
/////////////////////////////////////////////////////////////////////////////
// CDlg_1 dialog
 
CDlg_1::CDlg_1(CWnd* pParent /*=NULL*/)
	: CDialog(CDlg_1::IDD, pParent)
{
	//{{AFX_DATA_INIT(CDlg_1)
		// NOTE: the ClassWizard will add member initialization here
		
	//}}AFX_DATA_INIT
	//	m_hIcondlg1 = AfxGetApp()->LoadIcon(IDI_ICON1);
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

>>>> already defined in MyAppDlg.obj

Seems there is a further dialog which already implements CAboutDlg. If so,

   - create an aboutdlg.h and aboutdlg.cpp source file and add it to the project
   - move class definition of CAboutDlg from MyAppDlg.cpp to aboutdlg.h
   - move the implementation of  CAboutDlg from MyAppDlg.cpp to aboutdlg.cpp
   - add an #include "aboutdlg.h" whereever you need the about dlg
   - add a #pragma once to aboutdlg.h

>>>> the constructor of CDlg_1 in cpp file is :

As told the system menu was enhanced in OnInitDialog and handled in OnSysCommand. That must be done for each dialog which will show the about.

Be aware that

 #include "stdafx.h"

alwaysmust be the first statement in all .cpp.

This is getting rather away from the original question.

>>>> This is getting rather away from the original question.
Andy is right. You better close the first question and have an additional one regarding about box.

OK,
First, I 'll post another question for about.
But for this present question now I realize a strange event I don't know why but when I do switching between Dlg_1 (step1)  and dlg_3 (step2)  by simply clicking on Next and Preview buttons after the 36 th switchs the application MyApp is closing automaticly and this is well repeatitiv.

Is it bug or normal because of my design ?

Thank you
 

>>>> but when I do switching between Dlg_1 (step1)  and dlg_3 (step2)  

Are you using CPropertySheet? Or are the Next and Previous button handlers always creating a new modal dialog? If the latter there probably is a limit how often you can do that.

No I do not use CPropertySheet, I don't know about it
Yes he Next and Previous button handlers always creating a new modal dialog (in fact I don't know if it creates really NEW dialogs because I use globales extern variables)  

But if I use this code ( ID: 25589247) I think that I 'll not have this strange issue isn't it ?

Is using CPropertySheet another way doing what this code ( ID: 25589247) do ?

 

>>>> But if I use this code ( ID: 25589247) I think that I 'll not have this strange issue isn't it ? But if I use this code ( ID: 25589247) I think that I 'll not have this strange issue is

No, as each dialog would end (by calling EndDialog) before a new one was invoked.

>>>> Is using CPropertySheet another way doing what this code ( ID: 25589247) do ?

No. It is a tabbed dialog where each dialog 1, 2, and 3 are pages of some kind of parent (frame) dialog (what is a class derived from CPropertySheet). You switch between the dialogs (pages) by clicking on the tab (button). All page dialogs are open but only the active page runs some kind of modal dialog.

Andy knows better of how to create this.

The propertysheet has two modes.  If you use the wizard mode then no tabs appear, instead buttons for previous and next (and OK/cancel) are implemented for you.

Ok,

I made this code for switching from a dialog to another and it runs well :

       CDlg_2 Dlg2;
       Dlg2.DoModal();
       EndDialog(TRUE); //

Thank you for all these good informations.

Hi,

Again this problem appears  , Id'ont understand why ??

because the codeis the same as Andy said on  ID: 25587791 (see code)but unfortunatly I can see
again "Sometimes" that the Dialog_3 (step2) exist (is visible) in the same time that Dlg_2 (step3)

So this code to pass  from step2 to step3 :
       CDlg_2 Dlg2;
       Dlg2.DoModal();
       EndDialog(TRUE);

is not enough to resolve the problem or maybe my design is not stable because with this design
like I wrote you before I have already this strange caracteristics ( ID: 25604387 ) so after 36 switch between 2 dialogs, the application is closed and this is not normal too?

void Cdlg_3::OnSave() 
{
 
   // TODO: Add your control notification handler code here
  UpdateData(TRUE);
  CWaitCursor();//090928
 
..
..
..
 
        FreeLibrary(hDLLCOMBO5); 
 
       Sleep(10);
       ShowWindow(SW_HIDE); //091013
       UpdateData(FALSE); //091014
       CDlg_2 Dlg2;
       Dlg2.DoModal();
       EndDialog(TRUE); //091002 BUG   <<-----------------  After the code you want to run
 
    //UpdateData(FALSE); 
    return; // 
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:

If you want a wizard to guide you through a number of steps I'd consider a change to a property sheet/page organisation.

Or maybe if I do by this way like itsmeandnobodyelse posted (see code) because I like this design and maybe it will be more fast for adapting actual code and good design too in the same time isn't it ?

Thank you.

 recommend to create all three dialogs  in the application class by simply making them a member.
 
// app.h
 
...
class MyApp : public CWinApp
{
public:
     enum { DLG1 = 10000, DLG2 = 20000, DLG3 = 30000 };
private:
     MyDialog1 dlg1;
     MyDialog2 dlg2;
     MyDialog3 dlg3;
     int myCurDlg;
 
public:
...
 
};
 
// the one and only app instance
extern MyApp theApp;  
 
 
Then in MyApp::InitInstance invoke one of them:
 
// app.cpp
 
...
// the one and only app instance
MyApp theApp;  
...
 
BOOL MyApp::InitInstance(...)
{
      ...
      myCurDlg = DLG1;
      while (myCurDlg != IDOK && myCurDlg != IDCANCEL )
      {
         switch(myCurDlg )
         {
         case DLG1:
             myCurDlg = dlg1.DoModal();  break;
         case DLG2:
             myCurDlg = dlg2.DoModal(); break;
         case DLG3:
             myCurDlg = dlg3.DoModal(); break;
         default: return FALSE;     
         }
      }
      
      return FALSE;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:

Oh,

Problem after problem, Yes one another issue again certainly due maybe of this multidialog design that I made?
This problem is that the application is not killed and I can see on the task Manager MyApp.exe.

When I am on the last step, the step3 (or Dlg_2), if I wait that all process is finished and after that by clicking on Finish button (OnNext function), I can exit correctly (meaning that it doesn't appear in the Task manager)  the application. (See code ).

But this problem appears when on the step3 I do a close window before of all process are finished.  
(See code OnClose() )

So my Onclose() function is wrong but why ?

void CDlg_2::OnNext() //Finish Button, here ok the application is exiting correctly 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
 
	EndDialog(TRUE); //091002 BUG 
	//Cdlg_3 dlg3; //090924
	//dlg3.DoModal(); //099024
	
	//DestroyWindow();
	OnOK(); //090924
}
 
 
 
void CDlg_2::OnClose() //When closing window, here problem because the application is still present in the task manager
{
	// TODO: Add your message handler code here and/or call default
	UpdateData(TRUE);
 
	wrong_exit =true;
	m_progress2.SetPos(100);
	if(good_ipchange==false)
	{
 
			//MessageBox("Wrong exit, ip is restored."); 
			KillTimer(3);
			UINT dwRetVal=0;
			hDLLCOMBO33=::LoadLibrary("iphlpapi.dll");
 
			ULONG taille = sizeof(infos33);
			//Déclarer et initialiser un pointeur sur la variable taille
			PULONG ptaille=&taille;
			//Appel de la fonction GetAdaptersInfo()
			//DWORD retour = GetAdaptersInfo (infos, ptaille);
 
			LPFNDLLFUNCINIT GetAdaptersInfo = (LPFNDLLFUNCINIT) ::GetProcAddress(hDLLCOMBO33, "GetAdaptersInfo");
			LPFNDLLFUNCCOMBO SetAdapterIpAddress = (LPFNDLLFUNCCOMBO) ::GetProcAddress(hDLLCOMBO33, "SetAdapterIpAddress"); //SetAdapterIpAddress()
 
			UINT retour = GetAdaptersInfo (infos33, ptaille);	
 
			if (retour != ERROR_SUCCESS)
			{
				printf("%s\n\n","Aucune information trouvee");
				MessageBox("No data find from NIC card");
			//	return FALSE; temp
			}
 
			//TRACE("value of gl variable int is %d\n", gl_indtorest);
			
			RedrawWindow(); //090929 refresh dialog window 
 
			//	if ((dwRetVal = SetAdapterIpAddress(infos33[Global_index].AdapterName, 0, inet_addr(gl_IP_retriev), inet_addr("255.255.255.0"), inet_addr("11.1.4.1"))) == 0) 	
				if ((dwRetVal = SetAdapterIpAddress(infos33[Global_index].AdapterName, 0, inet_addr(gl_IP_retriev), inet_addr(gl_IPMASK_retriev), inet_addr(gl_IPGAT_retriev))) == 0) //091012
 
				{
				   MessageBox("Successfull restore ip address during wrong exit.");	
				   //MessageBox("Wrong exit, ip is restored."); 
				} 
				else 
				{
				   printf("\tSET ADDR IP failed with error: %d\n", dwRetVal);
				   MessageBox("Problem to set ip address to NIC, please be sure that other NIC has no the @: 192.0.2.1 or verify the connectivity");
 
 
				   LPVOID lpMsgBuf;
				   if (FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
													 FORMAT_MESSAGE_FROM_SYSTEM | 
													 FORMAT_MESSAGE_IGNORE_INSERTS,
													 NULL,
													 dwRetVal,
													 MAKELANGID(LANG_NEUTRAL,
																LANG_ENGLISH), //Default language LANG_ENGLISH or SUBLANG_DEFAULT
													 (LPTSTR) &lpMsgBuf,
													 0,
													 NULL ))  
				   {
			 			   printf("\tError: %s", lpMsgBuf);
						   AfxMessageBox((LPCTSTR)lpMsgBuf, MB_OK | MB_ICONINFORMATION );
							
						   LocalFree( lpMsgBuf );
					   // exit(1);
				   }
					
				}
 
			FreeLibrary(hDLLCOMBO33); ///091022 Important de liberer ici?
	}
		system( "taskkill /IM ping.exe /F" );
		remove(FILE_BAT_PING);
		remove(FILE_STDIN);
		remove(FILE_SENDCMD);
		remove(FILE_PING);
 
		//SendMessage(WM_CLOSE);
 
	EndDialog(TRUE); 
	OnOK(); //091022 pour quitter entièrement
	        // l'application à mettre et avant CDialog::OnClose()
 
 
CDialog::OnClose();
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:

OK, two options:

I do it a standard way - less code to write, less likelyhood of mistakes - :-))
I do it a non-standard way - more code to write - more chance of mistakes -

Your choice.

Ok

So you mean that using less code is by doing property sheet/page organisation  
:) I suppose ?

But I like this way  ID: 25633523 too.  

Ok,

So I decided to make by the way that itsmeandnobodyelse proposed.
Till now I maded Dialog based application. So for this new design in which I will use
3 Dialogs what can I do for the  application class? Still Using Dialog based application so meaning that it will be 4 dialogs the main dialog Dlg_main (which one will never seen) and the  Dlg_1, Dlg_2 and Dlg_3 isn't' it?  Or it will be maybe like this  (see code) to avoiding using a never seen main dialog (and which one can maybe generate the same issue I had before;  dialogs 2 and 3 that appear in the same time).

Thank you

 
class MyDialog1  : public CDialog
{
// Construction
public:
 enum { DLG2 = 20000, DLG3 = 30000 };
private:
     MyDialog2 dlg2;
     MyDialog3 dlg3;
     int myCurDlg;
 
public:
...
 
};

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

>>>> the main dialog Dlg_main (which one will never seen)

In a dialog-based MFC app there is no dlg_main which never is seen (you probably think of a frame window). Instead the dialog (where there normally is only one) is the one and only main window which was invoked modally in YourApp::InitInstance. After closing (ending) the dialog, the InitInstance would return FALSE what causes the application framework to *NOT* calling its message pump what is the 'engine' of a document-view based application model BUT to exit.

So, making the dialog2 and dialog3 members of dialog1 is not the way. You need a parent class which handles those three dialogs so that you don't build up a cascade of modal dialogs. It doesn't matter whether this parent class is the app class, a 'main' dialog class, or a property sheet class. If for example you have a 4th dialog which has nothing but 3 buttons to invoke the three other dialogs and is some kind of entry dialog to the others, you can start that dialog modal from application class and start the others in appropriate handlers of the 4th dialog. The point is that when you want to switch from dialog2 to dialog1 or dialog2 you must not do that by creating an instance of the new dialog and call DoModal but to end the current dialog and let the parent class start the next dialog.

class MyDialog_Main  : public CDialog
{
// Construction
public:
 enum { DLG1 = 10000, DLG2 = 20000, DLG3 = 30000 };
private:
     MyDialog1 dlg1;
     MyDialog2 dlg2;
     MyDialog3 dlg3;
 
public:
...
     void OnHandleButtonDialog1()
     {
        int nextdlg = dialog1.DoModal();
        handleNextDialog(nextdlg);
     }
     void OnHandleButtonDialog2()
     {
        int nextdlg = dialog2.DoModal();
        handleNextDialog(nextdlg);
     }
     void OnHandleButtonDialog3()
     {
        int nextdlg = dialog3.DoModal();
        handleNextDialog(nextdlg);
     }
     void handleNextDialog(int nextDialog)
     {
        switch(nextDlg)
        {
        case DLG1:  PostMessage(WM_USER+DLG1, 0, 0); break;
        case DLG2:  PostMessage(WM_USER+DLG2, 0, 0); break;
        case DLG3:  PostMessage(WM_USER+DLG3, 0, 0); break;
        }
     }
};
 
 
// mydialog_main.cpp
 
...
 
 
BEGIN_MESSAGE_MAP(MyDialog_Main, CDialog)
   ...
   ON_MESSAGE(WM_USER+DLG1, OnHandleLButtonDialog1)
   ON_MESSAGE(WM_USER+DLG2, OnHandleLButtonDialog2)
   ON_MESSAGE(WM_USER+DLG3, OnHandleLButtonDialog3)
END_MESSAGE_MAP
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:

Ok itsmeandnobodyelse thank you,

 I'll test it and easily because the MyAppDlg dialog (which is in my current project I have done this before and currently when program is launched this dialog is hided for displaying Dialog1 in place of).

So the MyAppDlg dialog will be the parent.

 

Hi,
When looking at ID: 25589247 I have some questions:
Is there something too to add in MyApp.h and MyApp.cpp or only on Dlg files like your last post ?
If So which global extern variable must I use in dialogs buttons to switch between dialogs ?

Thank you

If using the switch in the main dialog as described in my last post you don't need *any* other definitions or declarations in the app.h nor are any global variable.

To switch from dialog n to dialog m simply pass the appropriate return code when calling EndDialog, e. g.

void Dialog2::OnSwitchToDialog3()
{
      EndDialog(MyDialog_Main::DLG3);   // here pass the next dialog id
}


The OnSwitchToDialog3 handler function may be invoked by a button in dialog 2 or by a menu item.

Note, instead of MyDialog_Main::DLG3 you also could use the IDD_DIALOG3. It only should be different from IDOK, IDCANCEL, IDRETRY which are the normal constants passed to EndDialog.

But if you make that change you have to handle that in MyDialog_Main::handleNextDialog as well.


 

>>>> when program is launched this dialog is hided for displaying Dialog1 in place of

If you use the above switching concept you should call

    handleNextDialog(DLG1);

in OnInitDialog.

Now that I change the functions that switch from dialogs by respecting this order:

AppMainDlg  -> Dialog_1 -> Dialog_3 -> Dialog_2

In this actual code I commented the old code (BEFORE) by remplacing from new one (NOW)

The only problem that I see is that the AppMainDlg appears when Dialog_3 is called and stay always.
How avoid that AppMainDlg apeears ?

Thank you

BOOL AppMainDlg::OnInitDialog()
{
	CDialog::OnInitDialog();
 
//BEFORE
	/*
	EndDialog(TRUE); 
 
	CDlg_1 Dlg;
	Dlg.DoModal();
	*/
	
//NOW
    OnHandleLButtonDialog1(); 
 
	return TRUE; 
}
 
 
void CDlg_1::OnNext() 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
	GetDlgItem(IDNEXT)->EnableWindow(false); 
	CWaitCursor();
	
//BEFORE
	/*
	EndDialog(TRUE); 
 
	Cdlg_3 dlg3;
	dlg3.DoModal();
	*/
	
//NOW
	OnSwitchToDialog3();
 
   return; 
}
 
 
 
 
void Cdlg_3::OnPreview() 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
 
//BEFORE
	/*
	CDlg_1 Dlg1;
	Dlg1.DoModal();
	*/
	
//NOW	
	OnSwitchToDialog1();
 
	return; 
}
 
 
void Cdlg_3::OnSave() (= OnNext) 
{
    ....
	
	
	FreeLibrary(hDLLCOMBO5); 
//BEFORE
/*
       Sleep(10);
       ShowWindow(SW_HIDE); //091013
       UpdateData(FALSE); //091014
       CDlg_2 Dlg2;
       Dlg2.DoModal();
       EndDialog(TRUE); //091002 BUG   <<-----------------  After the code you want to run
 
	   EndDialog(IDOK);  //091023 to really force to close the step2
	   OnCancel();       //091023 
*/
 
//NOW
	OnSwitchToDialog2();
 
     return; // 
 
}
 
 
 
 
void CDlg_2::OnNext()   (= closing the application)
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
 
	//BEFORE
	EndDialog(TRUE); 
	OnOK(); 
	
	//NOW 
	// ?
	
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:

call

    ShowWindow(SW_HIDE);

in OnInitDialog before calling handleNextDialog(DLG1);

BTW, for what do you need that AppMainDlg if it never shows?

Yes,
I did it before but with this line :
 ShowWindow(SW_HIDE);
or without, the dialog_1 appears but the AppMainDlg doesn't appear.
So the problem is not on launching application but just when we click
on the next button of Dialog_1 that the AppMainDlg appears too with Dialog_2

BOOL CANPRCAMIPSetupDlg::OnInitDialog()
{
   CDialog::OnInitDialog();
    ShowWindow(SW_HIDE); // no really necessary because without it when dlg_1 appears AppMaindlg
                                              //doesn't appear

    OnHandleLButtonDialog1();
    return TRUE;  //
}


So how must be the code here below to avoid that AppMainDlg appears?

//dialog_1.cpp
 
void CDlg_1::OnSwitchToDialog3()
{
      EndDialog(CANPRCAMIPSetupDlg::DLG3);  // here pass the next dialog id 
}
 
 
void CDlg_1::OnNext() 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
	GetDlgItem(IDNEXT)->EnableWindow(false); 
	CWaitCursor();
 
         //091026
	/*
	EndDialog(TRUE); 
	Cdlg_3 dlg3;
	dlg3.DoModal();
	*/
	 
	ShowWindow(SW_HIDE); // no need
         OnSwitchToDialog3();
 
   return; //
 }

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:

Hi,

So the only problem is that the CANPRCAMIPSetupDlg appears when dialog_3 and dialog_2 are calling.
Maybe I must be do a get parent window hide ?

Thank you

>>>> dlg3.DoModal();
You still were cascading dialogs as the dlg_1 would still be active when you invoke the dlg_3.

If you don't do what I suggested (or still post old code) I can't figure out what is wrong.

Here is the current code with which one I have this issue.
I posted too olds code before in comment to only seeing
what are changes from before and now.


Thank you

//ANPRCAMIPSetupDlg.h///////////////////////////////////////
class CANPRCAMIPSetupDlg : public CDialog
{
// Construction
public:
 
public: 
      void handleNextDialog(int nextDialog)
     {
        switch(nextDialog)
        {
	   case DLG1:  PostMessage(WM_USER+DLG1, 0, 0); break;
	   case DLG2:  PostMessage(WM_USER+DLG2, 0, 0); break;
	   case DLG3:  PostMessage(WM_USER+DLG3, 0, 0); break;
        }
     }
 
 
	void OnHandleLButtonDialog1()
     {
        int nextdlg = Dlg.DoModal();
        handleNextDialog(nextdlg);
     }
   
    ....
 
}
 
 
//ANPRCAMIPSetupDlg.cpp///////////////////////////////////////
BOOL CANPRCAMIPSetupDlg::OnInitDialog()
{
	CDialog::OnInitDialog();
    OnHandleLButtonDialog1(); 
 
	return TRUE; 
}
 
 
 
//Dlg_1.cpp///////////////////////////////////////
void CDlg_1::OnSwitchToDialog3()
{
   EndDialog(CANPRCAMIPSetupDlg::DLG3);//here pass the next dialog id 
}
 
void CDlg_1::OnNext() 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
	GetDlgItem(IDNEXT)->EnableWindow(false); 
	CWaitCursor();
	OnSwitchToDialog3();
 
   return; 
}
 
//dlg_3.cpp///////////////////////////////////////
void Cdlg_3::OnPreview() 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
	OnSwitchToDialog1();
 
	return; 
}
 
void Cdlg_3::OnSave() (= OnNext) 
{
    ....
	
	
	FreeLibrary(hDLLCOMBO5); 
	OnSwitchToDialog2();
 
    return;
}
 
//Dlg_2.cpp///////////////////////////////////////
void CDlg_2::OnNext()   (= closing the application)
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
 
 
	EndDialog(TRUE); 
	OnOK(); 
	//What must be change?
	
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:

Ok,

>>itsmeandnobodyelse:
>>>> dlg3.DoModal();
this code doesn't appear in my last post

So resuming for my "wizard" application, I have the choice between two designs:

1) this one (from itsmeandnobodyelse )=>    ID: 25644677
2) and with =>  CPropertyPages/CPropertySheet

I try to do a little test application for second design. I realize all dialogs based in CPropertyPage and a main class which is based on CPropertySheet on which I apply the SetWizardMode(); method. And I can I have real wizard's type application. So it is good :)
 
But I do not realize yet my application with second design because my application is big,  and because I begin with the first design and I really want to understand what I'm doing wrong that the first design is not yet running well ?
 
Like I said you the application (with design 1) is almost ok except that the Main Dialog CANPRCAMIPSetupDlg  appears (and is always showing until closing application) when I click on Next button to switch between dialog 1 to dialog 3.

The code I posted you here ( ID: 25691428) is the current code.

Thank you

>>>> ok except that the Main Dialog CANPRCAMIPSetupDlg  appears

Ok, try to add
         
   ShowWindow(SW_HIDE);

before any of call of DoModal, e. g.

void OnHandleLButtonDialog1()
{
       ShowWindow(SW_HIDE);
       int nextdlg = Dlg.DoModal();
       handleNextDialog(nextdlg);
}

Hi,

Ok right thank you,  by changing my functions in MainAppDlg.h for each dialogs
now it is ok the MainAppDlg dialog is well hiding all the time. So now it seems ok and it runs good.

The error that I made is to put this line : ShowWindow(SW_HIDE);
in the functions of Dialog_1, Dialog_2,... class just before these function
 OnSwitchToDialogX(); like example (see code).
Is it right ?

In fact I must only add ShowWindow() on the MainAppDlg like you posted (see code)

//BAD WAY IN DIALOG_X.CPP
void CDlg_X::OnSwitchToDialogX()
{
  EndDialog(CANPRCAMIPSetupDlg::DLGX); //here pass the next dialog id 
}
 
void CDlg_X::OnNext() 
{
	// TODO: Add your control notification handler code here
	UpdateData(TRUE);
	GetDlgItem(IDNEXT)->EnableWindow(false); 
	CWaitCursor();
	 
	ShowWindow(SW_HIDE); // no need
        OnSwitchToDialogX();
 
   return; 
 }
 
 
//GOOD WAY IN MAINAPPDLG.H
void OnHandleLButtonDialogX()
{
       ShowWindow(SW_HIDE); //adding this line
       int nextdlg = Dlg.DoModal();
       handleNextDialog(nextdlg);
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:

>>>> ShowWindow(SW_HIDE); // no need

Would hide the *current* dlg as ShowWindow is a member of CWnd what is a baseclass of CDialog. Hence you actually call

   this->ShowWindow(SW_HIDE);

in the dlgx dialogs what makes less sense as they were closing anyway.

You could do

   GetParent()->ShowWindow(SW_HIDE);

but actually that most likely won't have the wanted effect as the show-up occurs when the child dialog closes and the previous dialog was activated when handling the WM_ACTIVATE message (what happens in the framework) what is *after* calling the EndDialog in the child dialog.

>>ok except that the Main Dialog CANPRCAMIPSetupDlg  appears

If I understand your architecture correctly then I think that behaviour is by design - ie. it behaves how you (and Microsoft in the MFC supplied code) have coded it to behave.

Hi,

Yes there is the problem of the MainAppDlg dlg that appears when I close Dlg_1
that is a real issue.

It becomes from the design I think.
To avoid this problem I have tried to hide initially the MainAppDlg dlg but if I close Dlg_1
the MainAppDlg dlg appears automaticlly.

So my current code is :

PS:
In fact this isssue remind me that I must find too a way to really quit (btw to don't see it in task manager)  the application when I close a dialog for the moment the application is exiting correctly only when step 3 is finished and when I click on finish button which contain is:
void CDlg_2::OnNext()  //Finish Button, (end of step 3)
{
      UpdateData(TRUE);
      EndDialog(TRUE); //091002 BUG
      OnOK(); //
}


Thank you

 
BOOL MainAppDlg ::OnInitDialog()
{
    CDialog::OnInitDialog();
 
    ShowWindow(SW_HIDE);
    OnHandleLButtonDialog1();
 
return TRUE;  //return TRUE  unless you set the focus to a control
}
 
 
void CDlg_1::OnClose() 
{
	// TODO: Add your message handler code here and/or call default
 
	GetParent()->ShowWindow(SW_HIDE);//seem not  
                                         //working		
	EndDialog(TRUE);
	CDialog::OnClose();
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

>>>>      GetParent()->ShowWindow(SW_HIDE);//seem not  
>>>>                                         //working            

I told you it will not work ;-)

You are right

but what would be the workaround ?

>>>> but what would be the workaround ?
Put the ShowWindow(SW_HIDE); above each dlgx.DoModal();

I told you that in #25696698 and you answered

>>>> now it is ok the MainAppDlg dialog is well hiding all the time. So now it seems ok and it runs good.

So, I actually do not quite understand what is the issue now.

Note, if the additional hiding leads to a flicker, you might try to handle the WM_ACTIVATE message in your main dialog. I think the show-up after closing one of the child dialogs comes from the (default) handling of that message. If you override it by an own handler the main dialog should keep hidden.

Ths ShowWindow(SW_HIDE) before the DoModal was also suggested even earlier :

http://www.experts-exchange.com/Programming/Editors_IDEs/C_CPP_CS/Visual_CPP/Q_24817264.html?cid=1573#a25587585

Ok,

In fact you give me the good solution to avoid appearing severals dialogs on the same time
but there was another issue probably due to design and which requires me to manage it by for example overriding WM_ACTIVATE function.

I realized this issue after (ID: 25704666)
>>Yes there is the problem of the MainAppDlg dlg that appears when I close Dlg_1
>>that is a real issue.  
So I will detailed this issue:
Like I have 4 dialogs; the Main dialog (MainAppDlg ) and 3 child dialogs (Dlg_1, Dlg_2, dlg_3)
I realize that by closing one of the child dialogs the Application is still existing (and I can see it in the task manager).
I have confirmed it because I can see the MainAppDlg that appears suddenly after that I close Dlg_1.
And when I close the Dlg_2 or the dlg_3 I can't see the MainAppDlg and it seems like the Application is finished. But it is not true because I can  see that the Application is still running in the task manager.


I can't find the WM_ACTIVATE function is it the OnInitDialog() ?
Must I override this function by only adding ShowWindow(SW_HIDE); inside ?

Thank you

>>>> And when I close the Dlg_2 or the dlg_3 I can't see the MainAppDlg and it seems like the Application is finished.

That is quite the contrary issue, i. e. your main dialog is hidden but no further dialog was selected.

As your main dialog seems to not show at all, you have three choices to prevent the above:

(1) if a child dialog closes but no following dialog was selected, your main dialog should close at well and your prog exits.

      void MainDlg::handleNextDialog(int nextDialog)
     {
        switch(nextDialog)
        {
         case DLG1:  PostMessage(WM_USER+DLG1, 0, 0); break;
         case DLG2:  PostMessage(WM_USER+DLG2, 0, 0); break;
         case DLG3:  PostMessage(WM_USER+DLG3, 0, 0); break;
                   case IDOK:
                   case IDCANCEL:
                        EndDialog(nextDialog);  break;        // ends the main dialog
        }
     }


(2) if a child dialog different to dialog1 closes but no following dialog was selected, you show the dialog 1 (so as you do in the initial phase). If the dialog1 closes returning IDOK or IDCANCEL (i. e. no following dialog was selected) you close the main dialog as well and your prog exits.


      void MainDlg::handleNextDialog(int nextDialog)
     {
        switch(nextDialog)
        {
         case DLG1:  PostMessage(WM_USER+DLG1, 0, 0); break;
         case DLG2:  PostMessage(WM_USER+DLG2, 0, 0); break;
         case DLG3:  PostMessage(WM_USER+DLG3, 0, 0); break;
                   case IDOK:
                   case IDCANCEL:
                        if (currentDlg == DLG2 || currentDlg == DLG3)
                        {
                              PostMessage(WM_USER+DLG1, 0, 0); break;
                        }  
                        EndDialog(nextDialog);  break;        // ends the main dialog
        }
     }


You would need to add a int member currentDlg to your MainDlg class and set it to the current dialog identifier, e. g. like

void MainDlg::OnHandleLButtonDialog2()
{
       ShowWindow(SW_HIDE);
       currentDlg = DLG2;
       int nextdlg = Dlg2.DoModal();
       handleNextDialog(nextdlg);
}

>>>> I can't find the WM_ACTIVATE function is it the OnInitDialog() ?

Add the prototype

 afx_msg void OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized );

to your main dialog class.

Add the macro

   ON_WM_ACTIVATE()

in a new line between BEGIN_MESSAGE_MAP and END_MESSAGE_MAP of your main dialog cpp.

Implement the

void MainDlg::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized )
{
}

Note, your above problems don't were related to OnActivate. So, the OnActivate is only necessary if you want to special actions in your *main* dialog when it was activated or deactivated from Windows operation system.

>>>> you have three choices

Seems it were only two choices ;-)

Hi,

The choice 1) does well what you expected on the 2 first dialogs, but there is a problem when  I close the third dialog, Dlg2 ( step 3) then  the Application doesn't exit?

The changes on my code are (see code):

class CANPRCAMIPSetupDlg : public CDialog
{ 
public:
	CANPRCAMIPSetupDlg(CWnd* pParent = NULL);// standard 
                                                //constructor 
// Dialog Data
	//{{AFX_DATA(CANPRCAMIPSetupDlg)
	enum { IDD = IDD_ANPRCAMIPSETUP_DIALOG };
	enum { DLG1 = 10000, DLG2 = 20000, DLG3 = 30000 };
	CStatic	m_title;
	CStatic	m_static_mac;
	CStatic	m_detected;
	CProgressCtrl	m_progress;
	CComboBox	m_combo1;
	int currentDlg;//091102
	//}}AFX_DATA 

	// ClassWizard generated virtual function overrides
	//{{AFX_VIRTUAL(CANPRCAMIPSetupDlg)
	protected:
	virtual void DoDataExchange(CDataExchange* pDX);	// DDX/DDV support
	//}}AFX_VIRTUAL 
// Implementation
protected:
	HICON m_hIcon;
	CWaitCursor wc;	
	// Generated message map functions
	//{{AFX_MSG(CANPRCAMIPSetupDlg)
	virtual BOOL OnInitDialog();
	afx_msg void OnSysCommand(UINT nID, LPARAM lParam);
	afx_msg void OnPaint();
	afx_msg HCURSOR OnQueryDragIcon();
	afx_msg void OnButton1();
	afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point);
	afx_msg void OnTimer(UINT nIDEvent);
	afx_msg void OnSelchangeComboMain();
	afx_msg void OnButtonCamera();
	afx_msg void MyipAddress();
	afx_msg void MyipAddress2();
	
	//}}AFX_MSG
	DECLARE_MESSAGE_MAP() 
public:   
     void handleNextDialog(int nextDialog)
     {
        switch(nextDialog)
        {
	case DLG1:  PostMessage(WM_USER+DLG1, 0, 0); break;
	case DLG2:  PostMessage(WM_USER+DLG2, 0, 0); break;
	case DLG3:  PostMessage(WM_USER+DLG3, 0, 0); break;
		
	//091102
	case IDOK:
        case IDCANCEL:
           EndDialog(nextDialog);  break; // ends the main dialog
	//091102
        }
     } 
	void OnHandleLButtonDialog1()
     {
	ShowWindow(SW_HIDE);
	currentDlg = DLG1;//091102
        int nextdlg = Dlg.DoModal();
        handleNextDialog(nextdlg);
     }
     void OnHandleLButtonDialog2()
     {
	ShowWindow(SW_HIDE);/
	currentDlg = DLG2;//091102
        int nextdlg = Dlg2.DoModal();
        handleNextDialog(nextdlg);
     }
     void OnHandleLButtonDialog3()
     {
	ShowWindow(SW_HIDE);
	currentDlg = DLG3;//091102
        int nextdlg = dlg3.DoModal();
        handleNextDialog(nextdlg);
     } 
private: 
	CDlg_1 Dlg;
	CDlg_2 Dlg2;
	Cdlg_3 dlg3;
};

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:

And,

If I use choice (2) closing (clicking on the X from window) of the Dialog_3 and Dialog_2 display the Dialog_1.  But I don't need to Display it I want only exiting the all application.

Thank you

>>>> when  I close the third dialog, Dlg2 ( step 3) then  the Application doesn't exit?
Hmmm. Has the dialog 3 an OK and/or Cancel button? If not, how do you exit from dialog3? The point is that dlg3.DoModal() must return

   IDOK  == 1  

or

   IDCANCEL  == 2

or

  DLG1 == 10000

or

  DLG2 == 20000

IDOK is the default for OnOk() or ENTER. IDCANCEL is the default for OnCancel()  or canceling via the red cross.

CANPRCAMIPSetupDlg::DLG1 would indicate the switch to dialog 1 (from dialog 3) and  CANPRCAMIPSetupDlg::DLG2 would indicate the switch to dialog 2 (from dialog 3)

Check the returncode of dlg3.DoModal in CANPRCAMIPSetupDlg. It must be one of the 4 choices. If not, check your calls of EndDialog in CDlg_3 class implementation.

>>>> But I don't need to Display it I want only exiting the all application.

Then choice (2) from the previous post is not the right choice.

>>Has the dialog 3 an OK and/or Cancel button?
Do you mean maybe the step 3 ? Because dialog 3 is step 2 in reality.

I have tested too choice (1) but it was not good because when closing dialog 3 (step2) or dialog 2 (step3) there is always dialog 1 that appears.

Thank you

>>>> Do you mean maybe the step 3 ? Because dialog 3 is step 2 in reality.
I mean dialog 3 of the three child dialogs.

Don't know what you mean by step and why the steps must have different numbers than the dialogs.

>>>>  have tested too choice (1) ... when closing dialog 3 (step2) or dialog 2 (step3) there is always dialog 1 that appears.

Please post *all* the functions of all dialogs which either start dialogs or end the current dialog or switch to another dialog. It seems that you have mixed-up code now.  

In fact  the process of the Wizard steps are like this :

AppMainDlg  -> Dialog_1 (step1) -> Dialog_3 (step2) -> Dialog_2 (step3)   (see:  ID: 25664167)

The AppMainDlg is always hide and when we are in last step (step3), we cannot go to the preview step 2.

Here below code you have all init and switch between dialogs.

//THE MAIN DIALOG
BOOL CANPRCAMIPSetupDlg::OnInitDialog()
{
	CDialog::OnInitDialog();
 
	ShowWindow(SW_HIDE);
    OnHandleLButtonDialog1();
 
	return TRUE;  // return TRUE  unless you set the focus to a control
}
//==========================================================================
 
 
 
//THE DIALOG 1 (meaning STEP 1 of the Wizard)
void CDlg_1::OnSwitchToDialog3()
{
      EndDialog(CANPRCAMIPSetupDlg::DLG3);   // here pass the next dialog id 
}
 
void CDlg_1::OnNext() 
{
 
	UpdateData(TRUE);
	GetDlgItem(IDNEXT)->EnableWindow(false); 
	CWaitCursor();
 
	OnSwitchToDialog3();
 
   return; // Dialog closed and DoModal returns only here! When using EndDialog()
 
}
//===========================================================================
 
 
 
//THE DIALOG 3 (It is the STEP 2 of the Wizard!. Normaly the name must be Dialog 2 because it's the STEP 2 of the 
//Wizard. I let the name Dialog 3 because of avoiding to change many controls name etc,...) 
void Cdlg_3::OnSwitchToDialog1()
{
      EndDialog(CANPRCAMIPSetupDlg::DLG1); 
}
void Cdlg_3::OnSwitchToDialog2()
{
      EndDialog(CANPRCAMIPSetupDlg::DLG2); 
}
 
void Cdlg_3::OnSave() //it is like Next Button
{
 
	UpdateData(TRUE);
	FreeLibrary(hDLLCOMBO5); 
 
	OnSwitchToDialog2();
 
     return;  
}
 
void Cdlg_3::OnPreview() 
{
 
	UpdateData(TRUE);
	OnSwitchToDialog1();
 
	return; 
}
//========================================================================
 
 
 
//THE DIALOG 2 (It is the STEP 3 of the Wizard, this is the last step!) 
void CDlg_2::OnNext() 
{
	UpdateData(TRUE);
 
	EndDialog(TRUE); 
	OnOK(); 
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:

>>>>      EndDialog(TRUE);

Actually TRUE is not a valid end code. But as TRUE matches to 1 and IDOK matches to 1 as well it is the same as EndDialog(IDOK).


>>>>      EndDialog(TRUE);
>>>>      OnOK();


That would call EndDialog(IDOK) twice if you were using the standard OnOK implementation. EndDialog() would add a message to the end of the message queue indicating to close the dialog. A second EndDialog call probably was ignored. But remove the EndDialog(TRUE). It rarely makes sense.


Can you also post the class definition and those functions of the main dialog which do the dialog switch.

Yes the class definition of MainDlg is :

Thank you.

// ANPRCAM IP SetupDlg.h : header file
//
 
#if !defined(AFX_ANPRCAMIPSETUPDLG_H__4CE9851A_0C75_435F_942A_5F8EB1A1432B__INCLUDED_)
#define AFX_ANPRCAMIPSETUPDLG_H__4CE9851A_0C75_435F_942A_5F8EB1A1432B__INCLUDED_
 
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
 
#include "Dlg_1.h"
#include "Dlg_2.h" 
#include "dlg_3.h"
 
/////////////////////////////////////////////////////////////////////////////
// CANPRCAMIPSetupDlg dialog
 
class CANPRCAMIPSetupDlg : public CDialog
{
// Construction
public:
	CANPRCAMIPSetupDlg(CWnd* pParent = NULL);	// standard constructor
 
// Dialog Data
	//{{AFX_DATA(CANPRCAMIPSetupDlg)
	enum { IDD = IDD_ANPRCAMIPSETUP_DIALOG };
	enum { DLG1 = 10000, DLG2 = 20000, DLG3 = 30000 };
 
	CStatic	m_title;
	CStatic	m_static_mac;
	CStatic	m_detected;
	CProgressCtrl	m_progress;
	CComboBox	m_combo1;
	int currentDlg;//091102
 
	//}}AFX_DATA
 
	// ClassWizard generated virtual function overrides
	//{{AFX_VIRTUAL(CANPRCAMIPSetupDlg)
	protected:
	virtual void DoDataExchange(CDataExchange* pDX);	// DDX/DDV support
	//}}AFX_VIRTUAL
 
// Implementation
protected:
	HICON m_hIcon;
	CWaitCursor wc;	
	// Generated message map functions
	//{{AFX_MSG(CANPRCAMIPSetupDlg)
	virtual BOOL OnInitDialog();
	afx_msg void OnSysCommand(UINT nID, LPARAM lParam);
	afx_msg void OnPaint();
	afx_msg HCURSOR OnQueryDragIcon();
	afx_msg void OnButton1();
	afx_msg void OnLButtonDblClk(UINT nFlags, CPoint point);
	afx_msg void OnTimer(UINT nIDEvent);
	afx_msg void OnSelchangeComboMain();
	afx_msg void OnButtonCamera();
	afx_msg void MyipAddress();
	afx_msg void MyipAddress2();
	
	//}}AFX_MSG
	DECLARE_MESSAGE_MAP()
 
public: 
 
     void handleNextDialog(int nextDialog)
     {
        switch(nextDialog)
        {
	        case DLG1:  PostMessage(WM_USER+DLG1, 0, 0); break;
		    case DLG2:  PostMessage(WM_USER+DLG2, 0, 0); break;
			case DLG3:  PostMessage(WM_USER+DLG3, 0, 0); break;
		
				//091102
                   case IDOK:
                   case IDCANCEL:
                        if (currentDlg == DLG2 || currentDlg == DLG3)
                        {
                              PostMessage(WM_USER+DLG1, 0, 0); break;
                        }  
                        EndDialog(nextDialog);  break;// ends the main dialog
				//091102
        }
     }
 
	void OnHandleLButtonDialog1()
     {
		 ShowWindow(SW_HIDE);//091030
		 currentDlg = DLG1;//091102
        int nextdlg = Dlg.DoModal();
        handleNextDialog(nextdlg);
     }
     void OnHandleLButtonDialog2()
     {
		  ShowWindow(SW_HIDE);//091030  
		  currentDlg = DLG2;//091102
        int nextdlg = Dlg2.DoModal();
        handleNextDialog(nextdlg);
     }
     void OnHandleLButtonDialog3()
     {
		  ShowWindow(SW_HIDE);//091030
		  currentDlg = DLG3;//091102
        int nextdlg = dlg3.DoModal();
        handleNextDialog(nextdlg);
     }
 
private: //
	CDlg_1 Dlg;
	CDlg_2 Dlg2;
	Cdlg_3 dlg3;
};
 
//{{AFX_INSERT_LOCATION}}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:

>>>>                         if (currentDlg == DLG2 || currentDlg == DLG3)
>>>>                         {
>>>>                               PostMessage(WM_USER+DLG1, 0, 0); break;
>>>>                         }  

That code was responsible for showing up the Dialog1 after step 2 or step 3.

Remove it. It was for choice (2) of #25718612 where the dialog 1 always would show up if either dialog 2 or dialog 3 close without further switch. But for choice (1) of #25718612 we have that returning with IDOK or IDCANCEL from any dialog would close all dialogs and the application.

Hi,

You are right seems better without this code:

>>>>                         if (currentDlg == DLG2 || currentDlg == DLG3)
>>>>                         {
>>>>                               PostMessage(WM_USER+DLG1, 0, 0); break;
>>>>                         }  

But the issue (application doesn't exit) is again present in the last step, so when I click on X of  Dialog 2's window,  the main application is still present onthe task manager.
Sorry I have not yet show the OnClose() of the Dialog 2 where the problem is (see code below)

Thank you

void CDlg_2::OnClose() 
{
	UpdateData(TRUE);
 
    ...
	...
 
	//SendMessage(WM_CLOSE);
 
	EndDialog(TRUE); 
	OnOK();
 
	CDialog::OnClose();
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

>>>>      EndDialog(TRUE);
>>>>      OnOK();
>>>>      CDialog::OnClose();

Replace all those statements by

  EndDialog(IDOK);

or

remove the void CDlg_2::OnClose()  completely (in header, message map and implementation).

The default behavior of the framework is to call CDialog::OnCancel when the red cross was clicked what actually only calls EndDialog(IDCANCEL).

Your above handling spoils that behavior.

Hi,

I have replaced by:
 EndDialog(IDOK);

but nothing change. I cannot remove CDlg_2::OnClose() because that function contains some important instructions that I need (see code). How can I do ?


Thank you

void CDlg_2::OnClose()
{ 
	UpdateData(TRUE); 
	wrong_exit =true;
	m_progress2.SetPos(100);
	if(good_ipchange==false)
	{ 
			KillTimer(3);
			UINT dwRetVal=0;
			hDLLCOMBO33=::LoadLibrary("iphlpapi.dll"); 
			ULONG taille = sizeof(infos33);
			PULONG ptaille=&taille; 
			LPFNDLLFUNCINIT GetAdaptersInfo = (LPFNDLLFUNCINIT) ::GetProcAddress(hDLLCOMBO33, "GetAdaptersInfo");
			LPFNDLLFUNCCOMBO SetAdapterIpAddress = (LPFNDLLFUNCCOMBO) ::GetProcAddress(hDLLCOMBO33, "SetAdapterIpAddress");  
			UINT retour = GetAdaptersInfo (infos33, ptaille);	 
			if (retour != ERROR_SUCCESS)
			{
				MessageBox("No data find from NIC card");
			} 
			RedrawWindow();  
				if ((dwRetVal = SetAdapterIpAddress(infos33[Global_index].AdapterName, 0, inet_addr(gl_IP_retriev), inet_addr(gl_IPMASK_retriev), inet_addr(gl_IPGAT_retriev))) == 0) //091012 
				{
				   MessageBox("Successfull restore ip");	 
				} 
				else 
				{
				   printf("\tSET ADDR IP failed with error: %d\n", dwRetVal);
				   MessageBox("Problem to set ip address"); 
				   LPVOID lpMsgBuf;
				   if (FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER |
													 FORMAT_MESSAGE_FROM_SYSTEM | 
													 FORMAT_MESSAGE_IGNORE_INSERTS,
													 NULL,
													 dwRetVal,
													 MAKELANGID(LANG_NEUTRAL,
																LANG_ENGLISH), //Default language
													 (LPTSTR) &lpMsgBuf,
													 0,
													 NULL ))  
				   {
			 			   printf("\tError: %s", lpMsgBuf);
						   AfxMessageBox((LPCTSTR)lpMsgBuf, MB_OK | MB_ICONINFORMATION );
							
						   LocalFree( lpMsgBuf );
				   }
					
				} 
			FreeLibrary(hDLLCOMBO33); //free
	}
		system( "taskkill /IM ping.exe /F" );
		remove(FILE_BAT_PING);
		remove(FILE_STDIN);
		remove(FILE_SENDCMD);
		remove(FILE_PING); 
	EndDialog(IDOK);  
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:

>>>> I cannot remove CDlg_2::OnClose()
Don't think that the OnClose() handler function is the right place to do those works.

If I remember rightly the OnClose will be called after the EndDialog. If so, calling EndDialog at end most likely makes no sense (and hopefully was ignored).

Check with the debugger what is the returncode of DLG2.DoModal() in the main dialog. I assume it is different to IDOK and IDCANCEL and taht is why the exit doesn't work.

Also, the OnClose should be called even if the dialog was closed by a cancel (eg. red cross at window top right) as well as the OK button - cancel should mean cancel.  (Bad design?)

I tested by changing on the Main dialog the OnInitDialog function like this (see code):

When launching application I can see the "HELLO" form the TRACE at the moment that Dialog 2 is launching
but the return's value of Dialog2 is dispayed only when I close the Dialog2 and the value is 1 at this moment the Main dialog appears instead of Dialog2.


Thank you

BOOL CANPRCAMIPSetupDlg::OnInitDialog()
{
	CDialog::OnInitDialog(); 
	ShowWindow(SW_HIDE);
	TRACE("\n\nHELLO \n"); 
    //OnHandleLButtonDialog1();
	int returndlg=Dlg2.DoModal();
	TRACE("\n\nVALUE OF RETURN DIALOG2 IS %d\n", returndlg); 
	return TRUE;
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

>> at this moment the Main dialog appears instead of Dialog2.

better replace by :

at this moment the Main dialog appears and the application is not exiting.


thank you

>>>> and the value is 1 at this moment the Main dialog appears instead of Dialog2.
If you want to exit, simply call EndDialog

BOOL CANPRCAMIPSetupDlg::OnInitDialog()
{
    CDialog::OnInitDialog();
    ShowWindow(SW_HIDE);
    TRACE("\n\nHELLO \n");
    //OnHandleLButtonDialog1();
    int returndlg=Dlg2.DoModal();
    TRACE("\n\nVALUE OF RETURN DIALOG2 IS %d\n", returndlg);
    EndDialog(returndlg);
}

Note, the problem why it didn't work is that you exchanged

      OnHandleLButtonDialog1();

by

      int returndlg=Dlg2.DoModal();

The right call would have been:

      OnHandleLButtonDialog2();

where the OnHandleLButtonDialog2 has equivalent implementation to OnHandleLButtonDialog1.

Both functions would have handled the IDOK and ICANCEL return of the sub dialog by ending the main dialog and thus ending the app while your code invokes the main dialog by simply returning from OnInitDialog without calling EndDialog.

If I add EndDialog at OnInitDlg of Main Dlg (see code)
then when I want to go to step 2 the application is closing.

So for the return value of Dlg2.DoModal(); it is 1 .
But I don't know resolving the problem is maybe to use my needed instructions other that in OnClose  in the Dialog and remove this OnClose function is'nt it?

Thank you

BOOL CANPRCAMIPSetupDlg::OnInitDialog()
{
	CDialog::OnInitDialog(); 
	ShowWindow(SW_HIDE); 
    OnHandleLButtonDialog1(); 
    EndDialog(TRUE);
return TRUE;  // 
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

>>>> But I don't know resolving the problem is maybe to use my needed instructions other that in OnClose  in the Dialog and remove this OnClose function is'nt it?

The OnClose has nothing to with the show up of the main dialog. The only reason for the latter was that you added Dlg2.DoModal() in InitDialog but didn't end the main dialog after that. If you call instead one of the OnHandleButtonDialogx functions, the handling of the return code after DoModal automatically was done. So, in your last code snippet, you can and should remove the EndDialog(TRUE); because of two reasons: first it is already done in the OnHandleButtonDialog1 and second it is not TRUE but IDOK (or IDCANCEL) what should be passed to EndDialog.

Back to the Dialog2::OnClose.

The OnClose different to OnOk and OnCancel is called very late *after* the message queue of the modal dialog has detected that the dialog should be closed. In OnOk you normally call EndDialog(IDOK) (what is the default in the baseclass function CDialog::OnOk which is called if you don't have an own Dialog2::OnOk). In OnCancel you normally call EndDialog(IDCANCEL) (what is the default in the baseclass function CDialog::OnCancel which is called if you don't have an own Dialog2::OnCancel).

Doing it that way the calling dialog (in your case the main dialog) could decide whether the user has clicked OK or Cancel (equivalent to the red cross) and get data from the class member object dlg2 what still is available and valid even if the dialog window was closed and destroyed.  The data retrieved from the dialog could be stored to a database or used to display them in the main dialog or whatever, but only if the dialog returned IDOK and not IDCANCEL. Of course you may do it differently and handle IDOK and IDCANCEL same way. No problem ... beside it is an indication of a bad design. Why should the user have an OK button and a Cancel button if both do the same?

But your question was whether the instructions you currently have in the Dialog2::OnClose should be moved somewhere else. Hmmm. The answer is not easy. The Dialog2::OnClose is the conter function to Dialog2::OnInitDialog. While the latter was called when the dialog freshly was created and the dialog window was available the OnClose was called before the dialog window was closed. So if you made some connections to an adapter in Dialog2::OnInitDialog you could make the disconnect in Dialog2::OnClose and all is fine. But of course it makes less sense to have a RedrawWindow() in that code. And surely a lot of message boxes isn't that what you should do in OnClose. I personally would think, you can move all those instructions into a new function and call it either from OnOk or OnCancel. If doing so, you could remove teh Dialog2::OnClose cause the base class function would do as well.  In case the adapter stuff was invoked in the application class or in the main dialog and not from dialog 2, you also should move the *cleanup* to the main dialog or application class.

Hi,

Sorry for long time to response, so it will be more easy by using Wizard CPropertySheets/CPropertyPages that I made but the problem was that this Wizard has Next and Preview buttons by default so how can I customize this Wizard to remove these default buttons or to add others buttons and controls at this?

Thank you

What has that comment you have accepted as an answer got to do with the original question?

Andy is right.

You should have valuated all the comments that helped not only the one that answered your last open question.

Thanks.

Sorry,

Here my comments.
Yes I have severals good solution that you exposed, because of design, because of bad codes etc..
So I choice the last one (ID: 25954200) :

Because propertysheet is basically what we must do for a wizard application. So btw for example  the problem that the Dlg_2 appears sometimes when the Dlg_3 is launching will be resolve anyway I don't know if other good solution exist to avoid this problem.

Secondly because my wizard is not a classic default wizard but with severals controls in a dialog so the solution to this issue will be like itsmeandnobodyelse wrote by modifying the classes it generated and by handler function in cpp source so finding the IDC_...Althougt I don't do the test

But most of posted comments has build sep by step solutions.

Thank you  

If you look carefully more than one expert contributed to solving the original question.  You then asked a follow up question, not baed on the original problem, then accepted a comment by one expert who responded to that.

I think I was also the first expert to even suggest the alternative route - the one you asked the subsidiary question to and have apparently decided to use.

Yes

You pay attention on delicates points and advice me to final solution
( ID: 25604794) that I have choice so you are right you are the first expert to
lightining the real good solution. So thank you AndyAinscow.

Currently I use the way by ID 25589247 but I 'll migre my code to your solution.

Thanks to itsmeandnobodyelse too because he responses well at my last answer
 to keep btw your solution.

Thank you

Sorry ,

the next time I will response to the question " Was this comment helpful?"

:)

Thank you