Probably a logic error in TCustomConnectDialog.Execute

Discussion of open issues, suggestions and bugs regarding ODAC (Oracle Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
h.hasenack
Posts: 48
Joined: Tue 20 Jan 2009 12:35

Probably a logic error in TCustomConnectDialog.Execute

Post by h.hasenack » Mon 03 May 2010 08:30

I fill in username, severname in TORAConnection
But when the connection dialog pops up, always the previous login info is displayed (Fetched from registry) rather than the username actually provided username by the calling routines.

I managed to fix this error by commenting out the "not" in line 13778

Code: Select all

      
if KeyOpened and ({not} IDE or (Connection.Username = '')) then
        LoadInfoFromRegistry(Registry);
Am I correct?

Regards

bork
Devart Team
Posts: 649
Joined: Fri 12 Mar 2010 07:55

Post by bork » Thu 06 May 2010 09:42

Hello

If you want to forbid loading UserName and Server by the connection dialog from the registry then you should set the StoreLogInfo property of the TConnectionDialog to False.

h.hasenack
Posts: 48
Joined: Tue 20 Jan 2009 12:35

Post by h.hasenack » Thu 06 May 2010 13:32

I understand. But it just seems the rest of the logic works to displaying the stored info only if no username/password was provided by the calling app.

I dont mind the app storing the settings at all. I just wat the stored settings to overwrite my (programatically entered) username and password values.

So: when called from something in the delphi IDE: always overwrite with stored info (hence the NOT has to dissapear)
else: only overwrite if the username is empty.

Now it says: if NOT called from the IDE, always overwrite the username with the stored info. That doesnt make sense to me.

regards

bork
Devart Team
Posts: 649
Joined: Fri 12 Mar 2010 07:55

Post by bork » Fri 07 May 2010 13:42

Hello

Many users expect TConnectDialog to have some peculiar behavior. And often needs of one user contradict the needs of another user. So no matter how hard we try, we won't be able to implement the behavior of TConnectDialog that would satisfy all users. If you need TConnectDialog to have some certain behavior in your application, you should create your own class inherited from TCustomConnectDialog or from TConnectDialog and override virtual Execute, LoadInfoFromRegistry methods or any other methods to implement the behavior that would satisfy you.

Post Reply