[RESOLVED] CDialog:ListBox in Doc/View

Instantiating a dialog in a Doc function, I can update an Edit box in the dialog, but when I try to use AddString on a Listbox (using "simple text"), I get an Assertion Failure.
Using VC++6; to illustrate the problem in the simplest app, I created an SDI Doc/View app, added a Dialog class, added a new menu item to invoke the dialog, then added an Editbox (with member variable)and a CListbox (with control member variable) to the dialog. The fact that I can write to the Editbox suggests that the invocation of the Dialog is ok, but the Assertion Error for the List box is a puzzle. I can add data using AddString in an InitDialog function, but this is useless, since I want to add data to the ListBox at runtime. Must be a simple omission somewhere........

More than likely you're calling AddString before the control has been created or after it's been destroyed. What is the ASSERT code telling you?

Debug assertion failure message shows:

File: afxwin2.inl
Line: 669

In the .inl file at Line 668/669 is:
[668] _AFXWIN_INLINE int CListBox::AddString(LPCTSTR lpszItem)
[669] { ASSERT(::IsWindow(m_hWnd)); return (int)::SendMessage(m_hWnd, LB_ADDSTRING, 0, (LPARAM)lpszItem); }

As I wrote earlier, a statement which writes to an Edit Box on the Dialog form is successful, whereas a trying to AddString to the List Box at the same point in the function which instantiates the Dialog causes the Assertion failure. Looks to me like the CListBox::AddString command is expecting to find the Dialog in a standard place, rather than actually getting it from the instantiated Dlg. (Excuse my poor jargonese).

May be you are missing DDX entry for the control or string. Please check if the variable name is present in your MESSAGE_MAP macro. Also, see to it that OnInitialUpdate() function calls the base class version in your view class.
Regards,
Bhushan

That supports what I said in post #2. The Listbox window doesn't exist at the point you're trying to add strings to it.

Thanks for reply, bhushan.
The Dialog class has a DDX entry for the ListBox (c_list):
void CDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CDlg)
DDX_Control(pDX, IDC_LIST1, c_list);
DDX_Text(pDX, IDC_EDIT1, m_edit1);
//}}AFX_DATA_MAP
}
The MESSAGE_MAP for the entire Dialog class is empty. I would never guess in a million years what to put there, nor why.
I also cannot guess what to put in View::OnInitialUpdate.
This c**p drives me mad.

