NetTalk Central

Author Topic: Autocomplete - More Assignments - Multi-component key lookup  (Read 3039 times)

CaseyR

  • Sr. Member
  • ****
  • Posts: 448
    • View Profile
    • Email
Autocomplete - More Assignments - Multi-component key lookup
« on: October 31, 2014, 02:54:13 PM »
Hi,

I have a form with a string entry that uses a lookup button successfully, displaying the selection and assigning the additional hidden values.   The lookup browse procedure has a two component key and the browse is primed and filtered to a single value in the first component.  Autocomplete has the same filter as the lookup browse and presents the selection options perfectly, but on selection fails to assign the additional values.  I am pretty sure the problem is in the p_web.GetDecription method called in the Validate:field routine.   It uses the two component key of the lookup browse, but only passes and uses the value of the second component to retrieve the record, so the retrieval fails cancelling the assignment.   

The only option I see is adding another key to the table for just the second component and filtering the unwanted records out, but that seems inefficient when volumes get high and will require dictionary and database changes.  Are there any other options for using a lookup button, autocomplete, and additional assignments?

Many thanks.

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Autocomplete - More Assignments - Multi-component key lookup
« Reply #1 on: November 03, 2014, 11:11:43 PM »
Hi Casey,

I think it's probably best if you make a small example app showing what you are doing.

I'm not sure that multi-component lookups are supported - and I'm not 100% sure that _can_ be suported (unless all but 1 of the components is fixed) but at least with an example I can give it a try.

cheers
Bruce

CaseyR

  • Sr. Member
  • ****
  • Posts: 448
    • View Profile
    • Email
Re: Autocomplete - More Assignments - Multi-component key lookup
« Reply #2 on: November 04, 2014, 06:58:10 PM »
Found the solution.

The GetDescription method assumes that the values of the higher level components of the key have been saved as session values.  That may be the case in most instances (I wasn't able to replicate the problem in an example, not sure why),  it isn't for most of my procedures for some reason.  So, the solution is to save the filtered key values in the session queue in Validate:field routine before GetDescription is called.

Thanks for the considering the problem,