Companion Form for an Embedded Browse

[DRW]

I have forms with embedded browses for child table records. I have a button(s) which opens companion form(s) for adding or editing child records displayed in the embedded browse. A companion form is opened to add new records. When closing the form and returning to the parent form, regardless of whether a new child record was created, the record focus in so far as the child table is concerned is automatically placed on the very last record of the pertinent embedded browse. When exiting the companion form back to the parent form shouldn�t record focus relative to the embedded browse be placed either onto the just created child record or back on to the same record that was focused if no new child record was in fact created?

[Keith Hubert]

Re: Companion Form for an Embedded Browse

Hi Douglas,

I have what sounds the same situation, where I need to enter records into a another table that is not in the same set as the opening form, but is related. I do not have a browse on that form that needs to be refreshed. This new form is in a separate set but with same parent as the first form.

This is how I do it.

Save Record.
Open Child form with a filter to match Job Number , enter all required records, there is a browse on this form.
On Close button, Save Record and Close form.
This returns the user back to the form at the same record they left it at.

From what you are describing you are opening another form to enter child records which belong to the browse on the form you have just come from. Why not enter the data into the bowse on that form? Or, when you close the second form, open the first form with a filter which finds the correct record.

Just a couple of thoughts.

[DRW]

Re: Companion Form for an Embedded Browse

Keith, thanks for your suggestions.

The issue I am confronting is only with the addition of new records using the companion browse. Editing records with a companion browse works perfectly fine; i.e. when closing the companion browse in the edit mode the record focus returns to the correct/same record in the parent form�s embedded browse. It just makes no sense to me that when creating a new record in a companion browse that the embedded browse focus back on the parent form should not be placed onto the newest record that was just created in the companion browse.

I�ve attached two screen shots to help illustrate what I �m trying to accomplish.

The first partial screen shot shows a parent form with an embedded browse titled �Rental Units�. Rental_Units is a child table that carries detail records for individual units. Much of the detail for each unit is also shown directly on the parent form under the heading �Rental Unit Details�. So the user can browse through the units in the embedded browse and their details are then displayed on the parent form. Nifty. I want to add new units by calling a companion form. Calling the companion form is pretty simple and straightforward. The problem is that when I exit the companion form after saving new records the embedded browse focus for �Rental Units� shown on the parent form always moves automatically to the last record of the browse, which likewise means that the child record fields displayed on the parent form also are those of the last record in the browse.

The second screen shot shows the results after having added new units via the companion form. Note the embedded browse is now focused on the very last record of the child table (based on sort order). In fact the very last physical record was not the last record added in the companion form � it was the first and record 1A was the last added. I think the proper behavior should have the focus be placed on record 1A, not 2; i.e. the record last in focus in the companion form at the time it was closed. If not that one then at least maybe it should remain on or return to the child record that was in focus when the companion form was opened. In any case the last physical record of the sort order makes no sense.

From what you are describing you are opening another form to enter child records that belong to the browse on the form you have just come from. Why not enter the data into the bowse on that form? Or, when you close the second form, open the first form with a filter which finds the correct record

.

I have played around with using a filtered form as you mentioned. But I have found one shortcoming that leads me not to want to use it for entering child records. When a regular form (not companion) is opened in the manner you are describing the parent form is not deactivated by A5. By that I mean the parent form can still be clicked on even closed with the secondary form being left open. With a companion form the parent form is always deactivated by A5 while the companion form is open and then reactivated when the companion form is closed. I haven�t yet figured out a simple way to accomplish the same result (deactivating and reactivating the parent) using a regular form. I still would just prefer the companion form operate in the manner that I've desxribed.

Regarding the creation of the child records directly on the parent form. Two issues:
1) Maybe I am missing something, but if child fields are directly displayed on the parent form, unless they are actually contained in an embedded subform, it isn�t possible to create a new child record without forcing the parent table into create mode as well, and
2) There may be situations where not all child fields are going to be displayed on the parent form, thus necessitating the use of a companion or regular form to add complete new records.

[MikeC]

Re: Companion Form for an Embedded Browse

Hi Douglas,

By that I mean the parent form can still be clicked on even closed with the secondary form being left open. With a companion form the parent form is always deactivated by A5 while the companion form is open and then reactivated when the companion form is closed.

This is easily accomplished by opening the form as dialog. This will not allow any "movement" between forms until it is closed. One very important note about dialog forms (and a VERY useful one!) is that say you call the form from a button. This calling script can contain several actions after calling a form as dialog but they will not be performed until the form is closed. So you would open the form as dialog, do whatever, then close it...except it actually is still in memory and so the aforementioned calling script can then continue and use what was done on the dialog form. Now a VERY important thing is to make sure that the dialog form is closed completely at the very end of the script (it is not visible but was still in memory and this "second" closing closes it from memory also.). Action Scripting will take care of this normally but not always--if you do ever open a form as dialog and while working notice another or many instances of the same form (they will show as the same form name but with numeric suffixes), then it tells you that the dialog form was not closed completely.

This is a very nice feature to have once you get familiar with the concept.