I should add that I want to access the ListBox from the Doc: that's where the data is.
I'll also repeat the point: I can write to the EditBox in the dialog from a Doc function, but attempting to access the CListBox of the Dialog causes an assertion error. It is clear that the Doc class doesn't have a clue about the CListBox, but how to get round this? Or any suggestions as to how to present the user with a list of runtime-generated items, from which they can select any or all? Where in any MS info is there any reference to the need to hand crank a CListBox into life (other than when it's embedded in a CDialog-based appplication)? Maybe I need to use the dreaded GetDlgItem(..) ?

Quote:

---

Originally Posted by crasher

I should add that I want to access the ListBox from the Doc: that's where the data is.
I'll also repeat the point: I can write to the EditBox in the dialog from a Doc function, but attempting to access the CListBox of the Dialog causes an assertion error. It is clear that the Doc class doesn't have a clue about the CListBox, but how to get round this?

---

Your problem is in your design. You shouldn't access dialog controls from your doc, you should access data from your dialog. You can either pass the data from the doc to the dialog before you create it, or you can give the dialog a pointer to your doc and let the dialog ask for the information.

Quote:

---

Maybe I need to use the dreaded GetDlgItem(..) ?

---

What's dreaded about GetDlgItem?

D_Drmmr:
You seem not to have read the posts.

This is a doc/view app. The app reads in a few Mb from various data files (1 to many), and converts and displays the data. The user must be given the choice of which of the various data sets to display together. Therefore a dialog needs to be invoked, in order to present a listbox identifying the data sets which are in memory. All the data is at that point in the Doc. The ListBox has to present the choices, but obviously has to access the identities of the data sets. So I need to pass some info from the Doc to the Dialog. The data is not pre-existing in the dialog, and this is not a dialog app.
You wrote:
"You can ... pass the data from the doc to the dialog before you create it".
That is what I am trying to do, and that is the problem!
I can indeed write to an EditBox in the dialog which I instantiate in a Doc function, but when I try to get the Listbox to accept data (AddString(..)) in the same function, a Windows Assertion Failure is generated. Therefore the ClistBox appears not to have been initialised or its pointer is bent. So there is something tricky about a CListBox in a dialog which is not part of a Dialog-based application.

I've already told you what you're doing wrong.

Quote:

---

Originally Posted by crasher

D_Drmmr:
You seem not to have read the posts.

This is a doc/view app. The app reads in a few Mb from various data files (1 to many), and converts and displays the data. The user must be given the choice of which of the various data sets to display together. Therefore a dialog needs to be invoked, in order to present a listbox identifying the data sets which are in memory. All the data is at that point in the Doc. The ListBox has to present the choices, but obviously has to access the identities of the data sets. So I need to pass some info from the Doc to the Dialog. The data is not pre-existing in the dialog, and this is not a dialog app.
You wrote:
"You can ... pass the data from the doc to the dialog before you create it".
That is what I am trying to do, and that is the problem!
I can indeed write to an EditBox in the dialog which I instantiate in a Doc function, but when I try to get the Listbox to accept data (AddString(..)) in the same function, a Windows Assertion Failure is generated. Therefore the ClistBox appears not to have been initialised or its pointer is bent. So there is something tricky about a CListBox in a dialog which is not part of a Dialog-based application.

---

This doesn't have anything to do with the architecture. Most likely you are trying to access the CListBox.Addstring before calling the base class O

Code:

---


BOOL CMyDlg::OnInitDialog()
{
 
  // BUG: Don't make any calls to child controls here
 
  CDialog::OnInitDialog();
 
  // Child controls initialized, okay to make controls here.
 
  ...
}

---

By the way, passing the data to the dialog is fairly simple. I usually just pass in a pointer to the document in the dialog's constructor.

Just add a parameter to the default dlg constructor that takes your specific app document pointer.

Quote:

---

Originally Posted by D_Drmmr

What's dreaded about GetDlgItem?

---

It's not that it's dreaded, it's just that using it results in extra code.

IMO, most folks use GetDlgItem because it's a carry over from coding in Win32 or they don't know how to create a Control variable in MFC.

The DDX mechanism hides the GetDlgItem implementation, when using data variables also handles the data transfer between the control and its associated variable.

Rather than having ugly GetDlgItem calls with casting everywhere, you can just use the dialog control variable.

Consider an edit box and say you want to hide it.

Create a control variable, and then...

Code:

---

m_EditBox.ShowWindow( SW_HIDE );

---

What about setting the edit box string?

Create a value variable (like CString), and then...

Code:

---

m_sEdit = _T("some text");
UpdateData( FALSE );

---

Compare that with:

Code:

---


CEdit* pBoxOne = (CEdit*) GetDlgItem(IDC_EDIT1);
pBoxOne->GetWindowText( _T("some text" );

---

Sure, you can argue that they're both 2 lines. But consider that UpdateData( ) only needs to be called once after setting any values - even for multiple controls.

GCDEF, yes , thanks for the reminder. And I did notice that nice row of medals you've got there. Now, what about a suggestion, or is putting a usable listbox in a dialog called from a menu entry in a doc/view app really complex? If I knew the solution, I wouldn't be posting here btw.

Quote:

---

Originally Posted by crasher

GCDEF, yes , thanks for the reminder. And I did notice that nice row of medals you've got there. Now, what about a suggestion, or is putting a usable listbox in a dialog called from a menu entry in a doc/view app really complex? If I knew the solution, I wouldn't be posting here btw.

---

The point is the listbox has to exist when you add strings to it. It exists after the call in OnInitDialog to CDialog::OnInitDialog, and before CDialog::EndDialog gets called, which usually happens when you press the okay or cancel buttons.

Can you post a small snipped that shows how you're adding strings and from where.

This is pretty basic. I've created a VC++ 2005 project to show one approach. This sample opens a test dialog from the view and passes in the pointer to the document. However, the test dialog could be as easily invoked from the mainframe or document as well.

I've added a m_sEdit variable to the document and a public GetEditString() public accessor method.

Code:

---

// Attributes
private:
  CString m_sEdit;
// Operations
public:
  CString& GetEditString( ) { return m_sEdit; };


---

When the OnViewTestdialog() menu handler in the view gets called, it creates a CTestDlg object and calls DoModal().

Code:

---

void CSdi2DlgView::OnViewTestdialog()
{
  CTestDlg dlg( this, GetDocument( ) );
  dlg.DoModal( );
}

---

The changes for the TestDlg are simple.

1) Pass in the CDocument ptr in the ctor

Code:

---


CTestDlg::CTestDlg(CWnd* pParent, CSdi2DlgDoc* pDocument)
  : CDialog(CTestDlg::IDD, pParent)
    , m_pDocument( pDocument )
    , m_sEdit(_T(""))
{
}

---

2) Update the OnInitDialog() handler to initialize the local TestDlg
m_sEdit variable with the data from the document

Code:

---

BOOL CTestDlg::OnInitDialog( )
{
  m_sEdit = m_pDocument->GetEditString( );
 
  CDialog::OnInitDialog();



  return 0;
}

---

3) Finally, save the data back to the document when the Ok button is pressed.

Code:

---

void CTestDlg::OnBnClickedOk()
{
UpdateData( TRUE );

m_pDocument->GetEditString( ) = m_sEdit;
 
  OnOK();
}

---

