>I'm attempting to modify VFP's searchclass (from the wizard) to allow searching on both parent and child table on a form. Does anyone know of a way to dimension an array to contain field names from both the parent and child tables? AFIELDS()apparently allows for only one table, and I would like to be able to search both. Thanks.

In my version of the searchclass, I replaced the SET FILTER with a LOCATE FOR and put the expression in there. The following method was actually designed after this change was made:

Select the child. Then do a AFIELDS(childarray), then loop through and append the child alias with a dot to the fields in the childarray, then ACOPY that array onto the main array created with the AFIELDS(parentarray) that was already in there.

You'll end up with a list like this in your combos:
parentfield1
parentfield2
...
childtable.childfield1
childtable.childfield2
and so on. I hope your child table and all your fields have names your user will understand. Otherwise, you'll need arrays or lookup tables to translate "caption" field names to the real ones you build into your expression.

Another thing I did was to pass a list of fields to be excluded from the list of search fields (like key numbers, logicals, and other odds and ends) and ADEL those elements from the array, and then redimension the array.

This system worked well for me until I started using parameterized views for my child cursor. Since these views contain only the children of one record, you can't LOCATE FOR childview.childfield (expression) (value) and expect to find any values in children of parent records other than the current one. When I get around to it, I will have to make this class get the child table underlying the view, find the appropriate parent, move the pointer to that parent, and requery the view. I haven't worked all that out yet.

Modifying wizard classes can be worthwhile, but wizstyle is a lousy framework, so start over with a real one (tastrade, if nothing else) as soon as you get a chance. I spent a lot of time messing with classes from wizstyle, which were not meant to be modified. The justification was always the need to fix some particular thing quickly. The main good thing about the framework I now have is that I can retrofit it onto apps made with wizstyle, if I ever need to. Better frameworks can't be used that way.