4 Replies Latest reply on Jun 14, 2010 9:51 PM by Richly

    Go To Next Field initialization

    Richly

      Summary

      Go To Next Field initialization

      Description of the issue

      I'm new to FileMaker Pro. Using FM11 on Windows XP SP3.In a script, I've tried the following (the names have been changed to protect the innocent):  Go to Field [T1::F3]  Go to Next Fieldwhere field F1 is the field assigned tab order 1, F2 is tab order 2, etc. (I've left out the code setting variables to field names that shows what's happening and the looping that was supposed to step through all the fields.)The result is that the active field starts at F3, as expected, but the next field is F1 and not F4. From the documentation, Go to Next Field moving to F1 is what I would expect if I hadn't done the Go to Field before it.  It's as though the Go to Field did not initialize something it should have.  What am I missing?  

        • 1. Re: Go To Next Field initialization
          philmodjunk

          I just tested this using Filemaker 11 advanced on a Windows XP SP 3 system. I can't replicate this bug.

           

          I defined three fields, Field 1, Field 2 , Field 3. Their default tab order matches the numbers in their field names.

          My script:

          Go To Field [Table::Field 2]

          Go To Next Field

           

          I ran this several times with the cursor in different fields or after clicking the layout background to keep the cursor out of all the fields. In each case the cursor was placed in Field 3 as I would expect.

           

          Unless I've done something differently than you, try this:

          Create a new layout and test this issue on the new layout.

          It's possible that your layout is corrupted. ( I've had Go To Field refuse to place the cursor in the correct field with filemaker 10 until I rebuilt the layout so this may also be the case here.)

          • 2. Re: Go To Next Field initialization
            Richly

            Thanks for the quick response. I did create another layout, similar to the first, and it behaved as it should, not as the original one did.

             

            My concern now is: what kinds of things corrupt FM layouts? The one that misbehaved had only about 40 fields on each of three tabs, only a few records, and was only about a week old, so neither size nor age is likely to be the explanation. The only other thing I can think of that has a heightened likelihood of causing corruption is that it was being manipulated by amateurs who never saw FM before.

             

            What can one do to prevent corruption? Are there common indications that it's occurred (other things than bad field navigation)? Is there then a way to test for it? How can it be repaired (or can it)?

             

            Again, thanks for your help.

             

            • 3. Re: Go To Next Field initialization
              philmodjunk

              Layout Corruption doesn't happen very often and usually it's fairly easy to fix. In the case of one field performing badly, I've been able to copy and paste all the layout objects from the original layout except the problem field. I then added the problem field "from scratch", updated my tab order and all was well.

               

              As to how it happened, I have no idea. As end users, filemaker is a black box where something went in apparently unbroken and it came out broken. There are known causes of corruption, but which exact cause really can't be pinned down with any certainty.

               

              Your best defense is to make and keep frequent back up copies of your file. Then you can revert back to a previous copy when a problem occurs.

               

              Another useful, though imperfect tool, is the recover command from the file menu. I use it from time to time just to get a check up on my files. I recover them, check for any reported problems and then discard the recovered copies. If filemaker reports "no problems found' then I have some indication that the file is probably OK.

               

              Note that a group of objects that have had an alignment specified before they were grouped can trigger a bogus problem report when you recover the file even though the file is fine.

              • 4. Re: Go To Next Field initialization
                Richly

                Thanks again for another helpful answer.  It's still early in my FM learning curve, and the layout that was giving trouble has been relegated to the trash.  The reason I asked about causes of corruption is to try to avoid whatever they are.  In any case, from your answer, I infer that the encountered corruption is probably local to one layout and not likely to pervade the entire file.

                 

                Cheers!