Skip to content

Better Parent - Child Constrained Support

Previous: Committed Records and DD_Commit
Next: Additional DD and DEO Related Changes

Previously, finds in a relates-to constrained child DDO might re-find and refresh the contents of the constraining parent. This could result in unsaved changes in a parent DD getting lost. This design limitation was particularly apparent with header/detail types of views and is why we always required that headers were saved before entering the detail grid. Take a look at the old order entry view, and you will see custom code that is required to make this all work. The framework has worked this way since DataFlex 3.0.

This has been re-engineered for 17.0. The DDOs now handle this much more intelligently so that saves and finds only occur when you expect them to. This means that the header/detail “save first” rule is not needed and that a great deal of custom header/detail view code can be removed. The net result is that header/detail requires less code and they simply work the way you expect them to.

We've altered DD change propagation so that a record find (FindByRowId, Find_By_Recnum, Request_Find, or Request_Assign) does not propagate a parent change if the parent DD is enforcing an existing relates-to constraint. Previously, it would send a change to the parent DD causing the constrained parent DD to be refreshed, losing any changes that might have been made to the parent. It was this refresh that required that you first save any parent changes.

With this requirement lifted, changes have been made in the DDs and the cDbCJGrid class to more intelligently handle changes in constrained headers detail conditions. These changes only apply to relates-to constrained header/detail scenarios:

  1. If you have changes in a header, you can navigate between the header DEO and Grid without needing to first save or clear the header.
  2. If you have changes in a header, you can navigate between unchanged rows in a grid without needing to first save or clear the header.
  3. If a change is made to any detail item, it will require saving. The save will be sent to the Grid, which will also save any changes in the header.
  4. If there are no changes in a detail line (but changes in the header), selecting save or clear-all will delegate the save to the header, firing all of the verifications from the header DEO point of view.

The following changes have been made to support this:

Should_Save_Row in DataDictionary

Should_Save_Row in DataDictionary returns True if the main DD is changed, or if a parent is switched, or if a non-relates-to constrained parent is changed. Previously, this returned true if the main DD was changed or if a parent was switched.

This message now recognizes that a changed non-constrained parent should be treated like a normal change (i.e., row needs saving or the parent change will be lost) while a changed constrained parent is special (no need to save if you switch rows). This was done to make header/detail constraints work better with grids.

ShouldSaveConstrainedToServer in DataDictionary

A new DD message, ShouldSaveConstrainedToServer, returns true if any parent DD is enforcing a relates-to constraint and that parent is changed.

Changes in cDbCJGrids

We've changed Request_Save and Request_Clear_All behaviors in the cDbCJGrid class. If there is nothing to save/clear_all in the detail row but there is a change in the header, the grid will send the save/clear_all message to the header DEO via delegation. This makes the save or clear send verification messages that make more sense for the type of save or clear it is performing.

The cDbCJGrid handles this delegation to the header DEO by sending the new cDbCJGrid messages Request_Save_Parent and Request_Clear_All_Parent. By default, these simply delegate the messages Request_Save_No_Clear and Request_Clear_All, which should direct those messages to the header DEO. You can augment this if standard delegation does not work.

Compatibility Issues

This is a big change and it may impact your application. Hopefully, these changes will be improvements. Currently, there is no backwards compatibility mode to make this work exactly as it used to. We will need your feedback to determine if this will be needed. If you are having issues with this change, you might want to start by removing any special code that you've got to handle the complexities of header/detail navigation. The goal of this change is that you get to remove code.

See Also

  • Data Dictionary Improvements 17.0