>>>I revisited the test, reset property sheet entries to 'default', open grid.init event and set column2.controlsource to the first column there. Also, I changed '' to space(1) in button.click event. Unfortunately, I still get the same results. Don't take me wrong, I would be extremely happy if grid will work this way more stable than now, but it does not.
>>
>>Init on the form or init on the Grid? In any event I do my setting after both of these events in a home grown method InitUI. By first column do you mean first column in the table? Are you seriously suggesting that VFP can only make the first column of a grid the first column of a table? I promise you it works. And I don't get you wrong. You want something that works and don't care about anything else.
>
>Ok, I moved it to Form.Init and it's the same. Of course, I don't think that VFP can make only first field to the first column (sorry but it's not very polite suggestion), but to do this you should set column.controlsource explicitly in code and do it subsequently after each recordsource rebuilding. I don't want to argue against your experience, it's yours and if it works for you, that's fine for me.

Sorry if I sounded impolite. I didn't mean it so ! I merely couldn’t believe that foxpro functioned the way you claimed.

So I took another look at your examples and tried them out with my form and found out to my astonishment that Foxpro really reverse the columns even when the grid is initialized (as in my programs) after the form init. So you are right! However you might want to consider why I don’t have these particular problems.

1) The cursors for grids should be created by a single function. When you recalculate the results the results appear in the same order. That means that the order in the fields do not change. I’m a little unclear as to why someone would have a grid that uses different table structures without changing the column structure. I believe it! It's not something that I have seen as necessary. But then it's a big world.

2) I don’t use many expressions in grids. Complicated expressions belong in the business class not in a form. Even in the short run (a year of a programs life) putting calculations in a class that can be accessed by forms, reports and so on saves development and more importantly maintenance time. I make a simple cursor with everything I want to show. Then I can use it in the report. That means my grids already have all the calculations imbedded in the cursor. The formatting is not lost when the cursor is closed with my approach. I said earlier that I had grids with expressions in the control source but it on closer examination I saw that the expressions were in tables that were not being closed.

3) I don't use relations in grids. If at all possible.

I think that the saving of column properties is okay when that’s what you have to do but it shouldn’t be necessary in many if not most cases. Keep it simple! Though God knows that's hard with VFP :-)

James Beerbower
VCA/Qsys
Germany/USA