🚀 go-pugleaf

"JeJe" <jejesan@hotmail.com> wrote in message
news:3ec08128$1@newsgroups.borland.com...

> inputDialogBox d = new frmInputDialogBox();
> nResult = d.ShowModal();
> ..
> delte d;

You can't use forms on the stack like that, you need to use a pointer
instead:

    inputDialogBox *d = new frmInputDialogBox();
    nResult = d->ShowModal();
    ...
    delete d;

> the strange thing is, I don't think this should work, after
> calling this->Close() on clicking the OK button, the
> ModalResult will be reset to 2 (mrCancel) instead of the
> original value (mrOk), so on the frmInsert, the nResult will
> always be 2.

That is because Close() sets ModalResult to mrCancel internally.  You should
not be calling Close() for a modal form in the first place.  If your OnClick
handler for the Ok button doesn't do anything else, then don't assign an
OnClick handler at all.  Just set its ModalResult property to mrOk at
design-time and leave it at that.  At runtime, when you click the button, it
will automatically assign the form's ModalResult property to the same value
as its own ModalResult property, and the form will close automatically.  If
you need to use an OnClick handler for extra processing, then you must leave
the button's ModalResult property to mrNone and then set the form's
ModalResult property manually.


Gambit

you are right, actually I had this:
frmInputDialog = new TfrmInputDialog(this);
nResult = frmInputDialog->ShowModal();
delete frmInputDialog;

----------------
anyhow, I know this->Close() should not be in the OK button's
OnClick() event, this is written by someone else long time
ago.  the thing that bothers me is that it used to work, and
I don't get it why it should work in any way.  do you see
how it could have ever worked at one point?

Thanks,
Jerri

"Remy Lebeau \(TeamB\)" <gambit47@yahoo.com> wrote:
>
>"JeJe" <jejesan@hotmail.com> wrote in message
>news:3ec08128$1@newsgroups.borland.com...
>
>> inputDialogBox d = new frmInputDialogBox();
>> nResult = d.ShowModal();
>> ..
>> delte d;
>
>You can't use forms on the stack like that, you need to use a pointer
>instead:
>
>    inputDialogBox *d = new frmInputDialogBox();
>    nResult = d->ShowModal();
>    ...
>    delete d;
>
>> the strange thing is, I don't think this should work, after
>> calling this->Close() on clicking the OK button, the
>> ModalResult will be reset to 2 (mrCancel) instead of the
>> original value (mrOk), so on the frmInsert, the nResult will
>> always be 2.
>
>That is because Close() sets ModalResult to mrCancel internally.  You should
>not be calling Close() for a modal form in the first place.  If your OnClick
>handler for the Ok button doesn't do anything else, then don't assign an
>OnClick handler at all.  Just set its ModalResult property to mrOk at
>design-time and leave it at that.  At runtime, when you click the button, it
>will automatically assign the form's ModalResult property to the same value
>as its own ModalResult property, and the form will close automatically.  If
>you need to use an OnClick handler for extra processing, then you must leave
>the button's ModalResult property to mrNone and then set the form's
>ModalResult property manually.
>
>
>Gambit
>
>

"JeJe" <jejesan@hotmail.com> wrote in message
news:3ec124b6@newsgroups.borland.com...

> the thing that bothers me is that it used to work,
> and I don't get it why it should work in any way.
> do you see how it could have ever worked at one
> point?

There is no way it would ever have worked that way before.  Close() has
always set the form's ModalResult to mrCancel.  The only possibility would
be if the OnClick handler was explitically resetting ModalResult back to
mrOk after calling Close() but before returning control to the form.  The
button's ModalResult is set to the form's ModaulResult before the OnClick
handler is triggered.  Calling Close() inside the handler would override
that assignment, so if the handler wasn't resetting the ModalResult back
again after calling Close() then the form's ModalResult would remain at
mrCancel when the form closed.


Gambit

Thanks Gambit,

this will remain as a mystery to me, I compared the source 
codes of all the versions I had in VSS, and they are identical,
so I really don't know what made it to work at one point.
which my customer is really concerned with. basically I don't
have a strong answer for the situation, even tho I know how
to fix the bug.

at one point I moved this frmInputDialog to the auto-create
under properties, which I don't need to.  but I don't think
this has any effects.

all the DLL's in my build (installShield) are all dated
2 years back, so I know my environment didn't get changed.

- JeJe

"Remy Lebeau \(TeamB\)" <gambit47@yahoo.com> wrote:
>
>"JeJe" <jejesan@hotmail.com> wrote in message
>news:3ec124b6@newsgroups.borland.com...
>
>> the thing that bothers me is that it used to work,
>> and I don't get it why it should work in any way.
>> do you see how it could have ever worked at one
>> point?
>
>There is no way it would ever have worked that way before.  Close() has
>always set the form's ModalResult to mrCancel.  The only possibility would
>be if the OnClick handler was explitically resetting ModalResult back to
>mrOk after calling Close() but before returning control to the form.  The
>button's ModalResult is set to the form's ModaulResult before the OnClick
>handler is triggered.  Calling Close() inside the handler would override
>that assignment, so if the handler wasn't resetting the ModalResult back
>again after calling Close() then the form's ModalResult would remain at
>mrCancel when the form closed.
>
>
>Gambit
>
>