4 Replies Latest reply on Mar 23, 2009 9:50 AM by philmodjunk

    Form view scrolling

    miw

      Title

      Form view scrolling

      Post

      I have a form view with lots of photos.  Is there a way to keep the Header portion of the Form view layout always visibile at the top of the page and only have the Body part of the window scroll down to see all the data?

       

      I know I could get this to work in a listor table view when my firlds are text but the fields in my body are container fields.

       

      Mike

        • 1. Re: Form view scrolling
          philmodjunk
             I don't understand why a list view with container fields in the body won't work.
          • 2. Re: Form view scrolling
            miw
               You are right; I tried it again this morning and it does work; I don't know what I did wrong the first time I tried it but now it works just like how I wanted it to.
            • 3. Re: Form view scrolling
              miw
                 Phil:  I got the photos in my container fields to render in list mode as you suggested.  However, the photos for all records appear as one scrolls down the window, not just the active record.  Do you know an easy way to just show the active record's container fields yet still allow "next" and "previous" navigation of records themselves?
              • 4. Re: Form view scrolling
                philmodjunk
                  

                Yes.

                 

                The details can very a bit depending on your table and layout design option.

                 

                The Extremely general answer:

                 

                Put next and prev buttons on your layout.

                Write scripts that manipulate either found sets and/or relationships to control what the user sees.

                attach them to the buttons

                 

                Exactly how you implement this depends on your layout and table structure.

                 

                You apparently have a parent table which contains your "active" record and a second table that stores the images in container fields that make up your list. I'm not sure if you are describing a standard list view layout displaying  fields from both tables or if you are using a portal to display your container fields.

                 

                From your first post, I'm guessing that you chose the first option.

                 

                Let's call your parent table PARENT and your second table IMAGES.

                Let's assume you have a single field in PARENT that uniquely identifies what group of images you want the user to see, called Parent_ID. This field should be the Key field linking PARENT to IMAGES in your relationship between the two tables. I'll treat it as a serial number, but it could be a text field of unique names or even a date field and the method can still be used.

                Define a global number field, gParent_ID (It should be the same data type as Parent_ID).

                You'll need to give gParent_ID a value when the user first views your list layout. You can set the value to match Parent_ID of first record or you can put in place some method of asking the user to select a record.

                 

                Your next script would look like this:

                Set Field [PARENT::gParent_ID, PARENT::gParent_ID + 1]

                Enter Find Mode

                Set Field [PARENT:: Parent_ID, PARENT::gParent_ID]

                Set Error Capture [On]

                Perform Find

                Set Error Capture [Off]

                # Add a sort step here if the order of your images is important

                 

                Your previous script is identical but it subtracts one from gParent_ID instead of adding one.

                 

                When your user clicks the Previous and next buttons you step through your PARENT table's records one ID number at a time, while bringing up your matching set of related IMAGE records. Note that if these script produce a value for Parent_ID that does not exist, the user will get an empty set of records and a largely blank screen. You can add additional details to the above script example to prevent searching past the limits of your table and to skip nonexistent ID values.

                 

                If I've made some wrong assumptions about your layout and table design that don't match what you are doing, let me know.