>>>I attended your Application Developer's Visual Foxpro class in New York last December and found it extremely helpful. I recommended to our HR department that your class become the standard VFP class. I think VFP has a lot to offer. Recently I have created a class library and general application framework that my department is using to standardize development and maintenance. I think the OOP features in VFP are terrific. I have on occasion run into some problems that I am unable to solve. One really annoying problem is below:
>>>
>>>
>>>I have an application that has a main form that allows the user to lookup data in a mailing list database. The main form consists of controls from three tables in a one-to-many-to-many relationship, as follows: country is the parent to bank, and bank is the parent to contact. The user navigates through the country table, which is displayed in a text box. The other tables are in grids on the form. As the user moves to a country, the bank grid updates to reflect banks related to that country. The first bank listed will then be the bank that contact information is shown. This form seems to work fine. If the user selects any bank in the bank grid, the contact info. refreshes and displays appropriately for that bank. However, I want to allow the user to double-click on any control bound to any of the tables, and as a result take the user to another form (with 3 tabbed pages - one for each table - to give the user the appearance of data from one table) that shows that record in a
>>>detailed view for possible editing, adding, or deleting. The problem comes in the grids for the child tables. If the user double-clicks any record that is not the first record in the grid, the second form returns the user to the first record from the grid that was double-clicked. I thought I had it solved by saving the record number to a variable and then sending the pointer back to that record. It displays the record when the second form's controls are disabled. However, the pointer goes back to the top record! This is evident when the controls are enabled for editing; the controls refresh to show the record I don't want when they receive focus. I then tried setting a filter on the table to allow it to only point to the record I want. This works as far as the pointer is concerned, but causes all sorts of trouble if I need to add or edit the record. I have the tables related in the dataenvironment, with optimistic table buffering set and the onetomany property in the
>>>relationships set to false to achieve the desired navigational effect. Would using a view for the second form solve the problem? Any thoughts or suggestions would be greatly appreciated.
>>
>>I'm not positive, but I think your primary form is still taking control of the pointer. Maybe if your second form used a private data session and you set the pointer that way....
>>
>>HTH
>>
>>Matt
>
>Personally, I would use cursors for the first form and real tables for the second.

This also touches on a subject that Edward sold me on a few months back: Relationships in the DE cause trouble. It only takes a few extra lines of code in the right places to refresh the form and relocate record pointers where you want them, and then you don't have to worry about all this unwanted "automated" behaviour. Another thing you might want to investigate is using views for the child grids, and requerying when the parent tables record moves. Staying away from programmed in one-to-many relationships in the DE has saved me a lot of grief since going with Edward's advice; I strongly encourage you to try it. HTH

Erik