Is there any way I can switch the RecordSource of a grid without losing nondefault grid controls? Failing that, is there any way I can programatically reestablish the methods of my nondefault grid controls after I've rebuilt them with AddObject() code?
I'm reengineering a VFP6 app (SQL Server back end) to eliminate remote views and replace them with passthrough queries. Many of the forms use a drop-down list box to navigate (e.g., from one county to another) and then display the results on a grid (e.g., census information for the selected county). The grids typically have some nondefault controls (spinners and/or drop-down list boxes) that are used for editing and adding records. An "undo" feature is implemented via table buffering.
When the grid's RecordSource was a remote view, the grid knew it was looking at the same remote view all the time, even when the view was requeried with new parameters. Now, I'm using as the RecordSource an updatable cursor that I load from a query result. I have to recreate the updatable cursor for each query in order to get rid of all of the data from the previous selection (e.g., previously selected county). This destroys the grid.
Setting the RecordSource equal to itself doesn't fix this, nor does setting it to another cursor that is structurally identical to the "real" RecordSource while it's being rebuilt and reloaded. The only solution I can think of is to move the navigation list box off to another form and call the grid form from it. That way, the context is fixed for the entire life of the grid--but this is not as slick as what the users are accustomed to seeing.
TIA for any ideas on this!
I'm reengineering a VFP6 app (SQL Server back end) to eliminate remote views and replace them with passthrough queries. Many of the forms use a drop-down list box to navigate (e.g., from one county to another) and then display the results on a grid (e.g., census information for the selected county). The grids typically have some nondefault controls (spinners and/or drop-down list boxes) that are used for editing and adding records. An "undo" feature is implemented via table buffering.
When the grid's RecordSource was a remote view, the grid knew it was looking at the same remote view all the time, even when the view was requeried with new parameters. Now, I'm using as the RecordSource an updatable cursor that I load from a query result. I have to recreate the updatable cursor for each query in order to get rid of all of the data from the previous selection (e.g., previously selected county). This destroys the grid.
Setting the RecordSource equal to itself doesn't fix this, nor does setting it to another cursor that is structurally identical to the "real" RecordSource while it's being rebuilt and reloaded. The only solution I can think of is to move the navigation list box off to another form and call the grid form from it. That way, the context is fixed for the entire life of the grid--but this is not as slick as what the users are accustomed to seeing.
TIA for any ideas on this!