David, just a note. Our (Pamela and me) discussion revealed that she uses cursors as row and record source. Incidentally, I use this way too, and exactly for cursors it happened that grid loses definitions, especially if cursor is updated interactively, i.e. user fires new Select-SQL.

>Pamela,
>
>I've never had a grid "lose" itself like Ed is saying is a common problem. It's just plain never happened in my apps, and I use a lot of grids. This isn't to say that it doesn't happen to him, it evidently does, but it's not the global problem he seems to be stressing. Typically creating a custom grid class for each view so that I can just drop it on any form that needs the view.
>
>When you type DO FORM XYZ in the command window you create a public memvar, that's just the way FoxPro works. When the form is released the memvar isn't released but it's no longer an object reference. It still has a type() of "O" but it's not an object.
>
>Are you cleaning up from the first run with a CLEAR ALL? RELEASE ALL? If so you are doing far more to your program environment than just getting rid of the old form object.
>
>Is the grid a subclass from a classlib or just a Grid baseclass with overridden properties on the form? Do you by chance happen to have a grid subclass of the same name stored in another classlibrary? Depending on the order classlibs get loaded into memory you can get one or the other class and not be quite sure which one you'll get.
>
>I'm about 99% sure that there is some environmental difference in your code that is causing this especially if it isn't always repeatable. Bugs are usually more consistent than that. *s*
>
>If a grid has a ColumnCount of -1 it will just build itself from the currently selected alias when the grid instantiation occurs. Which might explain your 18 column grid.
>
>>I have always believed what you say to be true, that the variable should be overwritten and have no effect when the form is run a second time.
>>
>>Specifically, what happens when I run the form a second time while the null object variable is still in memory is that a grid in the form does not define itself according to the column and textbox objects that are defined in the grid class. Instead, it defines itself as the cursor that is assigned as the rowsource. So instead of getting a five-column grid with the dynamic properites defined in the column objects, I get an 18 columngrid with the raw data displayed. It is as though the grid object definition is getting lost somewhere. I have no idea what kind of code in the form or the container object could cause this sort of thing to happen.
>>
>>I can't say that when I release the memory variable before I run the form, it solves the problem every time, but it seems to solve it 90% of the time.