Marking mandatory table columns

Home Forum Working with Tables Marking mandatory table columns

This topic contains 4 replies, has 0 voices, and was last updated by  srogers 10 years ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #841



    I have a table with 10+ columns. About half of these columns are mandatory. When I check whether or not they have values using the check mandatory behavior, all the column headers are marked in red if any one column doesn’t have data.

    Is there a way to mark only the specific columns that require values when you check mandatory?

    It’s very confusing to the user, who may have an entry which legitimately doesn’t have data for a column, as it appears that all columns are mandatory.


    You could create a behavior on submit that loops through the table and at each row uses a simple branch (is *field* – current row empty?). If true, use a Show Message behavior object. The empty field in the table will remain highlighted.

    Build the behavior like this:

    Set Table Rows – move to first row.

    Simple Branch – Is field empty?

    If true, show message. if false move on to

    Set Table Rows – Move to next row.

    Simple Branch – Last Behavior was successful?

    If true loop back to first Simple Branch

    If false go to Exit behavior object.

    Workflow software, Process software, Procedure software



    That looks like it should work – It will make the behavior screen of my submit button unworkably huge, as there are already a number of behaviors associated with it.

    I’ve tried to make a placeholder button on a hidden page to house large behaviors, and call them from other behaviors. Problem is, if you call a behavior from another behavior, the Exit behavior item will only exit the current behavior (If there are more items in the original behavior, they will continue). Is there a way to end all active behaviors? Or would the “last command was successful” criteria work on a run behavior command?

    Yikes. I hope that paragraph makes sense.


    I was able to follow you, I think. I think you are talking about the exit object in the behavior being referenced with the run behavior object. I wouldn’t use Last command was successful, I would use another exit object in the behavior calling the other behavior.

    It sounds like you may have a problem in that the behavior being called does too many things in this case (I can’t quite tell).

    Workflow software, Process software, Procedure software



    Basically I replaced a Check Mandatory behavior by calling an external behavior (which does a separate Check Mandatory behavior for each table column, because I wanted the warning message to be different for each column). It didn’t work because the external behavior would be called, and if any of the check mandatory behaviors failed, it would end the sub-behavior, but the one that called it would continue.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

© Copyright 2021. All rights reserved.
Contact Us