>I meant editing two records of the same table/cursor.

I thought you did <s>.

>For example, if form #1 (the navigation form) listed all students, form #2-A would be used to edit student A and form #2-B would be used to edit student B. Since both are records of the same cursor, I would guess data should be kept separate through private data sessions. That would be the first behavior of the class.

I am not really sure that what you are trying to do is standard parent/child data behaviour. You appear to have a navigation form and from that, you load editing sessions from student record found via the navigation form, correct? This is a kind of Codebook type approach. I would be more inclined to make the the student editing form as "parent" form, loading the form using Codemine's OpenFormMulti method (from the statemanager). Then, in the form's find/list methods, have your navigation logic so that each instance of the student form that you load each has its own navigation logic. This way, the student form is the parent form, it is modeless and you can launch as many of them as you or your user requires.

>A different behavior of the class, appropriate for different circumnstances, would be what I think Codemine does natively, namely that there is only one form "#2" and that as you navigate through the first cursor, form #2 shows a different record of the navigation cursor (or an expanded version of the navigation cursor).

This is a standard parent/child linked data relationship. This can occur out of the Codemine box, so to speak.

>How would you suggest to do that?

If you want to retain a single parent form approach (that appears to house your navigation routine), and then launch child forms for editing mutiple records of the same cursor linked to the parents datasession, then you have a couple of options. You could decide how many child records you are prepared to allow. Say you allow three records to be edited, you would have three child cursors in the CDE and give them different alias names eg., Student1, Student2, Student2. Then, each child form you launch can look at a pre-existing workarea in its parent's DE. In the rule classes, your logic can use somethine like

m.cWorkarea = 'Student'

Because we have use "=" as opposed to "==", one type of logic should work for all cursors starting with "Student".

The other way is that when you launch a child form, the child form can load another instance of your student table (using a similar naming convention) using a VFP "USE" command and then call the CDE's AddCursor method to register the newly added cursor to the managed cursor list in the CDE (just like it had been set and specified at design time).

Personally, I think that I would make the Student form the "parent" and use a multi-instance formDataManager as the base form. Then, just use the standard Codemine find/list capabilities to load the correct student. This way, you can load as many students as you like and it is much cleaner.

HTH