Thanks Arjay. I appreciate your efforts and time spent. You have created a Doc/View project in Visual Studio 2005, which successfully permits writing of data from Doc/View to a dialog called from a menu item. This is what I have already achieved in VC++6.
Unfortunately I cannot figure out what I should do either in VC++6 nor in the VS2005 example you sent in order to be able to transfer data to a CListBox. It has to be a listbox, since the entries are generated at runtime from random filesets, and the entry count can be between 1 and 100 or so, and the user must select which ones he wants converted and simultaneously displayed.
Eugene Kain in his modestly titled book shows how one can communicate between a Dialog and a Doc/View, but cleverly avoids anything other than trivial items. No guesses for what I'd like to do with his fat tome.
I'm beginning to think that what I'm trying to do is impossible.

It's possible. All you do is create a list of items in the document and expose the list to the dialog.

You populate the list box in the OnInitDialog by cycling through the list in the document and calling AddString for each item.

In the OnOk, you add/remove any items in the document's list.

Essentially, it's the exact same thing as what I've shown with the m_sEdit variable except that instead of exposing a CString variable, you expose a list.

Btw, instead of using a CListBox, I'd probably use a CListCtrl in report mode - that way you can bind to the document's list directly.

If I get time, I'll update the sample.

Thanks again Arjay.
I made a few small changes to your project, in order to access a CListBox which I added to the dialog. I commented all the changes ( I hope) with //**crasher.
I get an assertion failure - same as in VC++6 - when trying to AddString.
The dialog Clistbox apparently doesn't exist at that point (one could ask why not, since the Wizard knows all about it?), although its empty rectangle is merrily displayed on the dialog, even though it doesn't exist.
I believe that just before one tries to AddString, a (dlg).Create should be executed, but I'm stuck for which handle/pointer to pass to it (tried a few things). That's even assuming that a Create there would be correct.
In a CListbox in a Dialog App, the CListbox is fully up and running without the programmer having to bend over backwards. Here in a Doc/View it's just left hanging (or totally messed up?).
I've attached the modified project.
Thanks again for your time and trouble.
(Btw, I use VC++6 because 2005 is desperately slow on importing big text/binary files)

By moving the

Code:

---

m_list.AddString(m_pDocument->GetEditString());

---

after

Code:

---

CDialog::OnInitDialog();

---

everything works. Just as GCDEF says. The list control hasn't been initialized(created) that's why you're getting ASSERT on IsWindow.
Or maybe I haven't understood where the problem stands.

Quote:

---

Originally Posted by crasher

Thanks again Arjay.
I made a few small changes to your project, in order to access a CListBox which I added to the dialog. I commented all the changes ( I hope) with //**crasher.
I get an assertion failure - same as in VC++6 - when trying to AddString.
The dialog Clistbox apparently doesn't exist at that point (one could ask why not, since the Wizard knows all about it?), although its empty rectangle is merrily displayed on the dialog, even though it doesn't exist.
I believe that just before one tries to AddString, a (dlg).Create should be executed, but I'm stuck for which handle/pointer to pass to it (tried a few things). That's even assuming that a Create there would be correct.
In a CListbox in a Dialog App, the CListbox is fully up and running without the programmer having to bend over backwards. Here in a Doc/View it's just left hanging (or totally messed up?).
I've attached the modified project.
Thanks again for your time and trouble.
(Btw, I use VC++6 because 2005 is desperately slow on importing big text/binary files)

---

In post number 14 I said "The point is the listbox has to exist when you add strings to it. It exists after the call in OnInitDialog to CDialog::OnInitDialog".

It's frustrating to give somebody the answer and have them ignore you.

Quote:

---

Originally Posted by crasher

Thanks again Arjay.
I made a few small changes to your project, in order to access a CListBox which I added to the dialog. I commented all the changes ( I hope) with //**crasher.
I get an assertion failure - same as in VC++6 - when trying to AddString.
The dialog Clistbox apparently doesn't exist at that point (one could ask why not, since the Wizard knows all about it?),

---

As mentioned several times - a dialog's controls are not available until after the base class call to CDialog::OnInitDialog( );.

See your code below.

Code:

---

BOOL CTestDlg::OnInitDialog( )
{
  //
  // Okay to manipulate data variables here
  //
  // Initialize the edit box string variable
  // from the document
 
  // m_sEdit = m_pDocument->GetEditString( ); //**crasher

  m_list.AddString(m_pDocument->GetEditString()); //**crasher :  ASSERT failure here

  CDialog::OnInitDialog();

  // Okay to manipulate control variables here



  return 0;
}

---

Did you not see my comment // Okay to manipulate control variables here ?

That means to put any control initialization after the base class call.

Yes, SkynetTo, you're right. Arjay (thanks 2!) had already made that clear earlier, but I 'd already gone into frustration/desperation mode. Thanks for pointing out my stupid mistake.
You too were indirectly right, GCDEF, but after your "it doesn't work" posts, I didn't look at your subsequent post. Sorry about that.
Thanks again to all.

Quote:

---

Originally Posted by crasher

You too were indirectly right, GCDEF, but after your "it doesn't work" posts, I didn't look at your subsequent post. Sorry about that.
Thanks again to all.

---

No, I was exactly right and told you what was wrong from the beginning. :mad: