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.

I found that setting focus to the grid--either programmatically or by clicking--changes the workarea to the grid's RecordSource. I haven't seen this documented anywhere, but I admit it makes some logical sense.

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

Problem a) is possible to deal with, once I understand that this is normal behavior (I'd be interested if anyone disagrees that this is what happens, though). But problem b) is a different matter. 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.

In a way, this might not seem too bad; a selected workarea is not unlike a global variable. 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).

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?