Memory trashing when I try to make a modal CDialog modeless

I am using MS Visual C++ 6.

I have a CDialog-descended dialog. If I make it a modal dialog,
everything works fine. It opens, I make selections in the dialog,
click OK, data is saved out correctly and so on.

But I want to make it modeless. I don't like locking the user out of
the other windows if there isn't a specific reason to do so, and in
this case there isn't.

To make it modeless, from the routine that creates it,

TagEditDialog * editDialog;
editDialog = new TagEditDialog(this, &metaRow);
MrMainDialog * mainDialog = (MrMainDialog *)parentApp->m_pMainWnd;
editDialog->pSkin = &mainDialog->skin;

//I replace this part
editDialog->DoModal();
editDialog->DestroyWindow();

//with this
editDialog->Create(IDD_TAGEDIT, this);//for modeless
editDialog->ShowWindow(SW_SHOW);

In TagEditDialog, I overrode OnOk(), OnCancel(), and PostNcDestroy(),
to handle destroying the window, but that shouldn't be relevant,
because the memory trashing happens before any of these are called.

TagEditDialog has a member,

MetaDataRow * metaRow

a pointer to an instance of this class (I've removed methods/members
that aren't relevant AFAIK), this basically represents a row in a
database table, it's 30 columns so I wanted a wrapper class to
simplify handling it

class MetaDataRow
{
public:
    MetaDataRow();
    class ColDef
    {
    public:
        ColDef(int order, wstring type, wstring value, bool
noMetaOverride);
        int order;
        wstring type;
        wstring value;
        bool noMetaOverride;
    };
    map<wstring, ColDef> nameValue;
};

(I thought there might be something weird in how I declared ColDef so
I tried declaring it outside of MetaDataRow, but that didn't make any
difference.)

When TagEditDialog is instantiating, everything is fine. I put in a
bunch of lines like this:

int foo = metaRow->nameValue.size();

so I could see at what point things got trashed (that returns correct
results before trashing but a random number after). Also I put a
memory window watching the first 135 bytes at metaRow.

In OnInitDialog() and OnShowWindow(), everything is OK so far. But
the first time I try to access metaRow->nameValue after the window is
displayed, metaRow has been trashed. In the memory window I can see
the contents are changed and are just garbage.

I tried tracing through the MFC code after the call from
OnShowWindow() exits, at that point metaRow has not been trashed.
metaRow remains untrashed all through that, eventually it goes into
assembly language and ends on

call 77E3A430

after which the window displays. Up to that point, metaRow is not yet
trashed.

I added a button to the dialog, which when I click it just tries this

int foo = metaRow->nameValue.size();

again, but at that point metaRow is trashed (and the call returns
garbage.)

***

Anyway ... if I change the dialog back to a modal dialog, everything
works fine.

Between the time OnShowWindow exits and the time the data gets
trashed, as far as I know none of my code gets called; unless maybe
there is a problem in an OnPaint() function somewhere. That seems
strange though, I am not sure why that would affect a modeless dialog
differently from a modal dialog.

Does anybody see anything obviously wrong in the code in general, or
in the way I converted the window from modal to modeless?

The dialog template is based on a generic CDialog, with OK and Cancel
buttons, plus the "test" button I added for trying to debug this.

In addition, there is a row of four CStatic labels and four CEdits.
These are invisible, and are just used as templates to dynamically
create a varying number of label/edit pairs (thanks to this newsgroup
for that idea, which worked very nicely.) Note though that the code
to generate the label/edit pairs is currently commented out, so the
only relevant thing is the four invisible label/edits.

Is there something I should be doing in the template creator
differently for a modeless dialog?

If nobody sees anything obviously wrong, does anybody know a way to
try to further debug this? Is there a way to have visual studio break
when a certain memory address gets written to, so I can get a stack
trace?

--
Joe Cosby
http://joecosby.com/
GIVE ME SLACKS OR KILT ME!!!

:: Currently listening to You Send Me, 1957, by Sam Cooke, from "16 Most Requested Songs"