Parent/Child Applications

Creating applications that support Parent/Child architecture (also known as Header/Detail) is a common task for m-Power developers. This feature aims to greatly simplify the development/customization effort of creating these types of applications. A few examples of Parent/Child applications include:

  • -Order Entry, where Billing/Shipping is stored in the parent, and order lines are in the details.
  • -Expense Forms, where employee information is stored in the parent, and expense lines are in the details.
  • -Enrollment Applications, where user information is stored in the parent, and all of their selected courses are stored in the details.

In short, any application that would require you to have a one to many relationship would be a great candidate for this Parent/Child feature.

Creating your Maintenance applications using the Display & Maintain template using the Parent/Child feature, enables numerous features, including:

  • -Automatic linking of application at run-time. Each parent record will include a link that allows users to view the Child information belonging to the Parent.
  • -The Child review screen will include a link to return to the Parent.
  • -Inclusion of Parent information on Child screens
  • -Auto-delete of Child records when Parent is deleted
  • -Auto-copy of Child records when Parent is copied
  • -Auto-Redirect to add new Child immediately upon creating Header

Video Documentation

Implementing this Feature

  1. Create Parent Application — Create your Parent Application over the necessary tables using the Display and Maintain template. Prior to compiling, navigate to the "Application Settings" section. At the bottom, be sure to set the "Parent/Child Options" value to "Parent Application."
  2. Create Child Application — Create your Child level Application over the necessary tables using the Display and Maintain template. Prior to compiling, navigate to the "Application Settings" section. At the bottom, be sure to set the "Parent/Child Options" value to "Child Application."
  3. Edit Parent Application — Return to the "Build and Customize" screen of your Parent application. Click on the "Link to Child" icon. This is what will bind the two applications together, passing the necessary fields.
    Note: Button missing? Be sure you've specified the application as a Parent Application in step 1 above.
  4. Select Child — Use the drilldown to select the necessary child.
    Note: Child Application missing? Be sure you've specified the necessary application as a Child Application in step 2 above.
  5. Configure Parameters — Use the interface to select the field(s) from the Parent and Child applications that should be linked. For example, if the Parent and Child record utilize Order # as the common link between them, choose both (see image). However, if your case required more than one field (such as Company #), feel free to add as many fields as necessary.

Screenshots of this Feature at Run-Time

  • The Parent Application contains a new button that allows users to see Child records that pertain to the user
  • The Child Application contains Parent information above the Child records as well as a button that allows users to return to the Parent screen

Configuring this Feature

There are three configurable options that are included with this feature, all accessible via the Application Properties of the Parent application, under the "Parent" tab.

  • Auto Redirect On Add — Redirect to Child by default — When 'Redirect to Child' is set, the application will automatically redirect the user to add a Child record after they have added a new Parent Record. However, if "Normal Redirect" is set, when a Parent record is added, the application will simply return back to the Parent maintainer.
  • Auto Copy Child Records — Off by default — When enabled, in the event that a parent record is copied, all associated child records will also be copied
  • Auto Delete Child Records — On by default — will delete all child record associated with the parent when the parent is deleted.

Created: November 30, 2015 | Modified: June 12, 2017