Robert Collins wrote: > 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?
That would appear to be its intent, but it is a relic of an old way of doing things, and no longer works. (Tested by making it always-called: setup continues on regardless) >> 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. The race window is 2 successive SendMessage calls. Since we are inside the OnNext handler at the time, I don't believe any more messages to setup can be processed. Therefore, I believe we are safe. Max.
