CStringList or CStringArray

This should be a simple question using VC++ 4.2 but something isn't working too well. I have to transfer data from a listbox before it closes, to use it in the calling class. I've jumped in at OnOK and have attempted to put everything into a CStringList. This was done in many ways, but none worked.

The one that seemed to be fail proof was to go to the calling class and insert the string in the CStringList there, within that class. It inserts it fine (i.e. AddTail). However, once the calling Dialog closes I find the CStringList is empty, though the insertion had no problems. Remember, the dialog is in another class, so the fact that it closes should not affect the different class the CStringList is in. Though this seems to make sense it certainly doesn't work.

I've used a CStringList as I don't know how many elements will be in the list. Maybe a CStringArray is a better solution. Or maybe you have another suggestion.

Thanks for your much needed wisdom!
RJV
RJVAsked:
Who is Participating?
 
gelbertConnect With a Mentor Commented:
I think your problem is that CStringList stores pointer to memory where data is located. So when you close dialog( and destroy class I think which allocated memory for strings of listbox), you destroy memory used to store strings from listbox. As result your CStringList points to undefined memory( You can expect to fuind there anything).
  Whatever you are using to store strings make sure that you allocated memory first, copy strinds there and save pointer to this memory instead of memory of dialog.
0
 
RJVAuthor Commented:
Hi Gelbert,

This is the part that has been unclear in the MFC documentation. It doesn't state clearly that pointers are stored. From what you indicate the best bet is a CStringArray in the destination class.

What is curious is that though the dialog is destroyed, when I access the CStringList later I get a NULL POSITION. I should get a pointer to junk, seeing as the CString was destroyed. That is what doesn't make sense.
RJV

0
 
jasiekCommented:
Answer is somwhere else. In OnOK() function dialog still remains in the memory and is destroyed later. So in OnOk() all dialog members are still valid and still accessible in the memory.
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

 
RJVAuthor Commented:
True, OnOK does leave all valid, which is why I implemented it. The problem is more complex.

Essentially, only the calling function has access to any of the memory in the dialog. If you go to any other function in the class that loaded the dialog, you will not have access to the information in the dialog's class. Just test it to see this.

The inverse is also true, though slightly different. If you go from the dialog class to the calling class before the dialog closes (such as from OnOK), the access to the memory variables in the calling class is not valid. Put anything you wish in them (public or restricted, makes no difference) then finish up with the dialog and see what is in those variables (in the calling class, not the dialog's class). They will be empty.

The problem seems to be associated to MFC's locking classes to views, particularly if the dialog is modal. It isn't easy to change anything in the calling dialog or property sheet (my case) from the called dialog.

I'd run across this type of problem in the past, though not as intensively as now. After nearly a day of testing and using the likes of 'new' and 'malloc' I was able to find out exactly what was happening and then get things to work.

As to CStringList, Gelbert, I'm still not certain about your comment. Indeed, the documentation states that it stores pointers. However, I've seen many examples that transfer text to lists and immediately change or destroy the CString or variable with the original text in it. So the matter is indeed confusing.

Can anyone shed more light on this matter? I'm sure it will help everyone.

Roger
0
 
jasiekCommented:
Hello RJV,
I do programming with dialogs for a long time and I do not exactly know, why you have these problems. I can access anything I want from dialog and anytime I want. Your problem can be with DDX - do you use it?. If you use it I hope you know about UpdateData() function to update your controls.
Send me the part of code (jasiek@writeme.com) where you have problems and I will help you.
Kind regards,
0
 
gelbertCommented:
Hello RJV,

  If memory which pointed by your CStringList is freed you can find there
anything: junk, NULL, valid data. It depends who managed to use it between freeing and using CStringList.
0
 
RJVAuthor Commented:
In answer to both, gelbert the CString supplying CStringList is indeed freed after you close the dialog. Remember, though, that you can access any variable in a dialog even after you close it. This is a standard proceedure. So the data there should be valid. On the other hand, as I indicated, you use one CString for all data. As such, it isn't freed but it changes constantly. Within this context nothing much would be valid for a CStringList.

As to dialogs, yes I use DDXs extensively, Jasiek. I've also done a lot of work with dialogs, from modal to modeless to propertysheets and pages and to dialog bars. That's why this problem caught me completely by surprise. Give it a try.

Include a variable in one modal dialog (property page in my case) and then call another modal dialog. From that dialog, go to OnOK. From there call a function in the first dialog (i.e. via a 'dialog pDlg'). In that function put something in that variable. Then close the topmost dialog (last one called) and take a look at the variable. If you're like me I think you'll be surprised, particularly from what you said. It should be NULL.

RJV
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.