CSI/Syteline: How can I auto populate a field from one IDO and save to another?

In CSI I have a linked DB and IDO setup, I can save new information into it through the form created for it. 

I am looking to add the fields from it to another form, auto populate the fields, this will need to be done from both IDOs, and save the new information back to the linked DB.

 

Example: 

On the Items/warehouse form:

1. Create new tabs (done)

2. Have fields from the item/warehouse default IDO - auto populate using current information from the selected item (done)

3.  Have fields from the IDO Linked DB - Drop down selections (done)

4. Save this data to the IDO Linked DB 

  • Moved to Syteline forum.
  • So it doesn't allow you to save the inputted data to your IDO? I would try to make your new IDO a subcollection of the SLItemWhses IDO and then try saving. I've never tried it so I can't confirm that it will work.
  • In reply to 1362426:

    If I set the fields all to that IDO, yes I can save to it with manually entering the information. Im trying to figure out how to auto populate the fields from the LSItemWhses IDo and save that data to the custom IDO. Like most things, Im probably missing something simple.
  • In reply to 1295924:

    Did you try making your new IDO a subcollection?
  • In reply to 1295924:

    Have you tried using a custom load method? I'm not sure it would work but it's worth a shot. Or you could load your data in with a form script with components attached to your new IDO.
  • In reply to 1362426:

    A secondary collection? Yes. I assume this is what you mean by sub collection. Or are you talking about using a sub form?
  • In reply to 1295924:

    From the help file:

    Understanding forms with collections
    A form's collection may consist of one or more IDO specifications.

    The first IDO specified returns the primary collection. Additional IDOs return secondary collections.

    Secondary collections are useful when you need to create a form that works with multiple collections when some of those do not have parent-child relationships characteristic of subcollections. Since it is easier to implement forms with subcollections than forms with secondary collections, you should use secondary collections only in those cases where subcollections will not work.
  • In reply to 1362426:

    Also:

    Understanding forms with subcollections
    A subcollection is a 'child' collection whose records (rows) are associated with and dependent on the items in the 'parent' (primary) collection. Subcollections are the primary mechanisms for defining hierarchical, parent-child data relationships on forms. Subcollections implement one-to-many relationships between collections.

    To implement a form with a subcollection, bind a grid component to a subcollection property. This property is defined in the parent IDO as a child IDO that is filtered from the parent IDO. You can bind individual properties of the subcollection to grid columns or other form components.

    Examples of forms that use subcollections include the Users form, the Background Task History form, and the Event Handlers form.
  • In reply to 1362426:

    Well now I feel I need more coffee. Im going to work on this and look forward to updating you on how you were correct.
  • In reply to 1295924:

    Ha! I maybe wrong. The suggestion to "load your data in with a form script with components attached to your new IDO" may work too. Looking forward to your solution. :)
  • In reply to 1362426:

    This is something interesting from the February update of Mongoose:

    New SubForm component
    You can now load forms within a different (parent) form, using a new container component named
    SubForm.
    We also added the Default SubForm Spec property and the Title Bar property to set up this component.
    These properties are located under the Miscellaneous > Specific Attributes section on the Component
    property sheet.
    Enhanced sub-report capabilities
    We elevated the capabilities of FlexLayout regions in sub-reports to the same level of citizenship as
    the FlexLayout regions in parent reports. You can now set page breaks and page renumbering properties
    in sub-reports and have these properties honored by the parent report. (Previously, the properties that
    were set on FlexLayout regions in sub-reports were ignored by the parent report, and the parent report
    overrode the sub-report with its own properties.)
    You can now display or hide blank sub-reports by setting an appropriate VisibleWhen property on all
    regions within the sub-report. If any, or all, regions in the sub-report are not visible, then they are also
    not visible in the parent report.
    When a sub-report cannot be displayed due to permission or licensing issues, a static control with an
    error message displays on the parent form in the location where the sub-report should be placed.
    Resolving the issue with the sub-report removes the static error message from the parent report.