using autocomplete in portal

['makerphile]

I am having trouble using autocomplete within a portal using a value list drawn from a matching field of a different table. Is there a workaround or should I be using a different strategy?

I hold classes with variable attendance, charging per class attended. For each class date, I want to enter a list of attendees onto an attendance list. Then I want that attendance list to generate line items for billing purposes, one line item per student per class. Here is the tricky part. I want to enter, on each line of the attendance list, a couple of keystrokes representing initials or parts of first names, which are non-unique but easier to remember than a student id number. I want those few keystrokes to produce a cue (via autocomplete, ideally) as to something that uniquely identifies the student, so that the line items generated will be associated with the right student (presumably through a serialized student id #). For example, I type in "Da" and autocomplete gives me a choice among

Danny Daniel Johnson #62

Dan Daniel Smith #123

David David Jones #231

David David Jones #342

DA Devin Andrews #164

(The third and fourth suggestions listed above would be two different students - as indicted by different student id#'s - that coincidentally have the same names.) The autocompletion could theoretically use a value list drawn from the CompoundIdentifier field of a StudentInfo table, which would have records like the following:

Nickname/Initials: Danny

FirstName: Daniel

LastName: Johnson

StudentID#: 62

CoumpoundIdentifier: Danny Daniel Johnson 62

The problem is, when I want to enter data into the CompoundIdentifier field of the LineItems table, viewed through a portal in a ClassesTaught table, I cannot autocomplete using a value list from the matching CompoundIdentifier field of the StudentInfo table.

In other words, there would be a ClassesTaught table with a Date field, and a LineItems table with a CompoundIdentifier field and a Date field. I create a relationship matching the Date fields from the two tables and allow for creation of records in the LineItems table using that relationship. Then I create a portal in the ClassesTaught table that shows the CompoundIdentifier field from the LineItems table. Now for each new record in ClassesTaught, I enter a date and then start entering names (in the form of compound identifiers) in the portal. When done entering names, the finished new record in ClassesTaught would show my attendance list, and a new LineItems record would have been created for each attendee listed. Within the portal in ClassesTaught, I would think I could autocomplete entries in the CompoundIdentifier field of the LineItems table using a valuelist from the matching CompoundIdentifier field of the StudentInfo table (which could include students who never had classes before). But this autocompletion based on a value list from StudentInfo::CompoundIdentifier can be done when creating new records directly in the LineItems table, but not when creating those records within the portal in ClassesTaught.

Is there a trick for getting autocomplete to work here? Is it a problem that got fixed in FMA 8.5 (I use 8.3)? Is there a better way to do quick data entry that is less of a kluge than the strategy of using compound identifiers with autocomplete? (What I really want in LineItems records for the purposes of billing summaries is the StudentID#, not all the information in the CompoundIdentifier, since the Nickname part of the CompoundIdentifier could conceivably change within a billing summary cycle.)

[Søren Dyhr]

Compoundfields are almost bygones, but you could get something near what you wish to do by tinkering a little with the priciple in this template:

http://www.newcenturydata.com/downloads/filter.zip

--sd

['makerphile]

Sorry for the late thank you, I didn't open your attachment correctly so that I couldn't see what you had done.

Now that I've got it working, it looks very nice. Is it possible to get the thing to supply possible values without clicking or tabbing out of the boxes, so that you can see whether continued keystrokes are narrowing entries down to a unique entry? That's the nice aspect of autocomplete of which I was trying to take advantage.

Thanks again