>I've believe I've proven to my own satisfaction that when there's a grid on the form, you can't count on SELECT working. In fact, you can't even count on the current workarea staying the same.

It appears that a grid selects its recordsource on gotfocus, and restores it on lostfocus. I can live with this. This allows dynamic properties to reference fields without specifying the alias.

>
>The problem is that a) my classes are based on the perhaps naive assumption that when I SELECT a workarea, it will remain selected until other code selects a different one.

Naive indeed :-).

>b) there are cases in my current app (which I haven't tried to reproduce in a test case) where the grid's workarea remains selected after focus has left the grid, and even after I SELECT a different area.

I have never experienced this, and I tried several different ways to reproduce it.

>If I can't rely on SELECT, then I have to change my classes to always use explicit workareas, which they'll have to get from a form property.
>

My classes do this. (I assume you are talking about vcr buttons, add,edit, delete buttons etc?) If your framework goes on the assumptions that a form is primarily a window into a single table or view, then it's pretty valuable to store the name of that table or view in a form property. Many aftermarket frameworks work like this.

Then your table specific controls would do something like:
SELECT (THISFORM.MainTable)

I have gone with what I feel is a more flexible way, which is to store the alias in the class itself. ie If I have a delete button that is supposed to operate on table a, I set a property of the delete button, so I can have more than one delete button on a form.



>In a way, this might not seem too bad; a selected workarea is not unlike a global variable.

Exactly.

By qualifying each record manipulation with the workarea, it's possible that my code will end up more robust (i.e., less vulnerable to bugs).

I think this is an important realization. I am now maintaining code that I wrote early in my VFP days that didn't adhere to this philosophy, and this is the reason for a huge chunk of my maintenance problems. Make sure all sections of your code look out for themselves. Reduces coupling by assuming nothing.

>What say you all? Do you always qualify record maniplation commands with the workarea, or do you rely on there being a "standard" workarea selected when a form is active?

I try to take it a step further when possible, by specifying the alias in the command itself, and never even selecting the work area except where absolutely necessary:
DELETE IN (THIS.TargetAlias)
or
SEEK This.Value IN (THIS.TargetAlias) ORDER mykey