This is the mail archive of the
mailing list for the Cygwin project.
RE: [setup PATCH] Another micropatch heading towardsnext_dialogremoval (1)
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: "Cygwin Apps" <cygwin-apps at cygwin dot com>
- Date: Sat, 26 Jul 2003 09:45:31 -0500
- Subject: RE: [setup PATCH] Another micropatch heading towardsnext_dialogremoval (1)
> On Sat, 2003-07-26 at 21:31, Max Bowsher wrote:
> > Actually, no.
> > Today, we don't handle the situation because NEXT() is obsolete code that
> > fails to actually do anything.
> Well, NEXT() in this does attempt to reactivate the current dialog
> doesn't it? Gary - any input here?
Yeah, no, NEXT has been broken ever since the switch to the property sheet. I
kept it around becuase it does still do "next_dialog = id", which is not
entirely obsolete until these pending patches are comitted.
> > After this, we kind of handle the situation, and will be able to handle the
> > situation properly one we have full use of exceptions.
> It's not a situation that should warrant an exception or failure. All we
> need to do is get the correct value from the dialog.
> > > It seems better to me to loop (say max 2 times) if such a race occurs,
> > > rather than reentering the dialog or exiting.
> > Try to actually trigger it. The dialog changes so fast, it is impossible to
> > do.
> > So, if a user can't trigger this oddness, the only remaining cause is
> > Windows oddness, which is good reason to bail out.
> > Actually, my preferred change would be to not try to detect this error,
> > since I don't think it can occur.
> Hmm, I'll defer to Gary on this. If he says it's impossible to occur,
> lets simplify the code. If it is possible to occur, lets Do The Right
> thing, windows oddness or not.
I'll look at this tomorrow. It's early and I haven't had my Mountain Dew yet,
but it sounds to me that its not possible to cause this.
Gary R. Van Sickle