Nando,

> Don't know if an additional value is required to indicate
> that one's going custom; probably Geoff's psNone would do.

There are no event hooks into what I have implemented. We did discuss
it, but I really needed an implementation that was consistent at
designtime as well as runtime (and events dont fire at designtime).
It seems to me that, as you suggest, custom runtime management of
passwords is best handled by setting PasswordStorage to psNone and
then directly assigning the Password property in your code.

Note that the implementation for get/set of the encrytped version of
the password (that will be streamed to the DFM) are setup as virtual
functions, so anyone wishing to replace the storage mechanism can do
so in a derived version of TIB_Connection.

I did consider trying to do "clever" things such as store the password
itself in the registry. I decided against this because it seems
pointless to do without saving the rest of the connection
configuration (server, path, protocol etc). If people really want
such functionality then I suggest a separate component designed to
interact with TIB_Connection - probably setup with its own
customisable login prompt.

Or to put it another way. PasswordStorage is all about reducing the
security implications of storing passwords during development. As
such it is intended primarily to help the developer and not intended
to be part of the end-user functionality. (The exception being the
psNotSecure option to allow the password to be saved for use in the
final result.)


Geoff Worboys
Telesis Computing