Subject Re: [IBO] TIBOQuery: OnSetText and OngetText not firing?
Author John vd Waeter
Daniel Rail wrote:

> It's a parameter of the OnGetText event. And, for the OnGetText, you
> should be assigning to the "Text" parameter. And, for the OnSetText,
> use the Sender parameter to assign the the field.
>
> Here's what your OnSetText event should look like:
>
> procedure Scramble(Sender: TField; const Text: String);
> begin
> Sender.AsString:=Encrypt(Text);
> end;
>
> And, your OnGetText should look like:
>
> procedure DeScramble(Sender: TField; var Text: String; DisplayText:
> Boolean);
> begin
> Text:=Encrypt(Sender.AsString);
> DisplayText:=False;{This permits editing the string value}
> end;

Hi Daniel,

Yes, thank you.... however, the events don't get triggered.

Here's what I do:
- at runtime, create a Request-live TIBOQuery, AQuery
- set the SQL-property.
- connect a ADatasource to AQuery
- Open AQuery, allways zero or 1 row get fetched.
- The dbaware editbox is already connected to Adatasource
- then: AQuery.FieldByName('SecretField').OnSetText := Scramble;
- and: AQuery.FieldByName('SecretField').OnGetText := UnScramble;

Even if I put a Windows.Beep(1000,100) in the Scramble and
Unscrambleroutines, there's NO beep.... ergo, the events don't get fired...

I could imagine the OnGetText doesn't get fired because data is already
fetched and passed into the editbox. But than at least shouldn't the
OnSetText be fired after editing en posting?

Or maybe I should put the lines that set the OnGetText-event and
OnSetText-event somewhere else? I tried in the BeforePrepare-event,(read
some old newsgroupsarticles concerning this matter), but that threw an
exception: Field 'SecretField' not found, followed by an access
violation....

I circumvented so far by using a non-dataaware editbox, decrypt after
opening query and encrypt again in the onpost-event... it works, but
seems ugly programming....

The reason for this encryption is as follows:
- its highly confidential medical data
- the main problem with this data is not the wire being tapped or
hackers entering the system... it's computers getting stolen by
burglers.... So this data MUST reside encrypted inside the database...
and only readable by my application and user with permissions, granted
by my application... (the encryption method is connected to the username).

thanks

John