Controlling Component Visibility in Event Handlers
Components collection. To show or hide a component, set its Visible property to true or false in the appropriate event handler. For field-level visibility, target the component by its Name property as defined in the Form Designer.
For tab visibility, reference the TabPage component. For grid column visibility, access the grid's column collection. Always place visibility logic in StdObjectLoaded so it re-evaluates each time the user navigates to a different record.
- Hide a field: ThisForm.Components["txtApproverNotes"].Visible = false;
- Show a tab: ThisForm.Components["tabManufacturing"].Visible = (itemType == "M");
- Toggle grid column: ThisForm.Components["gridLines"].Columns["DiscountPct"].Visible = showDiscounts;
- Show/hide a group box: ThisForm.Components["grpShippingDetails"].Visible = (status != "Draft");
- Always use StdObjectLoaded for record-dependent visibility to handle navigation correctly
Multi-Condition Visibility Patterns
Complex forms often require visibility rules that depend on multiple field values, user roles, or external data. Implement a visibility rules engine by defining conditions as a configuration structure rather than hard-coding each rule. Create a function that accepts a list of component names and their visibility conditions, then evaluates all rules in a single pass during StdObjectLoaded.
This pattern scales much better than writing individual if-statements for every field and makes it easy to adjust rules without modifying the script logic.
- Rule-based visibility: var rules = new Dictionary<string, Func<bool>> { {"txtApproval", () => status == "Pending"} };
- Apply all rules: foreach (var rule in rules) { ThisForm.Components[rule.Key].Visible = rule.Value(); }
- Role-based visibility: check ThisForm.ActiveUserGroups.Contains("Managers") for role-dependent fields
- Cascading visibility: when parent field is hidden, automatically hide all dependent child fields
- External data visibility: load a configuration IDO to drive visibility rules without code changes
Performance Considerations for Visibility Scripts
Visibility scripts run on every record navigation, so performance matters for forms with many controlled components. Avoid calling IDO methods inside visibility logic for StdObjectLoaded; instead, cache the required data during StdFormLoaded and reference the cache during navigation. Batch component updates: set all Visible properties before the form renders rather than toggling them one at a time.
If a form has more than 20 visibility rules, consider restructuring the form into multiple simpler forms or using role-specific form variants.
- Cache lookup data in StdFormLoaded: load user permissions and configuration once per form session
- Batch updates: calculate all visibility values first, then apply them in a single loop
- Avoid IDO calls in StdObjectLoaded visibility logic: pre-load reference data during form initialization
- Measure handler execution time: StdObjectLoaded should complete in under 100ms for responsive navigation
- Consider form variants: create OrderForm_Standard and OrderForm_Advanced rather than 50+ visibility rules
Try it here, free
SyteLine Job and Order Status Codes Reference
Look up what Planned, Firm Planned, Released, Stopped, Complete and the other SyteLine status codes mean and how they behave in planning and shipping.
Netray AI agents generate optimized visibility scripts based on your business rules. Define conditions in plain language and get production-ready SyteLine form scripts instantly.