PDA

View Full Version : onAfterFind & Lookup



Bob Worsley
9-Jun-2007, 08:36 PM
There are generally two ways to "find" a record, with data entry and F9 (or
F7/F8) functionality, or with a lookup list. onAfterFind covers the first,
but I haven't found anything similar for a lookup, and finding a record with
a lookup doesn't trigger onAfterFind. If I trigger some secondary events
from onAfterFind, I don't think there's a way to trigger the same ones from
a valid lookup selection. Or if there is, how do I do it? I'd think the
ideal way would be to simply fire onAfterFind after returning from a lookup
selection. Of course there's the problem of the user canceling...
Bob

Anders Ohrt
10-Jun-2007, 03:02 PM
> There are generally two ways to "find" a record, with data entry and F9
> (or
> F7/F8) functionality, or with a lookup list. onAfterFind covers the
> first,
> but I haven't found anything similar for a lookup, and finding a record
> with
> a lookup doesn't trigger onAfterFind.

Did you try OnAfterFindByRowid? From what I understand onAfterFind is only
triggered by Recnum finds, and the lookup probably uses Rowid. Just a wild
guess...

// Anders

Bob Worsley
10-Jun-2007, 08:24 PM
Hi Anders... Good thought, but no joy. I tried substituting and the
results seemed to be inconsistent -- what worked before didn't, and what
didn't appeared like it might... maybe. I'll wait for the experts. <g>
Bob

"Anders Öhrt" <Anders.Ohrt@berendsen.se> wrote in message
news:24wTzo5qHHA.3152@dacmail.dataaccess.com...
>
> > There are generally two ways to "find" a record, with data entry and F9
> > (or
> > F7/F8) functionality, or with a lookup list. onAfterFind covers the
> > first,
> > but I haven't found anything similar for a lookup, and finding a record
> > with
> > a lookup doesn't trigger onAfterFind.
>
> Did you try OnAfterFindByRowid? From what I understand onAfterFind is only
> triggered by Recnum finds, and the lookup probably uses Rowid. Just a wild
> guess...
>
> // Anders
>
>
>

Edwin van der Velden
12-Jun-2007, 02:31 AM
From what I know about it data entry triggers onAfterFind and a lookup
triggers a onAfterFindByRowId when it's opened and a onAfterFindByRowId when
a record is selected. The exception is unrelated lookups, these don't
trigger anything since they don't need to do a find but just copy the value.

--Edwin


"Bob Worsley" <bworsley@comcast.net> wrote in message
news:3Xcvfc8qHHA.5152@dacmail.dataaccess.com...
> Hi Anders... Good thought, but no joy. I tried substituting and the
> results seemed to be inconsistent -- what worked before didn't, and what
> didn't appeared like it might... maybe. I'll wait for the experts. <g>
> Bob
>
> "Anders Öhrt" <Anders.Ohrt@berendsen.se> wrote in message
> news:24wTzo5qHHA.3152@dacmail.dataaccess.com...
>>
>> > There are generally two ways to "find" a record, with data entry and F9
>> > (or
>> > F7/F8) functionality, or with a lookup list. onAfterFind covers the
>> > first,
>> > but I haven't found anything similar for a lookup, and finding a record
>> > with
>> > a lookup doesn't trigger onAfterFind.
>>
>> Did you try OnAfterFindByRowid? From what I understand onAfterFind is
>> only
>> triggered by Recnum finds, and the lookup probably uses Rowid. Just a
>> wild
>> guess...
>>
>> // Anders
>>
>>
>>
>
>
>

Anders Ohrt
12-Jun-2007, 03:38 AM
> From what I know about it data entry triggers onAfterFind and a lookup
> triggers a onAfterFindByRowId when it's opened and a onAfterFindByRowId
> when a record is selected. The exception is unrelated lookups, these don't
> trigger anything since they don't need to do a find but just copy the
> value.

Would it be possible to rename the current an onAfterFind to
onAfterFindByRecnum instead, and let both it and onAfterFindByRecnum call a
new onAfterFind? Otherwise, we must always hook twice to get all kind of
find's. That way, if you only care about finds by recnum you hook into
onAfterFindByRecnum, if you only care about finds by rowid you hook into
onAfterFindByRowid and if you care about all finds (the most common I
think), you hook into onAfterFind.

// Anders

Vincent Oorsprong
13-Jun-2007, 12:56 AM
Anders,

