From one beginner to another,
I'm quite sure that this tip will be entirely mundane to the experienced developer and largely irrelevant to most everyone else. Still, I thought I'd share what I've been learning as a first attempt to give back to the community that I regularly come to for insight.
Display data from a single child record, namely an image and a description, on its parent layout without the use of a portal. With First, Previous, Next, and Last buttons, the user should be able to navigate through all the images associated with the parent record in a more familiar presentation than a scrolling portal.
Somehow set up a slide control object with a projected maximum number of slides necessary to display each child record.
--This clearly wasn't the right approach, because the number of slides would limit the number of child records to be displayed. More importantly, it didn't answer how to designate which child record would go on each slide.
Create a "MediaNumber" field and global "placeholder" fields in the parent table. MediaNumber should designate the record number within the related found set (not its ID number) for which child data should be displayed. Thus, MediaNumber should always be between 0 (if no related records) and the found count of related child records. (Sadly, at this point I was still navigating to the related records just to get a found count. I have since learned the beauty of an unstored Get(FoundCount) calculation field in the child table.) Next, whenever MediaNumber is modified, call a script which navigates to the child records, goes to the record number defined by MediaNumber, and stores the desired data into local variables. (For the container field, I copied the filepath to the where the image was stored in the variable.) Then, navigate back to the parent form and insert the data into the placeholder fields.
--This essentially accomplished my goal. However, it was overloaded with unnecessary script steps (I was certain), required open storage of container data, and seemed to have terrible performance with just a handful of records.
Getting closer: (After learning more about the relationship graph)
Create a global field--we'll call it "gID"--in the parent table. Add a new table occurrence (TO) of the child table. Relate it to the parent TO by parent primary key = child foreign key, AND gID = child PRIMARY key. By this relationship, only ONE child record will be associated with its parent record at a time, determined by the value given to gID. Now specify the child fields on the parent layout as from this new TO. As in the first attempt, whenever MediaNumber is modified, call a script which navigates to the related child records and goes to the record number defined by MediaNumber. Instead of copying all the data, simply set the parent gID field equal to the child record's primary ID. Return to the parent record. The fields from the new child TO will display the data from the selected child record because of the new relationship.
--With this method performance seemed a little better, but it still required navigating away from the parent layout to find the associated child record's ID.
Most recent iteration:
To avoid the need to navigate away from the parent layout, add a new unstored calculation, "ListChildID", to the parent table. Define it using the List function and the child primary ID, as in List( OriginalChildTO::PrimaryID ). Make sure the TO used has the standard primary = foreign key relationship to the parent table. Now, when the MediaNumber is modified, only one script step is required to change which child record should be seen on the parent record. Simply set the gID field using the GetValue function, passing in the new ListChildID field as the set of carriage return delimited values -- something like GetValue( ListChildID ; MediaNumber ). This calculation will return the primary ID of the child record desired, just the same as navigating to the related child records, only much faster.
--Using the complex relationship, a couple extra fields, and the List function, I can finally display and navigate through data from child records one at a time within the context of a parent layout.
As an added bonus, I placed a portal of the child records outside the boundary of the layout, which I use to delete the current, related child record when a "Delete" button is pushed. In all, I count, "find" (in a sense), display, add new, and delete related child records within the parent layout without a portal on the user's screen.
Again, I don't expect to have taught anyone something new or to get much interest from this post. But if you have any questions, I (or somebody smarter!) will be sure to answer. Better yet, if you are willing to share smarter ways of accomplishing similar tasks, please do!
Thanks for reading,