🚀 go-pugleaf

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
>
>