Should a new framework have backwards compatibility in supporting old
methods to find records? Since v11 we suggest you use the RowId's for all
your new code. There is nothing wrong with Recnum's but they are a bit
outdated.

--
Regards,
Vincent Oorsprong
Data Access Europe B.V.
http://www.dataaccess.nl

Anders Ohrt
13-Jun-2007, 05:40 AM
> Should a new framework have backwards compatibility in supporting old
> methods to find records? Since v11 we suggest you use the RowId's for all
> your new code. There is nothing wrong with Recnum's but they are a bit
> outdated.

I don't see this (proposed) change as backwards compatibility. To me it
makes sense that the post-find hook is called onAfterFind, no matter _how_
you found the record. If you want to specify that it's only recnum finds, or
only rowid finds you are interested in, then you hook into
onAfterFindByRecnum or onAfterFindByRowid.

Now that I think about it, since the library never works with recnum's
internally, is there a point to having two hooks at all? Why not just remove
onAfterFindByRowid all together and just using onAfterFind?

// Anders

Bob Worsley
13-Jun-2007, 07:50 AM
I agree with Anders, having to have two different hooks to cover finding a
record seems a bit redundant to me. And it's a pain too. This has been
necessary in VDF since the beginning and has always required extra
programming. In this case I now need to double my code to cover both cases,
and since there's no way to differentiate between them for the particular
job each is doing (onAfterFind for a "find" and onAfterFindByRowid for a
lookup) it looks like it's going to be a bit complicated.
Bob

"Anders Öhrt" <Anders.Ohrt@berendsen.se> wrote in message
news:zaVoGdarHHA.1556@dacmail.dataaccess.com...
>
> > Should a new framework have backwards compatibility in supporting old
> > methods to find records? Since v11 we suggest you use the RowId's for
all
> > your new code. There is nothing wrong with Recnum's but they are a bit
> > outdated.
>
> I don't see this (proposed) change as backwards compatibility. To me it
> makes sense that the post-find hook is called onAfterFind, no matter _how_
> you found the record. If you want to specify that it's only recnum finds,
or
> only rowid finds you are interested in, then you hook into
> onAfterFindByRecnum or onAfterFindByRowid.
>
> Now that I think about it, since the library never works with recnum's
> internally, is there a point to having two hooks at all? Why not just
remove
> onAfterFindByRowid all together and just using onAfterFind?
>
> // Anders
>
>
>

Edwin van der Velden
13-Jun-2007, 08:45 AM
I don't know if there's any specific reason to have the two differnt hooks,
but combining them can also simply done by yourself, just overwrite both
functions and make them call a third function of yourself, that way you only
have to edit that third single function.

I'll forward the request and see what the thoughts of the rest of the
dev-team about it are (any if therés any reason to have differnt hooks), and
based on that I gues we'll decide if they should be combined or not for a
next release. :-)

-Edwin

"Bob Worsley" <bworsley@comcast.net> wrote in message
news:k5A$6kbrHHA.1556@dacmail.dataaccess.com...
>I agree with Anders, having to have two different hooks to cover finding a
> record seems a bit redundant to me. And it's a pain too. This has been
> necessary in VDF since the beginning and has always required extra
> programming. In this case I now need to double my code to cover both
> cases,
> and since there's no way to differentiate between them for the particular
> job each is doing (onAfterFind for a "find" and onAfterFindByRowid for a
> lookup) it looks like it's going to be a bit complicated.
> Bob
>
> "Anders Öhrt" <Anders.Ohrt@berendsen.se> wrote in message
> news:zaVoGdarHHA.1556@dacmail.dataaccess.com...
>>
>> > Should a new framework have backwards compatibility in supporting old
>> > methods to find records? Since v11 we suggest you use the RowId's for
> all
>> > your new code. There is nothing wrong with Recnum's but they are a bit
>> > outdated.
>>
>> I don't see this (proposed) change as backwards compatibility. To me it
>> makes sense that the post-find hook is called onAfterFind, no matter
>> _how_
>> you found the record. If you want to specify that it's only recnum finds,
> or
>> only rowid finds you are interested in, then you hook into
>> onAfterFindByRecnum or onAfterFindByRowid.
>>
>> Now that I think about it, since the library never works with recnum's
>> internally, is there a point to having two hooks at all? Why not just
> remove
>> onAfterFindByRowid all together and just using onAfterFind?
>>
>> // Anders
>>
>>
>>
>
>
>