Wouldn't be surprised if there has been some general discussion about this issue in the past. I'd appreciate a pointer to a broader discussion of the issue I raise here.

I just discovered that using a 'thisform' reference in a filter condition is very unhealthy and also that the COUNT function doesn't know what to do with property names having implied references (inside a WITH...ENDWITH block).

The following code generated an unknown member error.

WITH thisform

COUNT FOR logicfuncof(.myproperty) TO nmycnt

ENDWITH

OK, fine. I explicitly made the reference be thisform.myproperty and the error went away. But then I even got a wierder error.

The now corrected code still produced an unknown member error....but for a property which was not even in the current form! Ohhhhhhhhhhhh!

In myform1 I do:

SET FILTER TO logicfuncXtof(thisform.otherproperty)

Then I fire up modal myform2 which executes the COUNT command above, and the COUNT command results in an 'otherproperty' unknown member error.

I guess this is because:

(1) filter expressions are stored as character strings
(2) functions like COUNT use an implicit conjuction of the FOR clause with the current filter expression. So, my COUNT statement above really executes:

COUNT FOR logicfuncof(.myproperty).AND.logicfuncXof(thisform.otherproperty) TO nmycnt

I feel lucky that the form that executes the COUNT does not have a property with the same name as the one calling it, cause I'm pretty sure the 'thisform' in the implied conjunction would have been happy as a clam to use it without complaining.

This bodes badly for saving and restoring filter context, unless I steer clear of 'this' and 'thisform' in filter expressions.

Any insight on this 'feature' of VFP would be greatly appreciated.