4 Replies Latest reply on Feb 22, 2012 9:25 AM by ahcho

    Conditional Formatting oddity

    ahcho

      Title

      Conditional Formatting oddity

      Post

      Hello!

      So I have two buttons that have conditional formatting rules based on a single field with the toggles being "Yes" and "No". The goal of the button is to communicate to the user that there is a message for a specific employee or site. Pushing the button will change the color of text (see the attached screenie).

      The relationships are setup like so:

      Joblist::_kf_EmployeeID>-------------<JL_Messages_Emp::_kf_EmployeeID

      Joblist::_kf_SiteID>-------------------<JL_Messages_Site::kf_SiteID

      The table occurance for both "message" tables come from the same table.

      So when I push the Red pawn button (the big one outside of the portal), the red pawn disappears immediately upon button press. However, when I push the little red exclamation button (small button inside the portal), the exclamation mark does not disappear. There is a script that changes the value in the tables for the conditional formatting to work. It does disappear when I leave and come back to the layout.

      Has anybody else had this oddity?

      Aaron

      Conditional.jpg

        • 1. Re: Conditional Formatting oddity
          philmodjunk

          Inside the script perfomed when the button inside the portal is clicked, you might include a commit record step to see if it will update the screen.

          What are the conditional format expressions that control the visibility of these layout objects?

          • 2. Re: Conditional Formatting oddity
            ahcho

            The condiontal format expression is:

            Job List_Messages_Site::Read = "No" (The text is formatted white post-condition statement)

            If that statement is true, then the text is set to red.

            Now, placing the commit records step results in the conditional formatting occuring immediately. Removing the commit records step results in a one second delay which was not the same reaction as before (which is a bit odd). I can't actually recreate the original problem after adding the commit records step.

            Is it better practice to have the commit records step in the script?

            Aaron

            • 3. Re: Conditional Formatting oddity
              philmodjunk

              Commit records is usually a very safe "problem solver". It saves the entered data back to the hosted file or back to your hard drive and usually is very low profile.

              There are a few details to be careful of:

              Committing the record closes the open record (and open related records) so that they are no longer locked against other user edits. This means other users may be able to jump in an lock you out before you are ready to release control of the record. And this can make a partially created record visible to other users before you want them to be able to see it. Also, it could trigger some validation error messages simply because the validation rule require data in a field you haven't yet edited. This also releases the 'focus' on the portal row you just clicked/tapped to perform this script so if your script requires that focus, don't commit the record until the very end of your script so that this doesn't interfere.

              • 4. Re: Conditional Formatting oddity
                ahcho

                Thanks!