4 Replies Latest reply on Jun 25, 2014 6:09 PM by keywords

    Wrong field receiving data

    DDoughtie

      I am asking this question to see if anyone has experienced it.... not asking anyone to replicate it because I don't think it can be replicated. I suspect the solution might have some corruption. I can't post the solution because it's proprietary.

       

      Here's the scenario. I have experienced this twice within the same table with different 2 different fields.

       

      I have a field called "Card Address" I have a field called "Card Address_Enter". I have a script that looks at what was entered into "Card Address_Enter", copies the contents (uses "inserted calculated result" with the result being the "enter" field) and then inserts it into the "Card Address." I then have the "Card Address" set to hide when it contains data so the info is obscured. I also clear the "Enter" field after inserting. I do this with about 10 fields related to business info. All work perfectly except this one field. This portion of the script was copied from the ones that work so it's identical to the other steps that work.

       

      When the script runs it inserts the results back into the "Enter" field and nothing shows up in the Address field. Next I tried capturing it with a variable and have it display the variable in a custom dialog to make sure I'm grabbing it. I then clear the Enter field. I then try inserting the variable into the "Card Address" field but once again it gets inserted into the "Card Address_Enter" field and nothing shows up in the "Card Address" field. I originally created the "Card Address_Enter" by duplicating the Card Address field and renaming it.

       

      Troubleshooting I then deleted that field. Created a new one from scratch. Replaced it in the scripts and it worked once then the problem came back. It is as if the field labels and the internal field ID's are messed up. I then did away with the enter field and then when data is entered into the "Card Address" field (and the other 10 fields) it simply sets a status flag and I obscure the data based on the flag. That seemed to have solved the problem for that one.

       

      So, I then used this new technique with another field. I had originally used the same "enter" approach. I created a status flag for "Tax ID Status". This script is independent of the first one because it is handled on a different tab layout. The script basically looks to see if the data has been entered into "Tax ID #" (I would never use a # in a field name but I have to live with what they used because another system expects it). If the field has data then it sets the status flag to 1. I then hide the field based on "1". Once again I used Insert Calculated Results with the value being 1.

       

      I ran the script and the 1 got inserted into the "Tax ID #" field instead of the status field. It replaced the ID that was entered. Here's where it got really strange. I had the field off to the side when I was using the "Enter" approach. I moved the original "Tax ID #" field onto viewable page. I ran the script. The 1 shows up in the "Tax ID #" field on the data entry part of the layout but it did not showup on the original field that I placed at the top of the page for testing. I had others look to make sure I wasn't dreaming that the same field with the same name (field and table name) on the same layout.

       

      I then removed all instances of the field on the layout and created all new layout objects. I then placed them where they needed to be and the script then worked like it was supposed to. So, either the fields had some screwy internal id's or the layout objects did.

       

      This is such a basic script that everyone uses a million times a day I doubt anyone could replicate it with a new file. The history of the file is that it started as FMP 11. Moved to 12. The changes are being made in 13 for use on an iPad.

       

      I'm just seeing if anyone else has seen this behavior. (I''ve seen other 12 to 13 issues where "Hide When Printing" objects created in 12 aren't honored in 13. That I can replicate).


      Dan Doughtie

      Augusta, GA

        • 1. Re: Wrong field receiving data
          DDoughtie

          UGGGGGGGH. The Tax ID field is once again messing up. My fix was only temporary. This is plaquing me and another field is showing this symptom.

          • 2. Re: Wrong field receiving data
            Mike_Mitchell

            Dan -

             

            Have you tried capturing the value in a variable and using Set Field instead of Insert? Since Insert requires the object to be on the layout and available for editing, there might be a flub with that.

             

            Mike

            • 3. Re: Wrong field receiving data
              DDoughtie

              Thanks Mike.

               

              That seems to have fixed the problem. I did try using a variable with Insert Calc Results and had no luck. And I confirmed that all the fields before were on the layout. I'll kick it some more since the last time I "fixed" it the problem came back. I hope this is now gone.


              Dan

              • 4. Re: Wrong field receiving data
                keywords

                A tick to what Mike suggested. Set Variable, then Set Field is pretty much standard in my approach.

                 

                Just a couple of words of caution:

                 

                1.  You mention that "This portion of the script was copied from the ones that work so it's identical to the other steps that work." In my experience this is a potential slipup area, since you usually don't just copy script steps, but then have to adapt them (gather data from a different field, post it to a different field, etc). It is very easy to select the wrong field when doing this, especially with two fields with such similar names as Card Address and Card Address_Enter.

                 

                2.  I assume you have FM Developer. Stepping through scripts using the Debugger with the Data Viewer also open is the very best way to quickly identify where things are breaking down.