14 Replies Latest reply on Feb 5, 2010 1:29 PM by mrvodka

    Bug re: portal row validation

    deltatango

      Summary

      Bug re: portal row validation

      Description of the issue

      When you are entering text into a field in a portal row and then try to commit it, if validation fails and you click "no" to edit record, it takes you back to the field but in the FIRST ROW, not the row you were on. This can be confusing to a user. 

        • 1. Re: Bug re: portal row validation
          RickWhitelaw
            

          "if validation fails and you click "no" to edit record"

           

          Do you mean clicking "no" to "allow this value"?

           

          Anyway . . . 

           

          I would capture the portal row number and the object name (portal name if there are more than one on the layout), set variables for these and error trap for failed validation, then send the user back to the appropriate row (with a dialog?) after the validation error and user input (if required). I'm guessing this could be triggered OnRecordCommit, but I do very little data entry in portals, so I can't be certain.

           

          I believe this issue persists because FM does not "see" the Portal Row as a distinct object. It does see the portal that way. For example, the only way to get the height of a Portal Row, despite the syntax   provided for  GetLayoutObjectAttribute: GetLayoutObjectAttribute(objectName;attributeName{;repetitionNumber; portalRowNumber}), is to go to a portal, go to the last portal row, set a variable as Get(PortalRowNumber),

          use  GetLayoutObjectAttribute to get the height of the portal and set a variable, then divide the height by the number of rows. This makes a person believe that a Portal Row has no distinct identification in FM, and I "sort of" see this making sense.

           

          RW 

           

          RW 

          • 2. Re: Bug re: portal row validation
            LaRetta_1
              

            Hi Deltatango,

             

            I believe you have an issue but I can't seem to replicate it.  I am using Windows XP Professional, SP2 and tried it both on 9.0v3 and 10.0v3.  The 'reset vertical scroll' doesn't seem to matter and neither does using a pop-up or drop-down; in fact, nothing I've tried so far seems to matter.  When I commit the record, it returns to the proper field.

             

            Can you tell us precisely your settings in validation so I can try to reproduce it?  :smileyhappy:

             

            UPDATE:  Actually, the cursor doesn't seem to ever leave the field at all.

            • 3. Re: Bug re: portal row validation
              deltatango
                

              Create a table

               

              Create another table for use with a portal, turn on creation via this relationship 

               

              In the portal table create a field and set validation to have "not empty" turned on.

               

              For example:

               

              Invoice -> Invoice Line (with field "amount", validate not empty AND field "description", no validation) 

               

              Now, draw the portal on the layout

               

              Add the fields to the portal

               

              Create 3 Invoice Lines and on the fourth one, leave the amount field blank and try to create another line item with the description field

               

              I get an error that I cannot leave amount blank, Do I want to leave record like this? If I click "No", it's supposed to take be back to that field to edit value, but instead, it takes me to the first amount field in the portal. 

              • 4. Re: Bug re: portal row validation
                LaRetta_1
                  

                Bingo.  It jumps back to the first row and that isn't expected behavior - it should return to where the error was generated, as it does when you change a field value and it fails validation.  It probably has to do with fact that the new portal record hasn't committed yet (validation fails first) but still it should work as expected.

                 

                What also bothers me a great deal is that, if the portal is empty and I create 3 new related records and, on the fourth enter a description and commit (leaving amt empty) and message says I can't leave amt blank and I say Revert, it asks if I want to 'revert all changes to this record since it was last entered.'  If I say yes, then ALL LINES in the portal are deleted because they all were entered at same time!  Major bummer and not what a User would expect.  When it says 'all changes to this record' then I assume it is only the row I'm working on.  It certainly can't mean changes to the parent record because I made no changes to the parent.

                 

                Thank you for bringing this up.  BTW, I was testing on vs. 9.0v3 also.

                • 5. Re: Bug re: portal row validation
                  LaRetta_1
                    

                  Ah. It must be because no new lines are commited - only with allow creation on.  It would explain both jumping to first row (because FM doesn't see the other records yet because they aren't committed, thus don't exist to FM) and deleting all portal records upon Revert.

                   

                  It's used, I guess, in things like transaction model, but I still think it is funky, incorrect behavior.  I can just see a person adding several lineitems while customer is on the phone then hitting a validation error and not understanding the revert message and losing EVERYTHING they entered.  Bad.

                  • 6. Re: Bug re: portal row validation
                    deltatango
                      

                    "What also bothers me a great deal is that, if the portal is empty and I create 3 new related records and, on the fourth enter a description and commit (leaving amt empty) and message says I can't leave amt blank and I say Revert, it asks if I want to 'revert all changes to this record since it was last entered.'  If I say yes, then ALL LINES in the portal are deleted because they all were entered at same time!  Major bummer and not what a User would expect.  When it says 'all changes to this record' then I assume it is only the row I'm working on.  It certainly can't mean changes to the parent record because I made no changes to the parent."

                     

                    Yes, I have noticed this too. Annoying. 

                    • 7. Re: Bug re: portal row validation
                      deltatango
                        

                      Another thing is that you can't use calculations in validation messages and are limited to ONE message. So you have to write something like:

                       

                      {example} 

                       

                      "You must only enter letters and numbers, no spaces, the field cannot be empty and it must not have a value greater than ten and less than five" 

                      • 8. Re: Bug re: portal row validation
                        mrvodka
                           This is because when entering records in the portal, no action has happened to commit the record. Simply going to the empty row and adding a new record does not force a commit. When an action happens that allows a commit, then all those entries you had will commit. Otherwise it would only remain as temp data.
                        • 9. Re: Bug re: portal row validation
                          deltatango
                             I still think it is wonky. The program knows that when you hit Shift + Tab, it goes back to the previous portal row...even if the data isn't committed.
                          • 10. Re: Bug re: portal row validation
                            LaRetta_1
                              

                            Explaining why it happens doesn't mean we agree that the behavior is correct. When you create a new portal record, the prior should be committed.  I see it no differently than this (forgetting the portal for a moment):  If User is one a layout and creates a record then creates a second one, the first record gets committed (because that User on that layout cannot be in two records simultaneously in the same window). 

                             

                            But I wonder if parent/child locking enters into the principle here.  And nice catch on the Shift + Tab.  It certainly gives substance to your argument about returning to the proper last row when validation fails.

                            • 11. Re: Bug re: portal row validation
                              deltatango
                                 as they say in "da hood", "wurd dawg"
                              • 12. Re: Bug re: portal row validation
                                mrvodka
                                  

                                Although I would be in support of another option that would allow users to modify the last entry when on a validation or revertion of a portal row record, I am going to disagree about how on a revert record it should only revert the last entry in the portal row. To me it makes sense that a revert record reverts the data entered into the portal rows. Nothing has been committed so why should it keep those records?

                                 

                                For example, lets take a new parent record. Then we add a bunch of child records via the portal. Now I hit revert. If the sytem had committed those child records along the way automatically while we went into the next row, then we would have had to force a commit on the parent record which we may not want. The parent record has to exist first prior to it having related child records.

                                 

                                 

                                • 13. Re: Bug re: portal row validation
                                  deltatango
                                    

                                  In the company I create databases for, people click out of fields all the time. How is one supposed to control that the user will only "tab" from one field to the next and not click out, thereby committing records? Isn't there some way to NOT commit then by clicking out of a field?

                                   

                                  I just realized it might be done with a script trigger? 

                                  • 14. Re: Bug re: portal row validation
                                    mrvodka
                                      

                                    You can have a button that commit or reverts the record. To stop the dialog you can put an empty web viewer as the layout background.

                                     

                                     

                                    Here is a link.

                                     

                                    http://forum-en.filemaker.com/fm/board/message?board.id=FM-en-4&message.id=31127#M31127