> Another idea was to assign the where clause to my variable (&vwhere) and use > PROPERTY to refresh the list. That doesn't work, either. > > I think I'll have to use a second form that will contain a scrolling region > but I'd rather keep it clean and on a single form. Any suggestions?
I have a lot of interfaces built on this principal. Here are a few notes: 1. Since a few releases back, in order to optimize search speed, you have not been able to use macro substitution in a lookup where clause. So setting the lookup where clause to anything like: WHERE CustID = .vCustID AND &DateConditions WHERE &vWhere &vWhere will not work. You can still use dotted variables: WHERE CustID = .vCustID AND OrderDate BETWEEN .vStartDt AND .vEndDt 2. It's important to remember, if you are replacing the lookup where clause, that you _must_ include the word WHERE. In the last example above, you cannot use: CustID = .vCustID AND OrderDate BETWEEN .vStartDt AND .vEndDt 3. There are two ways to handle changes to the lookup where clause. The first is to include variables, let the user set the variables, and let the list box refresh itself. The other is to let the user set the variables, have them hit a "Search Now" button, build the WHERE clause _without_ variables (using the literal values of the variables), replacing the existing WHERE clause with the new one, and forcing a refresh. For "search" forms, I prefer the second way because it gives me more flexibility (I can ignore some of the variables if they are not filled in) and more control (I can only run the lookup when I want -- if the user has to enter Start and End dates, for instance, the lookup won't try to recalculate after only the Start date is entered). -- Larry
