>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.

Yes, that's behavior I could live with, too, although it would be nice if it were documented. It's rather important, after all!.

>>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 :-).

I have to admit that this is the first time I've ever seen the WA change without code doing it. That's grids for ya. :)

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

Somewhat against my better judgement (since I gotta get this app wrapped), I think I will indeed try to pare it down to the minimum possible reproducible case. I think it may have something to do with the fact that I'm trying to select the other (nongrid) table from within a button click. This is so soon after the grid has (supposedly) restored the WA that perhaps it's getting confused.

>>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.

Yes, but I hate to have to add stuff that I previously was able to take for granted. If it wasn't for grids, I don't think this would be necessary. Of course, some of my classes do have icAlias properties, but that's the exception rather than what now seems must be the rule.

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

One probable outcome of this is that I'm going to move code out of buttons and into the form. I try to avoid using thisForm as much as possible., at least for property access.

>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.

That sounds good, and I've done similar things. But my code is littered with stuff like

local lcAlias
lcAlias = this.icAlias
if Empty(lcAlias)
lcAlias = Alias()
endif

I will now have to root out all calls to Alias(), RecNo(), etc., etc.

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

I'm glad to have that reassurance.

>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.

Makes sense. On the other hand, the code becomes less generic. If, for example, I change the name of a table, I've got more work to do.

>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

Yes, this is exactly what I'm talking about (since I can't rely on SELECT, apparently).

Thanks, as always, for your comments, Erik.