5 Replies Latest reply on Jan 10, 2013 12:33 PM by philmodjunk

    can't select container field

    tomswell

      Title

      can't select container field

      Post

           In layout mode FM Pro Adv... , If I place a container field into a portal it is thereafter not accesable for re-sizing or placement.

           by any selection technique I'm aware of ? Other objects, no issue.

           I've wasted a huge amount of time experimenting with locking, move forward/back, option/select.

        • 1. Re: can't select container field
          schamblee

               There must be a problem with your database or an object is in front of your container.  Are you sure that your container field is in the portal and not behind the portal. I would suggest doing a new sample databases with a portal and make sure your container field is small enought to fit the row.  Leave space around the edges of the container field.  Don't copy and paste into the sample db incase it is a corruption problem, you don't want to copy the problem. 

          • 2. Re: can't select container field
            tomswell

                 I figured it out.  I'm still trying to completely get a handle on what goes where with a seperation model. I was dabbling with the client file not the server file. A this point both files are Local.

             The INTERFACE file has no data in it,

            The DATA file has no interface elements, and no scripts – well, almost no scripts… just the one startup script that lets me in! 

            Layouts in the DATA file are also thin on the ground – basically, there’s just a “DEV” layout for each table.

            anyone have reference to solid seperation guidelines ? What surprises are awaiting ?

            • 3. Re: can't select container field
              philmodjunk

                   I don't see why the data separation model would have any effect on your ability to select a field object--of any kind, on your layout.

                   Here's a thread I share on Data Separation: Convert to Seperation Model

                   But I doubt that it will reveal anything new to you.

                   The one "gotcha" of which I am aware is if you use Manage | Security to control access to specific tables or groups of records and then try to use a script set to run with "full access privileges" to modify data for which access is restricted for the current user. The "run with full access privileges" setting only applies to access privileges set on the current file--the interface. Any access restrictions set on the data file are still in place preventing unauthorized access. This necessitates using a different method to "unlock" the data temporarily so that your script can go ahead and modify data.

              • 4. Re: can't select container field
                tomswell

                     I should have said ... The nearly same layout in my data file gave me no problems resizing container and assumptions were made that the Layout was important.  At this point after reading more my understanding is I really don't need many layouts or scripts on the Data side. Somehow the client layout is corrupt. No big deal I'll just start "clean". I'm  slowly converting to FM12, testing the seperation files locally  before moving data to "cloud".

                     At tis point my understanding is I really don't need many layouts or scripts on the Data side. Or for that matter TOCs. Only when calculations dependent on them exist.

                     Is it so that the basic "parent / child" TOC relations such as Invoice/lineitems need only exist on client side ?

                     it's so easy to ask ... I know I can experiment.

                • 5. Re: can't select container field
                  philmodjunk
                       

                            At tis point my understanding is I really don't need many layouts or scripts on the Data side. Or for that matter TOCs. Only when calculations dependent on them exist.

                       This is correct and that last sentence will help you answer the next question:

                       

                            Is it so that the basic "parent / child" TOC relations such as Invoice/lineitems need only exist on client side ?

                       If you define calculation fields that require the parent/child relationship, then you need that relationship in the data file. If you do not define such, you don't.

                       And in FileMaker 12, many relationships may not be needed at all in either file if you use ExecuteSQL creatively.