Norman,

> if not Connected then
> if LoginAborted then
> Abort
> else
> DoLoginFailure;
>
> Now if the user click Cancel, LoginAborted is set true and the procedure
> Aborts (which doesn't raise an exception) but if it is any other failure,
> the current processing is carried out - an exception is raised (Login
> Failed).

at the risk of playing the devil's advocate role, I'd say that your
change would break existing applications.
Currently one can write:

MyConnection.Connected := True;
try
// do something, being sure that MyConnection.Connected is True.
finally
MyConnection.Connected := False;
end;

With your change, this assumption wold no longer be true. Personally I
don't like properties that reject assignments without raising an
exception, and Connected should not be an exception (no pun intended) to
that.
I'm sure Jason will understand the point. IMHO, the will to "fix" this
behaviour follows from a poor understanding of the whole point of
exceptions in Delphi.
Having said this, since I don't usually have LoginPrompt set to True, it
would not be a practical problem for me if the change weere made. Just a
theoretical problem, which I can live with. :-)


P.S. Everybody could you please watch your quoting?

Ciao
--
____
_/\/ando