Background is an attribute used at the Form level to define the background color displayed on the screen. It helps differentiate forms visually, improve readability, and create a clearer interface for users while navigating through different layouts or contexts. By using suitable background colors, developers can create more organised, visually distinct, and user-friendly form interfaces. This attribute is applicable only in display mode.

Syntax

[Form : <Form Name>]

Background : <Color Name Formula>

Example

[Form: TSPL Form]

Background : @@SV_JOBWORKOUT

[System : formula]

SV_JOBWORKOUT : If $$InTrueColorMode then “White, SalesOrderVchClr” else “White, White”

Explanation

In this example, the Background attribute of the form TSPL Form is controlled dynamically using the system formula @@SV_JOBWORKOUT. The formula checks whether the application is running in True Color mode using $$InTrueColorMode. If the condition evaluates to true, the form background is displayed using the color combination “White, SalesOrderVchClr“; otherwise, it falls back to a plain white background. By defining the background through a formula, the form can automatically adapt its appearance based on the display environment, helping maintain better visual consistency and readability across different screen color modes.

Balance (aliases: Balancing, Closing Bal, and Closing Balance) is an attribute used at the Form level to control the insertion of balance or total lines within a form during print mode. The attribute specifies the closing line definition along with the balancing method to be applied. Based on the configured method such as Daily, Weekly, or Yearly, the form automatically inserts the corresponding balance line to summarise values for that specific period. This helps present periodic totals in a structured and meaningful manner without manually handling calculations or summary lines within the print layout, especially across balancing periods or page breaks.

Syntax

[Form : <Form Name>]

Balancing : <Closing Line Definition Name> : <Balancing Method>

Example

[Form: TSPL Balance Form]

Balancing : Closing Balance : @@BalancingBreak

[System: Formula]

BalancingBreak  : if $$IsSysNameEqual:Daily:##BalancingMethod then $().Date else +
if $$IsSysNameEqual:Weekly:##BalancingMethod then $$WeekEnd:$().Date else +
if $$IsSysNameEqual:Monthly:##BalancingMethod then $$MonthEnd:$().Date else +  $$FinYearEnd:$().Date:@@CmpStartDate

[Line: ClosingBalance]
:
:

Explanation

In this example, the form TSPL Balance Form uses the Balancing attribute to automatically insert balance lines within the print layout. The line definition Closing Balance specifies which line should be displayed as the balance line, while the formula @@BalancingBreak dynamically decides the balancing interval based on the selected balancing method. The formula evaluates whether the balancing should occur Daily, Weekly, Monthly, or Financial Year-wise and accordingly determines the break point using the transaction date. As the form is printed, balance lines are inserted automatically at the appropriate intervals, helping present periodic closing balances in a structured and readable manner without manually handling the calculations or layout breaks.

Objects in Tally are often dependent on other related objects for their complete meaning and usability. For example, a Voucher may depend on Ledgers, Cost Centres, Stock Items, or other master objects. Belongs To (alias:Family) is an attribute used in conjunction with the Full Object attribute to control whether such dependent objects should also be included during export. When both Belongs To and Full Object are set to Yes, the export process automatically includes all objects that are related to or required by the exported object, ensuring that the exported data remains complete and contextually valid. By default, the attribute is set to No, in which case only the selected objects are exported and their dependencies are excluded unless explicitly enabled. This attribute is particularly useful when exporting data for migration, synchronization, or integration scenarios where the exported objects must retain all their associated relationships and dependencies.

Syntax

[Form : <Form Name>]

Belongs To : <Logical Expression>

Example

[Form: TSPLXML Get CollObjSpec]

Parts      : TSPLXML Get CollObjSpec, TSPLXML Data
Height     : 100% Screen
Width      : 100% Screen
FullObject : Yes
Belongs To : Yes

Explanation

In this example, the form TSPLXML Get CollObjSpec is configured with both FullObject : Yes and Belongs To : Yes. The FullObject attribute ensures that the complete object data, including all its storages and associated information, is exported rather than only the displayed values. The Belongs To attribute further extends this behavior by including all dependent objects associated with the exported object. As a result, when the form is exported, not only are the complete details of the selected objects included, but all related master and dependent objects required by them are also exported automatically. This ensures that the exported data remains complete, self-contained, and contextually valid, making it suitable for scenarios such as data migration, synchronization, backup, or integration where object relationships need to be preserved.

Bottom Button is an attribute used at the Form level to specify the list of button definitions that should appear at the bottom of the right-hand side button panel. These buttons provide quick access to actions relevant to the current form or report and become visible when the form is active on the screen. By controlling which buttons appear in this section, developers can expose only the most relevant commands for the current context, helping keep the interface organised, focused, and easier to navigate.

Syntax

[Form : <Form Name>]

Bottom Button : <Button/Key Name>

Example

[Form: TSPL Form]

Bottom Button: Report Config

[Button: Report Config]

    Key     : F12
Title   : $$LocaleString:”Configure”

Explanation

In this example, the form TSPL Form uses the Bottom Button attribute to display the button Report Config at the bottom section of the right-hand side button panel. The actual behavior and appearance of the button are defined separately in the Button definition. Here, the button is assigned the shortcut key F12 and the title “Configure” using $$LocaleString, allowing the displayed text to support localisation. As a result, users can quickly access the report configuration option either by selecting the button from the panel or by directly using the F12 shortcut key while the form is active.

Bottom Part is an attribute used at the Form level to specify the list of Part definitions that should appear at the bottom section of the form. It is commonly used to display important information such as summaries, totals, declarations, signatures, or status-related details in a dedicated area separated from the main content. This helps create a more structured and organised layout, especially when the main content is scrollable or dynamically repeated. In print mode, the Bottom Part is printed at the bottom of the last page, making it useful for displaying final totals, notes, or concluding information in reports and documents.

Syntax

[Form : <Form Name>]

Bottom Part : <Part Definition Name>

Example

[Form: TSPL Form]

Bottom Part : TSPL Summary Part

[Part: TSPL Summary Part]

Lines : TSPL Summary Line

Explanation

In this example, the form TSPL Form uses the Bottom Part attribute to place the part TSPL Summary Part at the bottom section of the form. The part further contains the line TSPL Summary Line, which defines the actual content to be displayed in that area. This arrangement helps separate summary or concluding information from the main form content, making the layout more structured and easier to read. In print mode, this bottom part would appear at the bottom of the last page of the printed output.

Button (alias: Top Button) is an attribute used at the Form level to specify the list of button or key definitions that should appear in the top section of the right-hand side button panel. These buttons provide quick access to actions relevant to the current form or report and become active when the form is displayed on the screen. By controlling which buttons appear in this section, developers can expose only the most relevant commands for the current context, helping keep the interface organised, focused, and easier to navigate.

Syntax

[Form : <Form Name>]

Button : <Button Name1>, <Button Name2>, …

Example

[Form: TSPL Form]

Button : TSPL Add Btn, TSPL Delete Btn

[Button: TSPL Add Btn]

Title : “Add”
Key : F4
Action: Create

[Button: TSPL Delete Btn]

Title : “Delete”
Key : F8
Action: Delete

Explanation

In this example, the form TSPL Form uses the Button attribute to activate two buttons TSPL Add Btn and TSPL Delete Btn in the top section of the right-hand side button panel whenever the form is displayed. Each button is defined separately with its own title, shortcut key, and action. The TSPL Add Btn button displays the title “Add” and is triggered using the F4 key to perform the Create action, while the TSPL Delete Btn button displays the title “Delete” and uses the F8 key to execute the Delete action. This setup provides users with quick and context-specific actions directly from the form interface.

Different forms within a report may require visual distinction to improve readability and help users focus on important information. Color is an attribute used at the Form level to define the text color displayed on the screen. The specified color is applied to the text of all fields within the form, helping maintain a consistent visual appearance across the entire layout. However, this setting can be overridden at the Field level whenever a specific field requires a different color for emphasis, highlighting, or contextual display. By using suitable text colors, developers can improve clarity, readability, and the overall visual structure of the interface during display mode.

Syntax

[Form : <Form Name>]

Color : <Color Name>

Example

[Form : TSPL Form]

Color : Red

Explanation

In this example, Color : Red is defined at the Form level for TSPL Form. As a result, the text displayed in all fields within the form appears in red by default. This helps maintain a consistent visual appearance across the form without specifying the color individually for each field.

Before saving or accepting a form, users are usually shown a confirmation query to verify the action they are about to perform. Confirm Text (alias: Query Text) is an attribute used at the Form level to define the title displayed in this confirmation query during form acceptance. The attribute accepts a string expression, allowing the confirmation message to be displayed dynamically based on the context or requirement. By providing a meaningful and context-specific confirmation title, developers can make the prompt clearer to users and help reduce accidental confirmations or unintended actions.

Syntax

[Form: <Form Name>]

Confirm Text : <String Expression>

Example

[Form: TSPL Form]

Full width     : No
Full height    : No
Width          : 65% Screen
Confirm Text   : $$LocaleString:”Export ?”

Explanation

In this example, the Confirm Text attribute is used in TSPL Form to define the title displayed in the confirmation query when the form is accepted. The expression $$LocaleString:”Export ?” ensures that the displayed text supports localisation. As a result, when the user proceeds with the form acceptance, a confirmation query displaying the message “Export ?” appears, clearly indicating that confirmation is required before continuing with the export action.

Syntax

[Form: <Form Name>]

Control : <System Formula> : <Logical Condition>

Where,

    System Formula should evaluate to a string that would display in the message box

Example

[Form: TSPL Form]

Parts   : TSPL Part
Control : NonEmptyField : NOT $$IsEmpty: ##SVUserInput

[System : Formula]

NonEmptyField : “The field cannot be left empty”

Explanation

In this example, the Control attribute is used at the Form level to ensure that the value stored in ##SVUserInput is not left empty before the form is accepted. The condition NOT $$IsEmpty:##SVUserInput is evaluated during form save. If the value is empty, the condition returns False, the message “The field cannot be left empty” defined through the system formula NonEmptyField is displayed to the user, and the form is prevented from being saved until a valid value is entered.

Certain validations require more than just displaying a plain error message to the user. In some cases, users may need additional guidance, multiple choices, confirmations, or a more interactive way to respond before proceeding further. Control Ex is an attribute used at the Form level to apply validation logic through an extended query box instead of a simple message prompt. This allows developers to design richer and more customised query interactions based on the validation requirement. When the specified condition evaluates to False, the extended query box is displayed and the form action is halted until the user responds appropriately.

When both Control and Control Ex are specified at the Form level, Control executes first. If the Control validation itself fails, the form acceptance is blocked immediately and Control Ex is not executed. Control Ex is evaluated only after Control passes successfully. The execution order at the Form level is:

Control → Control Ex → Notify → Recompute Query

Syntax

[Form : <Form Name>]

Control Ex : <QueryBox Definition Name> : <Logical Condition> : <Variable Name>

Where,

<Query Box Definition Name> refers to a Query Box definition that defines the structure of the extended query dialog to be displayed to the user. The Query Box definition contains details such as the title, available options, shortcut keys, descriptions, and default selection behavior. This is a mandatory parameter
<Logical Condition> specifies the condition that determines whether the extended query box should be triggered during form acceptance. The query box appears only when this condition evaluates to True. This is a mandatory parameter.
<Variable Name> refers to a Number-type variable used to store the option selected by the user from the query box. This variable can later be used in events or logic to process the user’s selection. This parameter is optional.

Example

[Form: TSPL Form]

Parts      : TSPL Part
Control Ex : TSPL Confirm Query : NOT ##IsValidInput : vUserChoice
|
|

;; —————- Query Box Definition —————-

[Query Box: TSPL Confirm Query]

Title : “Confirm Action”
Query : Yes : “Proceed”
Query : No : “Cancel”

;; —————- Variable to store user choice —————-

[Variable: vUserChoice]

Type : Number

Explanation

In this example, the Control Ex attribute evaluates the condition NOT ##IsValidInput during form acceptance. If the condition evaluates to True, indicating that the input is not valid, the extended query box TSPL Confirm Query is displayed to the user instead of a simple validation message. The option selected by the user from the query box is stored in the Number-type variable vUserChoice, where the selected option index can later be used for further processing or decision-making logic. This demonstrates how Control Ex can be used to implement interactive validations that require user confirmation or choices before proceeding further.

Reports contains multiple lines and the cursor may not always need to start from the first visible line. Default is an attribute used to control the initial cursor focus within a report based on a specified logical condition. When the condition evaluates to True, the cursor is positioned on the corresponding line or section, helping guide the user directly to the most relevant area of the report. If the attribute or condition is not specified, the cursor focus automatically moves to the first non-fixed line in the report. This helps developers control the initial navigation flow and improve the user interaction experience within reports.

Syntax

[Form : <Form Name>]

Default : <String Expression>

Example

[Form: TSPL Monthly Summary]

Default : $$DateFrom <= $LastVoucherDate:Company:##SVCurrentCompany

Explanation

In this example, the Default attribute is used in the form TSPL Monthly Summary to control the initial cursor focus based on a logical condition. The condition checks whether $$DateFrom is less than or equal to the company’s last voucher date using:

$LastVoucherDate : Company : ##SVCurrentCompany

If the condition evaluates to True, the cursor focus is set accordingly for the report during display. If the condition does not evaluate to True, the report follows the default behavior and places the cursor on the first non-fixed line. This allows the report to dynamically control the starting focus based on the current reporting period or company data context.

When a form contains multiple editable fields, the cursor may not always need to start from the first field in the normal navigation flow. Default Field is an attribute used at the Form level to specify the field that should receive cursor focus by default when the form is opened or regenerated in edit mode. This allows developers to direct the user immediately to the most relevant field for data entry instead of relying on the natural field sequence.

The attribute can also work along with the Default Value attribute to automatically populate a field with a predefined value when a specified logical condition evaluates to True. This helps reduce manual input and improves usability by pre-filling commonly required values while still allowing developers to control exactly when such defaults should be applied.

Syntax

[Form : <Form Name>]

Default Field : <Field Name> [: <Logical Condition>]

Example

[Form: TSPL Form]

Parts         : TSPL Part
Default Field : TSPL Name Field : If $IsInvoice then ($$FilterCount:LedgerEntries:HasOppBankEntry > 0) else ($$FilterCount:AllLedgerEntries:HasOppBankEntry > 0)

Explanation

In this example, the Default Field attribute is used to control which field should receive cursor focus when TSPL Form is opened or regenerated in edit mode. The cursor is directed to TSPL Name Field only when the specified logical condition evaluates to True.

The condition checks whether the current voucher is an Invoice using $IsInvoice. If it is an Invoice, the system counts the filtered LedgerEntries using $$FilterCount; otherwise, it checks AllLedgerEntries. In both cases, the condition verifies whether any ledger entry satisfies the filter HasOppBankEntry. When the count is greater than zero, the cursor focus moves directly to TSPL Name Field. This allows the form to dynamically control cursor placement based on the voucher context and available ledger data.

Different printers may require different print formatting behaviors, especially in environments where Dot Matrix printers are still used for continuous stationery or pre-printed formats. DMP Mode is an attribute used to specify the Dot Matrix printing mode that should be applied during printing. This attribute becomes effective only when Dot Matrix printing is active and is ignored for other print modes such as Neat mode.

When specified at the Form level, the selected DMP printing mode is automatically applied to all Parts, Lines, and Fields within the form. However, if different printing behavior is required only for specific sections, the attribute can also be defined individually at the Part, Line, or Field level. By using DMP Mode, developers can control how content is aligned and printed specifically for Dot Matrix printer requirements and stationery formats.

Syntax

[Form : <Form Name>]

DMPMode : <Mode Keyword>

Where,

<Mode Keyword> specifies the Dot Matrix printing mode that should be applied while printing the form. This attribute is effective only when Dot Matrix printing is enabled and is ignored for other print modes such as Neat mode.

Permissible mode keywords are:

• Draft – Prints content in high-speed mode where each character and line is printed only once. This provides the fastest printing performance but with lower print quality. It is generally used where speed is more important than appearance.
• NLQ (Near Letter Quality) – Prints using multiple carriage passes and higher dot density to produce clearer and sharper output, similar to typewriter-quality printing. This mode provides better readability but prints slower compared to Draft mode.
• Condensed – Prints text in compressed mode so that more characters fit within the same horizontal space. This is useful when larger amounts of content need to fit within limited paper width or pre-printed stationery layouts.
• Normal
  
  Prints using the standard Dot Matrix print style with normal spacing and character appearance. This is the default print mode used for regular printing requirements.
• Bold
  
  Prints characters with increased thickness or darker impression, making the text stand out more clearly on the printed output. Commonly used for headings, totals, or important values.
• Italics
  
  Prints text in a slanted style to visually differentiate specific content such as remarks, notes, or highlighted information.
• Underline
  
  Prints a line beneath the text, helping emphasize important fields, labels, or values in the printed document.
• Enlarged
  
  Prints characters in an enlarged size, making the text appear bigger and more prominent. Often used for titles or important headings in printed output.
• DoubleLine
  
  Prints text with a double-line effect to provide stronger emphasis and visibility for important sections or highlighted content.

Example

[Form: TSPL Print Form]

Parts   : TSPL Print Part
DMPMode : Condensed

Explanation

In this example, the form TSPL Print Form uses the DMPMode : Condensed attribute to apply condensed Dot Matrix printing mode to the entire form during printing. As a result, the content printed from TSPL Print Part appears in compressed format, allowing more characters to fit within the same horizontal space on the paper. This is especially useful for wide reports, continuous stationery, or pre-printed formats where space optimisation is important while printing through Dot Matrix printers.

During multi-printing or batch printing, certain forms may not always contain relevant data and printing blank or unnecessary forms can make the output cluttered and difficult to manage. Empty (aliases: Empty If, Empty On) is an attribute used to decide whether a form should be printed or skipped based on a specified logical condition. When the condition evaluates to True, the form is treated as empty by removing or suppressing its content during print processing, resulting in nothing being printed for that form. This attribute is especially useful in scenarios where forms should appear only when meaningful data, transactions, or values are available, helping avoid unnecessary blank pages and keeping printed reports cleaner and more relevant.

Syntax

[Form : <Form Name>]

Empty : <Logical Condition>

Example

[Form: TSPL Print Form]

Parts : TSPL Print Part
Empty : $$InDraftMode

Explanation

In this example, the form TSPL Print Form uses the Empty attribute with the condition $$InDraftMode. When the form is processed for printing and the condition evaluates to True, the form content is treated as empty and suppressed during print processing. As a result, TSPL Print Part is not printed in Draft mode. This allows developers to selectively skip forms or sections during specific print scenarios without manually modifying the print layout.

Excel exports may contain values of different lengths, and fixed column widths can make some data appear truncated or difficult to read. Excel AutoFit is an attribute used during Excel export to control whether Excel should automatically adjust column widths and row heights based on the exported content. When set to Yes, Excel resizes columns and rows according to the cell content, making the exported sheet cleaner, properly aligned, and easier to read without manual resizing. When disabled, the exported sheet retains fixed sizing and layout formatting.

Syntax

[Form : <Form Name>]

Excel AutoFit : <Logical Condition>

Example

[Form: TSPL Excel Export Form]

Parts         : TSPL Excel Export Part
Excel AutoFit : Yes

Explanation

In this example, the form TSPL Excel Export Form uses the attribute Excel AutoFit : Yes to enable Excel’s AutoFit behavior during export. As a result, when the data from TSPL Excel Export Part is exported, Excel automatically adjusts the column widths and row heights based on the content written into the cells. This ensures that the exported data is immediately readable without requiring users to manually resize columns after opening the Excel sheet.

Exported reports may sometimes require a fixed layout where formatting, alignment, spacing, and presentation should remain exactly as designed in the form. Excel No Format is an attribute used at the Form level to prevent any formatting changes during Excel export. When this attribute is enabled, the exported output retains the layout and formatting structure defined in the form without allowing Excel-specific formatting adjustments. Developers typically use this attribute in scenarios where the exported sheet is intended to preserve a predefined presentation format or template consistency during export.

Syntax

[Form : <Form Name>]

Excel No Format : <Logical Value>

Example

[Form: TSPL Excel Export Form]

Parts           : TSPL Excel Export Part
Excel No Format : Yes

Explanation

In this example, the form TSPL Excel Export Form uses the attribute Excel No Format : Yes to preserve the formatting and layout defined in the form during Excel export. As a result, the content exported from TSPL Excel Export Part retains its original structure, spacing, and presentation without allowing Excel to apply additional formatting adjustments. This helps maintain a consistent and controlled export layout exactly as designed in the form.

Excel exports may sometimes require multiple worksheets to organise different categories of data within the same workbook. Excel Sheet Name is an attribute used during Excel export to specify the name of the worksheet that should be created in the exported workbook. Providing meaningful sheet names helps users easily identify the content present in each worksheet, especially when multiple sheets are generated during export.

The first parameter accepts an expression that evaluates to a string, which becomes the worksheet name. The optional second parameter accepts a logical condition. When this condition evaluates to True, a new worksheet with the specified name is created during export. This allows developers to dynamically generate and organise Excel sheets based on data context or export requirements.

Syntax

[Form : <Form Name>]

Excel Sheet Name : <String expression> [: <Logical Condition>]

Where,

<String expression> evaluates to a string that would be assigned as Sheet Name. This is a mandatory parameter.

<Logical Condition> is a condition that determines whether a new worksheet with the specified sheet name should be created during Excel export. This is an optional parameter.

Example

[Form: TSPL Excel Export Form]

Parts            : TSPL Excel Export Part
Excel Sheet Name : #LedgerName

Explanation

In this example, the Excel Sheet Name attribute is used to dynamically assign the worksheet name during Excel export. The expression #LedgerName evaluates to the current ledger name, and the exported worksheet is created using that value as the sheet name. This allows the workbook to contain clearly identified sheets based on the ledger context during export.

Some reports may need to temporarily collect user input such as filters, selections, column names, or parameters and pass those values back to the parent report for further processing. Output (alias: Export) is an attribute used to pass the value entered in a field from the current triggered report back to the parent report once the current form is accepted. This helps developers design interactive report flows where one report gathers input from the user and the calling report uses that value dynamically.

This attribute is especially useful in scenarios such as Multi-column reports, Auto Column creation, or Add New Column functionality, where values entered in a child report need to be returned to the parent report to dynamically generate or modify report columns during runtime.

Syntax

[Form : <Form Name>]

Output: <Field Name>

Example

[Form: TSPLAutoColumns1]

  Parts       : TSPLAutoColumnsPart
  Output      : TSPLAutoColumns
Option      : Small Size Form

;; Output Attribute at Form Definition is used to return a Field value

;; to the calling Report

              |

           |

[Field: TSPLAutoColumns]

Use         : Short Name Field
Invisible   : Yes
Set as      : $$Table:TSPLSelectAuto:$VarName
Set always  : Yes
Skip        : Yes

In this example, the Output attribute at the Form level is used to return the value of the field TSPLAutoColumns back to the calling report once the form is accepted. The field TSPLAutoColumns itself is kept invisible and is automatically populated using the expression:

$$Table:TSPLSelectAuto:$VarName

This expression retrieves the VarName method value from the object selected in the previous field TSPLSelectAuto. Since Set Always : Yes is specified, the field value is continuously updated whenever the selection changes.

When the form is accepted, the value stored in TSPLAutoColumns is passed back to the parent report through the Output attribute. This returned value is then used by the calling report to dynamically control auto-column generation behavior.

A report may sometimes contain multiple forms, where each form is designed to work with a different object context. In such cases, the methods required by one form may belong to a completely different object than the methods required by another form. Fetch Object is an attribute used to explicitly specify which object should be fetched for a particular form. This ensures that the methods and values referenced within the form are evaluated from the correct object context during rendering.

Developers typically use this attribute in reports containing multiple optional forms or layouts where each form needs data from different object types. By controlling the object context explicitly, Fetch Object helps ensure accurate method evaluation and proper data binding for each form independently.

Syntax

[Form : <Form Name>]

Fetch Object : <Object Type> : <Object Identifier Expression> : <Method Name List>

Example

[Form: TSPL Ledger Form]

Parts        : TSPL Ledger Part
Fetch Object : Ledger : $LedgerName : Name, ClosingBalance

Explanation

In this example, the form TSPL Ledger Form uses the Fetch Object attribute to explicitly fetch the Ledger object using the value of $LedgerName. While rendering the form, the methods Name and ClosingBalance are fetched from the specified Ledger object context. This ensures that all references to these methods within TSPL Ledger Form are evaluated using the selected Ledger object, allowing the form to correctly display ledger-specific information such as the ledger name and its closing balance.

Some reports are designed to act as trigger screens, selection windows, or intermediate interfaces before the actual data report is displayed. In such cases, the form is expected to behave like a complete working screen rather than a small dialog window. Full Height is an attribute used to make the form occupy the entire height of the screen. When set to Yes, the form automatically stretches to 100% of the available screen height regardless of the amount of content present within it.

Developers typically use this attribute in reports such as selection reports, trigger reports, or navigation screens where a larger working area improves usability and allows users to interact more comfortably before proceeding to the main report.

Syntax

[Form : <Form Name>]

Full Height : <Logical Value>

Example

[Form: TSPL Full Screen Form]

Parts       : TSPL Part
Full Height : Yes

Explanation

In this example, the form TSPL Full Screen Form uses the attribute Full Height : Yes to occupy the complete height of the screen during display. As a result, the form stretches vertically to use the full available screen space instead of adjusting only to the height required by its content. This helps the form behave more like a full-screen working interface rather than a small dialog or partial window.

Reports may sometimes need to export not just the displayed values, but the complete underlying object data associated with the report. Full Object is an attribute used to control whether the entire object storage should be exported along with the report output. When set to Yes, the export includes all object storages related to the report, including User Defined Fields (UDFs). This ensures that the exported data contains the complete object context instead of only the visible or currently displayed values. Attribute Belongs To aids in exporting entire detail object.

Developers typically use this attribute in scenarios where the exported data is expected to support further processing, data migration, integration, or complete object reconstruction outside the report environment. The default value of this attribute is No.

Syntax

[Form : <Form Name>]

Full Object : <Logical Expression>

Example

[Form: TSPL Ledger Export Form]

Parts       : TSPL Ledger Part
Full Object : Yes

Explanation

In this example, the form TSPL Ledger Export Form uses the attribute Full Object : Yes to export the complete object data associated with the report. As a result, while exporting data from TSPL Ledger Part, the export includes all object storages related to the current object context, including any User Defined Fields (UDFs), instead of exporting only the displayed values. This helps preserve the complete object information during export for further processing or integration purposes.

Some reports are designed to act as trigger screens, selection windows, or intermediate interfaces before the actual data report is displayed. In such cases, the form is expected to behave like a complete working screen rather than a small dialog window. Full Width is an attribute used to make the form occupy the entire width of the screen. When set to Yes, the form automatically stretches horizontally to 100% of the available screen width regardless of the amount of content present within it.

Developers typically use this attribute in reports such as selection reports, trigger reports, or navigation screens where a wider working area improves usability and allows users to interact more comfortably before proceeding to the main report.

Syntax

[Form : <Form Name>]

Full Width : <Logical Value>

Example

[Form: TSPL Full Screen Form]

Parts      : TSPL Part
Full Width : Yes

Explanation

In this example, the form TSPL Full Screen Form uses the attribute Full Width : Yes to occupy the complete width of the screen during display. As a result, the form stretches horizontally to use the full available screen space instead of limiting itself to a fixed or partial width. This helps the form behave more like a full-screen working interface rather than a small dialog or selection window.

When a query box is displayed, it is often important to draw the user’s attention specifically to the query and reduce distractions from the background screen. Gray Back (alias: Grey Back) is an attribute used to control whether the screen behind the query box should be greyed out before displaying the query. When set to Yes, the background screen is dimmed, making the query box stand out more clearly and helping users focus on the action or decision required. When set to No, the screen behind the query box remains unchanged.

Developers typically use this attribute for important confirmations, validations, or interactive queries where user attention should remain focused on the query box. The default value of this attribute is False.

Syntax

[Form : <Form Name>]

Gray Back : <Logical Value>

Example

[Form: TSPL Query Form]

Parts     : TSPL Query Part
Gray Back : Yes

Explanation

In this example, the form TSPL Query Form uses the attribute Gray Back : Yes to grey out the background screen whenever the query form is displayed. As a result, the rest of the screen appears dimmed while TSPL Query Part remains highlighted and active, helping focus the user’s attention on the query interaction instead of the background content.

Some forms may require a controlled and fixed vertical size instead of automatically occupying the entire screen height. Height is an attribute used to explicitly define the vertical size of a form. Developers can specify the height using any measurement unit supported by TDL, such as millimeters (mm), inches, or percentage of the screen or page.

This attribute is useful when forms need to behave like dialog windows, pop-ups, selection screens, or specially aligned print layouts where precise control over vertical space is important for maintaining the intended interface or print structure.

Syntax

[Form : <Form Name>]

Height : <Unit of Measure>

Example

[Form: TSPL Custom Height Form]

Parts    : TSPL Part
Height   : 60% Screen
Option   : TSPL Custom Height Form Print : $$InPrintMode

[!Form : TSPL Custom Height Form Print]

Height : 60% Page

Explanation

In this example, the form TSPL Custom Height Form uses the Height attribute to control the vertical size of the form differently for display mode and print mode. During normal display, Height : 60% Screen makes the form occupy 60% of the available screen height. The Option attribute then activates the optional form TSPL Custom Height Form Print when the system enters print mode using the condition $$InPrintMode. In the optional print form, Height : 60% Page changes the form height to 60% of the printable page height instead of the screen height. This demonstrates how the Height attribute can be adjusted dynamically based on display and print contexts using different measurement references.

Forms may not always need to appear at the default centered position on the screen. Depending on the interface design or layout requirement, a form may need to be aligned towards the left, center, or right side of the available space. Horizontal Align (alias: Horizontal Alignment) is an attribute used to control the horizontal positioning of a form on the screen. It determines how the form is aligned across the available width during display.

By default, forms are horizontally center-aligned, providing a balanced appearance on the screen. Developers typically use this attribute when designing dialog windows, side panels, selection screens, or custom layouts where the form placement needs to match a specific visual structure or interaction flow.

Syntax

[Form : <Form Name>]

Horizontal Align : <Alignment Keywords>

Where alignment keywords can be,

• Left / Top — Aligns the form towards the left side of the screen.
• Right / Bottom — Aligns the form towards the right side of the screen.
• Centre — Aligns the form at the center of the screen.

Example

[Form: TSPL Align Form]

Parts            : TSPL Part
Width            : 40% Screen
Horizontal Align : Left

Explanation

In this example, the form TSPL Align Form uses Width : 40% Screen to occupy only 40% of the available screen width. The attribute Horizontal Align : Left then positions the form towards the left side of the screen instead of the default center alignment. This helps the form behave more like a side-aligned panel or compact working window rather than a centrally placed dialog.

Forms may sometimes need to be positioned at specific vertical locations on the screen instead of always appearing at the default center position. Vertical Align (alias: Vertical Alignment) is an attribute used to control the vertical positioning of a form on the screen. It determines whether the form should appear aligned towards the top, center, or bottom of the available screen height during display.

By default, forms are vertically center-aligned, giving a balanced appearance on the screen. Developers typically use this attribute while designing dialog windows, pop-up screens, compact forms, or custom layouts where the vertical placement of the form is important for the overall interface structure or user interaction flow.

Syntax

[Form : <Form Name>]

Vertical Align : <Alignment Keywords>

Where alignment keywords can be,

• Top / Left — Aligns the form towards the top of the screen.
• Bottom / Right — Aligns the form towards the bottom of the screen.
• Centre — Aligns the form at the vertical center of the screen.

Example

[Form: TSPL Vertical Align Form]

Parts          : TSPL Vertical Align Part
Vertical Align : Top

Explanation

In this example, the form TSPL Vertical Align Form uses the attribute Vertical Align : Top to position the form towards the top of the screen during display. As a result, the form containing TSPL Vertical Align Part appears aligned near the upper portion of the available screen space instead of the default vertically centered position. This helps in designing forms that need to behave like top-positioned panels, compact selection windows, or header-style interfaces.

Document templates contain placeholders or tokens that need to be replaced with actual data during print or export. JSON Map (aliases: MAP, XML Map) is an attribute used to map template tokens to TDL expressions. During print or export, these expressions are evaluated and their resulting values automatically replace the corresponding tokens in the template. In simple terms, it maps tokens in the document template to expressions whose evaluated values replace the tokens during runtime.

This allows developers to generate dynamic JSON or template-based output where placeholders are populated with live data from the current object or report context. JSON Map is especially useful while generating structured documents, integrations, export files, or external templates where dynamic value insertion is required. This attribute is generally used along with the Resource attribute at the Form level and forms part of the Productivity Suite capabilities in TDL.

Syntax

[Form: <Form Name>]

JSON Map: <Map Name>: <Expression >[:<Collection Name>]

Example

[Form: TSPLInvFrm]

Resource : TSPLInvoiceWord
Map      : BasicSDN    : @@DelNoteNo
Map      : CompanyName : ##SVCurrentCompany
Map      : Rate        : $Rate               : Inventory Entries

[Resource: TSPLInvoiceWord]

Source : “D:WorkInvoiceWord.xml”

;;It is the word document saved as .xml(WORDXML)

Resource Type : Word XML

[System: Formula]

DelNoteNo : $BasicShipDeliveryNote

Explanation

In this example, the form TSPLInvFrm uses the Resource attribute to associate the external Word XML template TSPLInvoiceWord with the form. The resource definition points to the file WorkInvoiceWord.xml, which is a Word document saved in XML format. During print or export, the Map attributes are used to replace template tokens in this document with dynamically evaluated values from TDL.

• Map : BasicSDN : @@DelNoteNo replaces the token BasicSDN in the template with the value returned by the system formula @@DelNoteNo.
• Map : CompanyName : ##SVCurrentCompany replaces the token CompanyName with the current company name.
• Map : Rate : $Rate : Inventory Entries replaces the token Rate with the value of the method $Rate fetched from the Inventory Entries object context.

As the document is generated, all mapped tokens in the Word XML template are automatically replaced with live data from the current report or object context, resulting in a dynamically generated document output.

Structured JSON or XML exports requires meaningful parent tags to organise and group related data properly within the exported output. JSON Tag (alias: XML Tag) is an attribute used to specify the tag name for a form in the exported JSON or XML file. When this attribute is defined, the entire form content is wrapped within the specified tag, helping create a clear and structured export hierarchy. If the attribute is not specified, no separate form-level tag is generated and only the inner content appears in the export output.

Developers typically use this attribute when generating structured integration files, template-based exports, or hierarchical JSON/XML documents where proper tagging and grouping of form data is important.

Syntax

[Form: <Form Name>]

JSON Tag : <String Expression>

Example

[Form: TSPL Smp ResponseRpt]

Parts: TSPL Smp ResponseRpt
XMLTag: “Custom Response Form”

Explanation

In this example, the form TSPL Smp ResponseRpt uses the attribute XMLTag : “Custom Response Form” to specify the tag name that should represent the form in the exported XML or JSON output. As a result, all the content generated from TSPL Smp ResponseRpt is wrapped within the tag “Custom Response Form” during export, creating a structured parent node for the form data in the generated output.

Different forms may require different keyboard interactions depending on the actions users are expected to perform within that screen. Key (alias: Keys) is an attribute used at the Form level to specify the list of key definitions that should remain active while the form is displayed. It controls which keyboard shortcuts are available for that form, allowing developers to enable only the relevant key actions based on the current context.

By managing active keys at the Form level, developers can create more focused and controlled user interactions, prevent unnecessary shortcuts from interfering with the workflow, and ensure that users have quick access only to the actions applicable within that form.

Syntax

[Form : <Form Name>]

Key : <Key Name>

Example

[Form: TSPL Keys Form]

Parts : TSPL Part
Keys  : TSPL Help Key
|
|

;; ——– Key Definitions ——–

[Key: TSPL Help Key]

Key    : F1
Action : Display : Help

Explanation

In this example, the form TSPL Keys Form uses the Keys attribute to activate the key definition TSPL Help Key while the form is displayed. The key definition assigns the shortcut key F1 to the action Display : Help. As a result, when the user presses F1 within this form, the Help screen is displayed. This demonstrates how the Keys attribute controls which keyboard shortcuts remain active for a specific form context.

Forms may sometimes need to display multiple sections arranged vertically instead of presenting all content in a single continuous layout. Top Part (aliases: Left Part, Left Parts, Part, Parts, Top Parts) is an attribute used at the Form level to specify the list of Part definitions that should appear from the top section of the form layout. It helps developers organise supporting or navigation-related content such as menus, summaries, filters, or selection panels separately from the main content area.

By assigning Parts within the form layout, forms can be divided into structured visual sections, resulting in cleaner layouts, improved navigation, and better overall usability.

Syntax

[Form : <Form Name>]

Top Part : <Part Name>

Example

[Form: TSPL Left Layout Form]

Left Part : TSPL Menu Part
Parts     : TSPL Main Part

Explanation

In this example, the form TSPL Left Layout Form contains two Parts: TSPL Menu Part and TSPL Main Part. Although TSPL Menu Part is specified using the attribute Left Part, at the Form level this attribute behaves as an alias of Top Part. Since Parts within a form are arranged vertically by default, TSPL Menu Part is placed at the top of the form layout. Similarly, the attribute Parts is also an alias of Top Part, so TSPL Main Part is positioned below TSPL Menu Part. As a result, both Parts appear one below the other in vertical sequence within the form layout.

Complex calculations or conditional expressions used only within a specific form do not always need to be declared globally. Local Formula is an attribute used at the Form level to define formulas whose scope remains limited only to that form. These formulas can then be referenced anywhere within the form definition without creating global system-level formulas.

Developers typically use Local Formula to keep form-specific logic self-contained, reduce unnecessary global definitions, and improve maintainability by keeping temporary calculations or conditional expressions closer to the form where they are actually used.

Syntax

[Form : <Form Name>]

Local Formula : <Formula Name> : <Expression>

Example

[Variable: TSPLAmountValue]

Type : Number

[Report: TSPL Local Formula Report]

Form     : TSPL Local Formula Form
Variable : TSPLAmountValue
Set      : TSPLAmountValue   : 15000

[Form: TSPL Local Formula Form]

Parts         : TSPL LF Part

;; Local formula defined within form scope

Local Formula : IsHighValue                 : ##TSPLAmountValue > 10000
Option        : TSPL Local Formula Form Opt : @IsHighValue

[!Form: TSPL Local Formula Form Opt]

Background: Red

Explanation

In this example, the report TSPL Local Formula Report initializes the variable TSPLAmountValue with the value 15000 and opens the form TSPL Local Formula Form. Within the form, a local formula named IsHighValue is defined using the expression ##TSPLAmountValue > 10000. Since the variable value is greater than 10000, the formula evaluates to True.

The Option attribute then uses this local formula through @IsHighValue to conditionally activate the optional form TSPL Local Formula Form Opt. As a result, the optional form gets applied and the form background changes to Red. This demonstrates how Local Formula can be used within a form to create reusable conditional logic that controls form behavior or appearance without defining formulas globally.

Some forms may contain very little content, causing the form size to shrink and affect the overall layout consistency or visual balance of the interface. Min Height is an attribute used to define the minimum vertical height that a form should occupy. Even if the actual content requires less space, the form will not reduce below the specified minimum height.

This attribute supports all measurement units supported by TDL, such as mm, inch, and percentage of screen or page, giving developers precise control over the minimum vertical size of the form layout. Min Height is specifically introduced for Print Customisation capability, where maintaining consistent layout structure, spacing, and alignment is important in printed invoice and document formats.

Syntax

[Form : <Form Name>]

Min Height : <Value> <Unit>

Example

[Form: TSPL Min Height Form]

Parts      : TSPL Part
Min Height : 50% Screen

Explanation

In this example, the form TSPL Min Height Form uses the attribute Min Height : 50% Screen to ensure that the form occupies at least 50% of the available screen height. Even if the content inside TSPL Part requires less vertical space, the form height will not shrink below this minimum value. This helps maintain consistent spacing and layout structure, especially in print customisation scenarios where fixed alignment and presentation are important.

Some forms may contain very little content, causing the form width to shrink and affect the overall layout consistency or alignment in printed documents. Min Width is an attribute used to define the minimum horizontal width that a form should occupy. Even if the actual content requires less space, the form will not reduce below the specified minimum width.

This attribute supports all measurement units supported by TDL, such as mm, inch, and percentage of screen or page, giving developers precise control over the minimum horizontal size of the form layout. Min Width is specifically introduced for Print Customisation capability, where maintaining consistent alignment, spacing, and presentation is important in printed invoice and document formats.

Syntax

[Form : <Form Name>]

Min Width : <Value> <Unit>

Example

[Form: TSPL Min Width Form]

Parts     : TSPL Part
Min Width : 60% Screen

Explanation

In this example, the form TSPL Min Width Form uses the attribute Min Width : 60% Screen to ensure that the form occupies at least 60% of the available screen width. Even if the content inside TSPL Part requires less horizontal space, the form width will not shrink below this minimum value. This helps maintain consistent alignment, spacing, and layout structure, especially in print customisation scenarios where controlled presentation and formatting are important.

Some forms are used only for viewing information, modifying variables, or changing report settings where asking for save confirmation every time can interrupt the user flow unnecessarily. No Confirm (alias: No Confirmation) is an attribute used to control whether the system should display a confirmation prompt before saving or exiting a form. Normally, the system asks for confirmation to prevent accidental save or quit actions. When No Confirm is set to Yes, the confirmation screen is skipped and the action proceeds directly.

This attribute is commonly used in forms meant for viewing purposes, report configuration screens, filter or parameter selection forms, and settings-related reports such as Balance Sheet configuration screens, where faster and smoother interaction is preferred over explicit confirmation prompts.

Syntax

[Form : <Form Name>]

No Confirm : <Logical Value>

Example

[Form: TSPL Quick Save Form]

Parts      : TSPL Part
No Confirm : Yes

Explanation

In this example, the form TSPL Quick Save Form uses the attribute No Confirm : Yes to skip the confirmation prompt normally shown during form acceptance or exit. As a result, when the user saves or closes the form, the action proceeds directly without asking for additional confirmation. This helps create a faster and smoother interaction flow for forms where explicit confirmation is not required.

Some situations may require informing users about warnings, recommendations, or important conditions while they work with a form. Notify is an attribute used at the Form level to display a warning or informational message to the user based on a specified condition. When the condition evaluates to True, the specified message is shown to alert or guide the user about a particular situation or requirement.

This attribute is useful in scenarios where users need awareness or guidance during form interaction, such as highlighting unusual values, incomplete information, or important reminders through contextual notifications at the form level.

Syntax

[Form : <Form Name>]

Notify : <System Formula for Message> : <Logical Condition>

Example

[Form: TSPL Voucher Entry Form]

Parts  : TSPL Voucher Part
Notify : TSPLVchAmtWarnMsg : (@@TSPLCreateAmtWarn OR @@TSPLAlterAmtWarn)

|
|

[System: Formula]

TSPLVchAmtWarnMsg : “Voucher amount is above the recommended threshold”
TSPLCreateAmtWarn : ##SVIsCreate AND ##Amount > 50000
TSPLAlterAmtWarn  : ##SVIsAlter AND ##Amount > 75000

Explanation

In this example, the form TSPL Voucher Entry Form uses the Notify attribute to display a warning message based on voucher amount conditions. The notification message TSPLVchAmtWarnMsg displays the text “Voucher amount is above the recommended threshold” whenever either of the conditions @@TSPLCreateAmtWarn or @@TSPLAlterAmtWarn evaluates to True.The formula TSPLCreateAmtWarn checks whether the voucher is being created and the amount exceeds 50000, while TSPLAlterAmtWarn checks whether the voucher is being altered and the amount exceeds 75000. When either condition is satisfied, the warning message is displayed to notify the user about the high voucher amount during form interaction.

The ON keyword is used to define a list of actions that should be executed when a specific event occurs. It helps developers associate event-driven behavior with Forms by automatically triggering the required actions at the appropriate stage of form interaction, printing, exporting, or acceptance. This allows business logic, validations, processing, and follow-up operations to be executed in a structured and predictable manner whenever the specified event is triggered.

Events permissible at Form Level

Syntax

[Form : <Form Name>]

    ON : <Event Name> : <Logical Expression> : <Action > : <Action Parameters>

Example

[#Form: Payment Color]

On  : Form Accept : ##ProgConfigExport : CALL : TSPLSmpSCExportReport

Explanation

In this example, the ON keyword is used at the Form level to define an action that should execute when the Form Accept event occurs. The event is triggered when the form Payment Color is accepted or saved. The condition ##ProgConfigExport is evaluated first, and if it returns True, the action CALL : TSPL Smp SC Export Report is executed. As a result, the report or function TSPL Smp SC Export Report is triggered automatically after form acceptance. This demonstrates how the ON keyword can be used to associate specific actions with form events and execute additional processing dynamically based on conditions.

Reports that display transactions over balancing periods often require a clear starting reference before showing the entries belonging to that period. Opening Bal (alias: Opening Balance) is an attribute used to insert an opening balance line within a form. This attribute works in combination with the Balancing attribute, which defines how balances are grouped or calculated, such as daily, weekly, monthly, or yearly balancing.

When Opening Bal is enabled, the form automatically inserts an opening balance line at the beginning of each balancing period before displaying the related transaction details. This helps users clearly identify the starting balance for every balancing segment and improves readability in period-based reports and print layouts. The attribute is typically used together with the Closing Balance attribute, where the opening balance provides the starting value for a balancing period and the closing balance provides the ending value, giving users a complete view of balance movement within each balancing segment.

Syntax

[Form : <Form Name>]

   Opening Bal : <Opening Line Definition Name>

Example

[Form: TSPL Balance Form]

Parts        : TSPL Balance Part
Balancing    : Closing Balance : @@BalancingBreak
Opening Bal  : TSPL Opening Line

[Line: TSPL Opening Line]

 Fields : TSPL Opening Field

[Field: TSPL Opening Field]

Set As : “Carried Forward …”

Explanation

In this example, the form TSPL Balance Form uses the Balancing attribute to divide the report into balancing periods based on the formula @@BalancingBreak. The Opening Bal attribute then specifies TSPL Opening Line as the line that should be inserted at the beginning of each balancing period.

Whenever a new balancing segment starts, the line TSPL Opening Line is automatically displayed before the transaction details for that period. The field TSPL Opening Field within this line displays the text “Carried Forward …”, providing a visual indication of the opening balance carried into the current balancing period. This demonstrates how Opening Bal works together with Balancing to present a clear opening balance reference at the start of each balancing section in the report.

Reports may sometimes require a different form specifically for printing, separate from the form used for on-screen display. Print (alias: Output Config Report) is an attribute used to specify the form that should be used for printing. This allows developers to define a dedicated print layout with its own structure, formatting, and presentation requirements without affecting the display form used during report interaction.

By using a separate print form, the printed output can be tailored to business document requirements while keeping the on-screen report optimized for usability and navigation.

Syntax

[Form : <Form Name>]

    Print : <Report Name>

Example

;; This is display report form

[Form: TSPL Display Form]

Parts       : TSPL Display Part

;; Report that needs to be printed

Print : TSPL Print Report

|

|

;; ——– Print Report ——–

[Report: TSPL Print Report]

Form : TSPL Print Form

[Form: TSPL Print Form]

Parts : TSPL Print Part
|

|

Explanation

In this example, the form TSPL Display Form is used for normal on-screen display and contains the part TSPL Display Part. The attribute Print : TSPL Print Report specifies that when the report is printed, the system should use the report TSPL Print Report instead of the display form.

The report TSPL Print Report is associated with the form TSPL Print Form, which contains TSPL Print Part and defines the layout to be used for printing. As a result, users continue to interact with TSPL Display Form on the screen, while the printed output is generated using the dedicated print form TSPL Print Form. This demonstrates how the Print attribute allows the display layout and print layout to be designed independently to suit their respective purposes.

Printing or exporting data requires a predefined document structure so that the generated output follows a specific layout or format. Output Template is an attribute used to specify the template file that should be used during printing or exporting. The template defines how the output should be structured, formatted, and presented, allowing developers to generate standardized documents without modifying the report or form definitions themselves.

By associating a template file with the form, developers can control the appearance of printed or exported output independently of the report design. This is particularly useful when generating documents that must conform to predefined business formats, external templates, or integration requirements. Currently it is used for excel export templates.

Syntax

[Form : <Form Name>]

   Output Template : <Template File Name>

Example

[Form: TSPL Sales Export Form]

Parts           : TSPL Sales Part
Output Template : @@MSMEformOutputTemplateFile

[System: Formula]

MSMEform1OutputTemplateFile : ##MSMEForm1TemplateFilePath + “” + ##MSMEForm1TemplateFileName

Explanation

In this example, the form TSPL Sales Export Form uses the Output Template attribute to specify the template file that should be used during export or document generation. Instead of hardcoding the template path, the attribute references the formula @@MSMEformOutputTemplateFile, which dynamically evaluates the location of the template file.

The formula MSMEform1OutputTemplateFile constructs the complete file path by combining the template folder path stored in ##MSMEForm1TemplateFilePath with the template file name stored in ##MSMEForm1TemplateFileName. When the form is printed or exported, the generated path is used to locate and apply the corresponding output template. This allows the template file to be configured dynamically, making the solution more flexible and easier to maintain without modifying the form definition.

Printed reports often require certain information to appear consistently at the bottom and top of every page, such as declarations, totals, company information, report titles, or page numbers. Page Break is an attribute used to specify the Parts that should be treated as the Closing Part and Opening Part for each printed page. The Closing Part is rendered at the bottom of every page, while the Opening Part is rendered at the top of the subsequent page.

By defining these Parts, developers can create well-structured multi-page print layouts where important information is automatically repeated across pages, ensuring continuity, readability, and a professional document presentation throughout the printed report.

Do not confuse this attribute with Balancing, Opening Bal, or Closing Balance, which are used to insert balance-related lines within report data based on balancing periods. Page Break is purely a print-layout attribute used to control page headers and footers.

Syntax

[Form : <Form Name>

Page Break : <Footer / Closing Part Name> , <Header / Opening Part Name> [: <Logical Expression>]

Example

[Form: TSPL Print Form]

Parts      : TSPL Body Part
Page Break : TSPL Footer Part, TSPL Header Part

;; ——– Footer Part (End of Page) ——–

[Part: TSPL Footer Part]

Lines : TSPL Footer Line

[Line: TSPL Footer Line]

Fields : TSPL Footer Field

[Field: TSPL Footer Field]

Set As : “P.T.O”

;; ——– Header Part (New Page) ——–

[Part: TSPL Header Part]

Lines : TSPL Header Line

[Line: TSPL Header Line]

Fields : TSPL Header Field

[Field: TSPL Header Field]

 Set As : “Carried Forward”

;; ——– Body Part ——–

[Part: TSPL Body Part]

Lines : TSPL Body Line

[Line: TSPL Body Line]

|
|

Explanation

In this example, the form TSPL Print Form uses the Page Break attribute to specify TSPL Footer Part as the Closing Part and TSPL Header Part as the Opening Part for printed pages. Whenever the report content in TSPL Body Part spans multiple pages, the system automatically prints TSPL Footer Part at the bottom of the current page and TSPL Header Part at the top of the next page.

The footer part displays the text “P.T.O”, indicating that the report continues on the next page, while the header part displays “Carried Forward”, indicating that the content is continuing from the previous page. This demonstrates how the Page Break attribute helps maintain continuity across multiple printed pages by automatically rendering designated footer and header Parts at page boundaries.

Sub-reports often contain fields whose values are derived using Set As or Modifies expressions. Persistent is an attribute used at the Form level to control whether these expressions should be re-evaluated each time the sub-report is opened. When set to Yes, the field values are recalculated on every open, ensuring that the latest context is reflected. When set to No (default), existing field values are retained and previously stored values continue to be used. This attribute is useful when sub-report data needs to be refreshed dynamically instead of preserving earlier values.

Syntax

[Form : <Form Name>]

Persist : <Logical Value>

Example

[Form: TSPL VCHACC Allocation]

Persistent : Yes

Explanation

In this example, the form TSPL VCHACC Allocation uses the attribute Persistent : Yes to ensure that the fields within the form are re-evaluated each time the form is opened as a sub-report. As a result, any values derived through Set As or Modifies expressions are recalculated based on the current context instead of reusing previously stored values. This helps ensure that the form always displays the latest information and reflects the most recent data available at the time it is opened.

During form interaction, users may enter or modify information that does not directly match the structure of the target object. Before the form is accepted and the data is committed, it may be necessary to prepare the object by copying, deriving, synchronizing, or transforming values into the required format. Preaccept Object Map is an attribute used to invoke an Object Map definition immediately before form acceptance, ensuring that all required object mapping logic is executed before the save process completes. This helps ensure that the target object contains the correct data and structure at the time of acceptance. The attribute is commonly used to synchronize related object data, populate derived values, transform user-entered information into the required object structure, and make mapped data available before the form is finally accepted and saved.

Syntax

[Form : <Form Name>]

Preaccept Object Map : <Object Map Definition Name> : <Logical Expression>

Example

[Form: TSPL Ledger Form]

Parts                : TSPL Ledger Part
Preaccept Object Map : TSPL Ledger Contact Object Map : Yes

                   |

                   |

;; ——– Object Map Definition ——–

[Object Map: TSPL Sales Object Map]

Delete Collection Object : ContactDetails : * : ($Name != $$Ifvalue:$LedgerContact:@@locPrimaryMobileNo)
Set Var : SVMSTToggleFlag   : NOT ##SVMSTToggleFlag

Explanation

In this example, the form TSPL Ledger Form uses the Preaccept Object Map attribute to invoke the Object Map TSPL Ledger Contact Object Map immediately before the form is accepted. This ensures that the object mapping logic is executed and the underlying object data is prepared before the save process completes.

The Object Map processes the ContactDetails collection by removing all contact entries except the one matching the ledger’s primary mobile number. It also updates the variable SVMSTToggleFlag by toggling its current value. As a result, the contact information is synchronized and the object is brought into the desired state before the ledger is accepted and saved. This demonstrates how Preaccept Object Map can be used to clean up, transform, or synchronize object data immediately before form acceptance, ensuring that only the intended data is committed.

When a form is loaded, it may require data that is not directly available in the desired structure or context. Before the form is displayed to the user, object data may need to be prepared, transformed, synchronized, or populated so that the form opens with the correct information. Preload Object Map is an attribute used to invoke an Object Map definition immediately before the form is loaded, ensuring that all required object mapping logic is executed in advance. This allows the form to open with the correct data context and pre-prepared object values. The attribute is commonly used to initialize object data, populate derived values, synchronize related object information, transform object structures, and make mapped data available before the form becomes available for user interaction. By preparing the object during form load, the form can display accurate and ready-to-use information from the moment it is opened.

Syntax

[Form : <Form Name>]

Preload Object Map : <Object Map Definition Name> : <Logical Expression>

Example

[Form: TSPL Ledger Form]

Parts              : TSPL Ledger Part
Preload Object Map : SetContactDetailsPrimary
|
|

;; ——– Object Map Definition ——–

[Object Map: TSPL Ledger ObjMap]

Map : LedgerName : $Name

Explanation

In this example, the form TSPL Ledger Form uses the Preload Object Map attribute to invoke the Object Map SetContactDetailsPrimary before the form is loaded. This ensures that the object mapping logic is executed and the required object data is prepared before the form is displayed to the user.

The Object Map maps the method $Name of the current object to the target member LedgerName. As a result, the value of the ledger name is made available in the mapped object structure before the form is rendered. This demonstrates how Preload Object Map can be used to initialize or prepare object data in advance, ensuring that the form opens with the required information already populated and ready for user interaction.

After a form is accepted or saved, users may often need to print the resulting document immediately, such as an invoice, voucher, receipt, or other business document. Print After Save is an attribute used to automatically trigger the printing process once the form acceptance or save operation is completed. When this attribute is enabled, the system initiates the print action without requiring the user to manually invoke printing after saving. This helps streamline workflows, reduce user effort, and ensure that documents intended for immediate printing are generated automatically as soon as the corresponding data is saved.

Syntax

[Form : <Form Name>]

Print After Save : <Logical Expression>

Example

[Form: TSPL Invoice Form]

Parts            : TSPL Invoice Part
Print After Save : @@TSPLAutoPrint
|
|

[System: Formula]

TSPLAutoPrint : $$IsEqual:##SVViewName:($$SysName:InvVchView)

Explanation

In this example, the form TSPL Invoice Form uses the Print After Save attribute to conditionally trigger printing after the form is accepted or saved. The attribute references the formula @@TSPLAutoPrint, which evaluates whether the current view name (##SVViewName) is equal to InvVchView.

When the formula evaluates to True, the system automatically initiates the printing process immediately after the invoice is saved. If the formula evaluates to False, no automatic printing occurs. This demonstrates how Print After Save can be used along with conditional logic to automatically print documents only in specific scenarios or views.

Printed documents may sometimes require a coloured background to improve presentation, highlight specific sections, or match a predefined document design. Print BG is an attribute used to specify the background colour of a form specifically for printing. The colour defined through this attribute is applied only during the printing process and is not displayed when the form is viewed on the screen. When printed on a colour printer, the specified background colour appears as defined, while on a black-and-white printer it is rendered in corresponding shades of grey. This allows developers to enhance the visual appearance of printed documents without affecting the on-screen display of the form.

Syntax

[Form : <Form Name>]

Print BG : <Color Definition Name>

Example

[Form: TSPL Print Form]

Parts    : TSPL Print Part
Print BG : TSPL Print Color
|
|

[Color: TSPL Print Color]

RGB : 200, 220, 255

Explanation

In this example, the form TSPL Print Form uses the Print BG attribute to associate the colour definition TSPL Print Color with the form during printing. The colour definition specifies an RGB value of 200, 220, 255, which represents a light blue shade. As a result, when the form is printed, the background of the printed output appears in this light blue colour on colour printers, while black-and-white printers render it in the corresponding shade of grey. The specified background colour is applied only during printing and does not affect the appearance of the form on the screen.

Printed documents may sometimes require specific text or content colours to improve readability, highlight important information, or match a predefined document design. Print FG is an attribute used to specify the foreground colour of a form specifically for print mode. The colour defined through this attribute is applied to the form content during printing and does not affect the appearance of the form when viewed on the screen. When printed on a colour printer, the specified foreground colour is used as defined, while black-and-white printers render it in the corresponding shade of grey. This allows developers to customise the appearance of printed content independently of the display layout.

Syntax

[Form : <Form Name>]

Print FG : <Color Definition Name>

Example

[Form: TSPL Print Form]

Parts    : TSPL Print Part
Print FG : TSPL Print Color
|
|

[Color: TSPL Print Color]

RGB : 194, 116, 177

Explanation

In this example, the form TSPL Print Form uses the Print FG attribute to associate the colour definition TSPL Print Color with the form during printing. The colour definition specifies an RGB value of 194, 116, 177, which represents a purple shade. As a result, the foreground content of the form, such as text and other printable elements, is printed in this colour on colour printers. On black-and-white printers, the colour is rendered in the corresponding shade of grey. The specified foreground colour is applied only during printing and does not affect the appearance of the form when viewed on the screen.

Printed documents may require specific text styles to improve readability, emphasize important information, or conform to a particular document format. Print Style is an attribute used to specify the style that should be applied to a form during printing. The style can control characteristics such as font appearance, size, emphasis, and other print-related formatting properties. The style defined through this attribute affects only the printed output and does not alter the appearance of the form when viewed on the screen. By using Print Style, developers can customize the presentation of printed documents independently of the display layout.

Syntax

[Form : <Form Name>]

Print Style : <Style Definition Name>

Example

[Form: TSPL Print Style Form]

Parts       : TSPL Style Part
Print Style : TPSL Cambria Small
|
|

[Style: TPSL Cambria Small]

Font   : Cambria
Height : 8

Explanation

In this example, the form TSPL Print Style Form uses the Print Style attribute to associate the style definition TPSL Cambria Small with the form during printing. The style specifies the font Cambria with a height of 8, defining how the form content should appear in the printed output. As a result, the content rendered from TSPL Style Part is printed using the Cambria font at the specified size. The style is applied only during printing and does not affect the appearance of the form when viewed on the screen.

Sometimes, a single mapped value in a document template may need to be expanded repeatedly across multiple columns instead of appearing only once. Repeat is an attribute used along with XML Map / JSON Map definitions to indicate that the mapped value should be repeated in the generated output. The way the repetition occurs depends on the value specified with the attribute. If the collection name specified is STRING, the mapped value is repeated character by character. Otherwise, the value is repeated based on the objects available in the specified collection, with each object contributing a separate repeated value. This attribute was introduced to support Productivity Suite by aiding repeat of collection for columns. In later release it has been extended to support data type string to aid fill information in form for individual block.

Let us, consider a scenario where a template is designed to print each character of an invoice number in separate boxes, similar to cheque printing or structured government forms.

XML Map : InvNo : $VoucherNumber
Repeat       : InvNo : STRING

If the voucher number is INV1025, the generated output repeats each character separately across columns:

| I | N | V | 1 | 0 | 2 | 5 |

instead of printing the complete value as a single string.

Similarly, when a collection name is specified instead of STRING, the mapped value is repeated for each object in that collection. This is useful in document templates that require dynamic column generation, where each repeated column represents data from a different object in the collection, such as ledgers, stock items, or other business entities.

Syntax

[Form : <Form Name>]

Repeat : <XML Map Name> : <Collection Name / Data Type>

Example

[Report: TSPL Column Repeat Report]

Form : TSPL Column Repeat Form

[Form: TSPL Column Repeat Form]

Parts  : TSPL Column Repeat Part
Repeat : ClBal : TSPL Ledger Collection

[Part: TSPL Column Repeat Part]

Lines : TSPL Column Repeat Line

[Line: TSPL Column Repeat Line]

Fields : TSPL Ledger Name, TSPL Ledger Balance

[Field: TSPL Ledger Name]

Set As : $Name

[Field: TSPL Ledger Balance]

Set As : $ClosingBalance

[Collection: TSPL Ledger Collection]

Source Collection : TSPL Smp ColRepLedSrc
Fetch             : Name, OpeningBalance, ClosingBalance

[Collection: TSPL Smp ColRepLedSrc]

Type   : Ledger
Fetch  : *

Explanation

In this example, the Repeat attribute is used with the collection TSPL Ledger Collection to generate repeated output for each ledger object available in the collection. The collection fetches the ledger methods Name, OpeningBalance, and ClosingBalance from all ledger objects. When the form is rendered, the system iterates through each ledger object in the collection and repeats the mapped output for every object. As a result, the fields TSPL Ledger Name and TSPL Ledger Balance are evaluated in the context of each ledger, displaying the ledger name and its closing balance respectively. This enables dynamic column generation where a separate column or repeated section is created for each ledger in the collection, making it useful for columnar reports, comparative statements, and document templates that need to display data from multiple objects side by side.

Document generation often requires predefined templates to control the layout, structure, and presentation of the final output. Resource is an attribute used to specify the name of the document template resource that should be used during printing or exporting. The resource points to a predefined template file that defines how the generated output should appear.

Templates such as Word XML, Excel XML, ODT, and ODS can be used for both printing and exporting operations, while XML and JSON templates are supported only for exporting. During execution, the template works in conjunction with the JSON Map (aliases: MAP, XML Map) attribute at the Form level, where template tokens are dynamically replaced with values obtained by evaluating TDL expressions.

By separating the document layout from the report logic, developers can generate structured, formatted, and template-driven outputs without modifying the underlying report definitions. This attribute is primarily used as part of the Productivity Suite capabilities in TDL for generating business documents, formatted exports, and other dynamically generated outputs using live report data.

Syntax

[Form : <Form Name>]

Resource : <Resource Definition Name>

Example

[Form: TSPL Export Form]

Parts    : TSPL Export Part
Resource : TSPL Export Template
|
|

[Resource: TSPL Export Template]

Source        : ‘.resourcesSalesTemplate.xml’
Resource Type : XML

Explanation

In this example, the form TSPL Export Form uses the Resource attribute to associate the document template resource TSPL Export Template with the form. The resource definition points to the template file SalesTemplate.xml located in the resources folder and specifies its type as XML. When the form is exported, the system uses this template as the basis for generating the output. Any tokens defined within the template can then be populated using corresponding JSON Map / XML Map definitions, allowing live report data to be inserted into the predefined document structure. This demonstrates how the Resource attribute links a form to an external template, enabling template-driven document generation and export.

Variables are often used to store values that control calculations, conditions, filtering, report behavior, or user interaction. Before a variable can be used, it may need to be assigned an initial value. Set is an attribute used to initialize or assign a value to a variable. The specified value is evaluated and assigned to the variable, making it available for subsequent processing within the report, form, function, or other TDL definitions. Unlike Set Always, which re-evaluates and updates the variable every time the form refreshes, Set initializes the variable only once when the definition is loaded and retains the assigned value until it is explicitly modified.

By initializing variables at the appropriate stage, developers can ensure that the required values are available for business logic, computations, conditional processing, and report execution.

Syntax

[Form : <Form Name>]

Set : <Variable Name> : <Value>

Example

[Form: TSPL Variable Form]

Parts : TSPL Variable Part
Set   : TSPLMasterType : “Ledger”
|
|

[Variable: TSPLMasterType]

Type : String

Explanation

In this example, the form TSPL Variable Form uses the Set attribute to initialize the variable TSPLMasterType with the value “Ledger” when the form is loaded. The variable TSPLMasterType is defined as a String variable, and the assigned value becomes available throughout the form for use in calculations, conditions, filtering, or other business logic. This demonstrates how the Set attribute can be used to provide an initial value to a variable, ensuring that it is ready for use as soon as the form becomes active.

Variables are often initialized with a value when a form is loaded, but there are situations where the value must be recalculated whenever the form is refreshed or re-evaluated. Set Always is an attribute used to ensure that the value of a variable is assigned every time the form refreshes. Unlike the Set attribute, which initializes the variable only once when the form is loaded, Set Always forces the specified expression to be evaluated repeatedly whenever the form is refreshed, ensuring that the variable always reflects the latest value based on the current context.

This attribute is particularly useful when variable values depend on dynamic data, changing object contexts, or calculations that need to remain synchronized with the current state of the form. While Set is suitable for assigning an initial value that remains unchanged unless explicitly modified, Set Always ensures that the variable is continuously updated to reflect the most recent data available to the form.

Syntax

[Form : <Form Name>]

Set Always : <Variable Name> : <Value>

Example

[Form: TSPL SetAlways Form]

Parts      : TSPL SetAlways Part
Set Always : TSPLCurrentDate : ($$SysInfo:SYstemDate)
|
|

[Variable: TSPLCurrentDate]

Type : Date

Explanation

In this example, the form TSPL SetAlways Form uses the Set Always attribute to assign the current system date obtained from $$SysInfo:SystemDate to the variable TSPLCurrentDate. Since Set Always is used, the expression is evaluated every time the form refreshes, ensuring that the variable always contains the latest system date available at that moment. If the same logic were implemented using the Set attribute, the variable would be initialized only once when the form is loaded and would retain that value during subsequent form refreshes. This demonstrates how Set Always helps keep variable values synchronized with changing data or system conditions throughout the lifetime of the form.

Printed documents and screen layouts may sometimes require additional space below the form content to improve readability, maintain alignment, or accommodate other layout elements. Space Bottom is an attribute used to specify the amount of space that should be left at the bottom of the form. The specified space is reserved after the form content, helping developers control the overall layout and presentation of the form.

This attribute supports all Tally-supported units of measurement, such as mm, inch, and percentage of screen or page, providing flexibility in defining the required bottom spacing. Space Bottom is particularly useful in print layouts where adequate space needs to be maintained before footers, declarations, signatures, or other concluding sections.

Syntax

[Form : <Form Name>]

Space Bottom: <Measurement>

Example

[Form: TSPL Space Bottom Form]

Parts        : TSPL Space Bottom Part
Space Bottom : 5% Screen

Explanation

In this example, the form TSPL Space Bottom Form uses the attribute Space Bottom : 5% Screen to reserve additional space equivalent to 5% of the screen height below the form content. After all content from TSPL Space Bottom Part is rendered, the specified space is maintained at the bottom of the form before any subsequent content or layout elements are displayed. This helps improve layout alignment and presentation by ensuring that adequate spacing is available below the form content.

Forms and print layouts may sometimes require additional space on the left side to improve alignment, accommodate margins, or position content appropriately within the available area. Space Left is an attribute used to specify the amount of space that should be left on the left side of the form. The specified space is reserved before the form content is rendered, helping developers control the horizontal positioning and overall presentation of the form.

This attribute supports all Tally-supported units of measurement, such as mm, inch, and percentage of screen or page, providing flexibility in defining the required left-side spacing. Space Left is particularly useful in print layouts where content needs to be aligned with predefined margins, stationery formats, pre-printed forms, or other layout elements.

Syntax

[Form: <Form Name>]

Space Left : <Measurement>

Example

[Form: TSPL Space Left Form]

Parts      : TSPL Space Left Part
Space Left : 5% Screen

Explanation

In this example, the form TSPL Space Left Form uses the attribute Space Left : 5% Screen to reserve additional space equivalent to 5% of the screen width on the left side of the form. Before the content from TSPL Space Left Part is rendered, the specified space is maintained on the left, causing the form content to be positioned slightly towards the right. This helps improve layout alignment and presentation by ensuring that adequate spacing is available on the left side of the form, which can be useful for maintaining margins, accommodating pre-printed stationery, or aligning content within a specific layout structure.

Forms and print layouts may sometimes require additional space at the top to improve visual balance, maintain margins, or accommodate headers and other layout elements. Space Top is an attribute used to specify the amount of space that should be left at the top of the form. The specified space is reserved before the form content is rendered, helping developers control the vertical positioning and overall presentation of the form.

This attribute supports all Tally-supported units of measurement, such as mm, inch, and percentage of screen or page, providing flexibility in defining the required top spacing. Space Top is particularly useful in print layouts where content needs to be aligned below predefined headers, logos, stationery layouts, or other top-level elements.

Syntax

[Form : <Form Name>]

Space Top : <Measurement>

Example

[Form: TSPL Space Top Form]

Parts     : TSPL Space Top Part
Space Top : 5% Screen

Explanation

In this example, the form TSPL Space Top Form uses the attribute Space Top : 5% Screen to reserve additional space equivalent to 5% of the screen height at the top of the form. Before the content from TSPL Space Top Part is rendered, the specified space is maintained above the form content, causing the content to begin slightly lower on the screen. This helps improve layout alignment and presentation by ensuring that adequate spacing is available at the top of the form, which can be useful for accommodating headers, logos, predefined margins, or other top-level layout elements.

Forms and print layouts may sometimes require additional space on the right side to improve alignment, maintain margins, or accommodate other layout elements. Space Right is an attribute used to specify the amount of space that should be left on the right side of the form. The specified space is reserved after the form content, helping developers control the horizontal positioning and overall presentation of the form.

This attribute supports all Tally-supported units of measurement, such as mm, inch, and percentage of screen or page, providing flexibility in defining the required right-side spacing. Space Right is particularly useful in print layouts where content needs to be aligned within predefined margins, stationery formats, or other layout constraints while ensuring adequate whitespace on the right side of the form.

Syntax

[Form: <Form Name>]

Space Right: <Measurement>

Example

[Form: TSPL Space Right Form]

Parts       : TSPL Space Right Part
Space Right : 5% Screen

Explanation

In this example, the form TSPL Space Right Form uses the attribute Space Right : 5% Screen to reserve additional space equivalent to 5% of the screen width on the right side of the form. After the content from TSPL Space Right Part is rendered, the specified space is maintained on the right, preventing the form content from extending into the reserved area. This helps improve layout alignment and presentation by ensuring that adequate spacing is available on the right side of the form, which can be useful for maintaining margins, accommodating stationery layouts, or aligning content within a specific page structure.

Forms that display tabular or repeated data can sometimes become difficult to read when multiple rows appear with the same visual formatting. Stripe is an attribute used to enable or disable striped rows within a form, improving readability by visually distinguishing adjacent rows. When enabled, alternate rows are displayed with different background shading, making it easier for users to track information across the form.

By default, Stripe is set to Yes, and supported data formats automatically display striped rows. This default behavior can be overridden by specifying the Stripe attribute in a child definition, such as a Part, allowing developers to enable or disable striping selectively for specific sections of the form. This attribute is particularly useful in reports, lists, and tabular layouts where improved row differentiation enhances usability and readability.

Syntax

[Form : <Form Name>]

Stripe : <Logical Value>

Example

[Form: TSPL Stripe Form]

Parts  : TSPL Stripe Part
Stripe : Yes

Explanation

In this example, the form TSPL Stripe Form explicitly enables row striping using the attribute Stripe : Yes. As a result, when the form displays tabular or repeated data through TSPL Stripe Part, alternate rows are rendered with different background shading, making it easier for users to distinguish one row from another. This improves readability, especially in reports or lists containing large amounts of data. Although striping is enabled by default for supported data formats, specifying Stripe : Yes at the form level ensures that striped rows are applied to the form unless overridden by a child definition such as a Part.

The appearance of text within a form plays an important role in improving readability and maintaining a consistent visual presentation. Style is an attribute used to specify the text style at the Form level. It applies a predefined style definition to the form, allowing developers to control text characteristics such as font, height, bold, italic, underline, and other font-related properties.

By defining a style at the Form level, the specified formatting is inherited by the contents of the form unless overridden by child definitions. This helps maintain a consistent look and feel across the form while reducing the need to apply the same formatting repeatedly at individual Part, Line, or Field levels.

Syntax

[Form : <Form Name>]

Style : <Style Definition Name>

Example

[Form: TSPL Style Form]

Parts : TSPL Style Part
Style : TSPL Cambria Small

[Style: TSPL Cambaria Small]

Font   : Cambria
Height : 8

Explanation

In this example, the form TSPL Style Form uses the Style attribute to associate the predefined style TSPL Cambria Small with the form. The style definition specifies the font as Cambria and the height as 8, determining how text within the form should be displayed. As a result, the content rendered through TSPL Style Part inherits these formatting properties and is displayed using the Cambria font at the specified size. This demonstrates how the Style attribute can be used to apply a consistent text appearance across an entire form without defining the same formatting repeatedly at individual fields.

Message boxes and query boxes are often displayed to interact with users while they work within a form. Sub Form is an attribute used at the Form level to specify whether a message box or query box should be positioned relative to the current form or relative to the entire screen (canvas). When enabled, the dialog is displayed in the context of the current form, making it appear visually associated with that form. When disabled, the dialog is positioned relative to the full screen.

This attribute helps developers control the placement and visual context of message and query boxes. Do not confuse it with the Field-level Sub Form attribute, which is used to invoke another form from a field. At the Form level, Sub Form only controls the positioning of dialog boxes.

Syntax

[Form : <Form Name>]

Sub Form : <Logical Value>

Example

[Form: TSPL SubForm Form]

Parts    : TSPL SubForm Part
Sub Form : No

Explanation

In this example, the form TSPL SubForm Form uses the attribute Sub Form : No, indicating that any message box or query box associated with the form should be positioned relative to the entire screen rather than the form itself. As a result, when a dialog is displayed, it appears in the context of the full screen (canvas) instead of being anchored to the current form. This is useful when the dialog needs to remain independent of the form’s location or layout on the screen.

When multiple horizontal Parts are displayed side by side, it is often necessary to ensure that related information appears aligned across all columns. **Sync** (alias: **Synchronize**) is an attribute used to specify a string formula based on which horizontal Parts are synchronized. The value returned by the specified formula acts as the synchronization key, causing corresponding entries across the horizontal Parts to align with each other.

For example, consider a multi-column Cash Book where receipts are displayed in one horizontal Part and payments are displayed in another. Since both Parts may contain a different number of transactions, the rows may not naturally align. By specifying the transaction date as the synchronization key, entries belonging to the same date are displayed on the same horizontal level across all Parts. This makes the report easier to read and compare, as users can view related information side by side. The `Sync` attribute is therefore particularly useful in multi-column cash books, comparative statements, and other columnar reports where data from different Parts needs to be aligned using a common value such as date, voucher number, ledger name, or any other matching key.

Syntax

[Form : <Form Name>]

Sync : <Expression>

Example

[Form: TSPL Sync Form]

Parts : TSPL Sync Part
Sync  : $$MonthStart:$Date

Explanation

In this example, the form TSPL Sync Form uses the Sync attribute to synchronize horizontal Parts based on the value returned by the expression $$MonthStart:$Date. The expression evaluates to the starting date of the month corresponding to the current transaction date, and this value acts as the synchronization key. As a result, entries belonging to the same month are aligned across the horizontal Parts, even if the number of entries in each Part differs. This helps present related information together and improves readability in columnar reports where data needs to be compared month-wise across multiple sections.

Forms may sometimes need to be refreshed when a change in context affects their structure, content, or behavior. Volatile is an attribute used to specify a logical condition based on which the form content should be refreshed. When the specified condition evaluates to True, the current form content is destroyed and regenerated using the latest context, ensuring that the form reflects the most up-to-date data, configuration, and layout.

This attribute is particularly useful in scenarios where changes made by the user can affect the composition of the form itself. For example, in the default TDL, Volatile is used in voucher forms to refresh the form when the voucher class is changed, allowing the form layout, fields, and values to be regenerated according to the newly selected voucher class. By rebuilding the form dynamically, the attribute ensures that users always interact with the correct form structure for the current context.

Syntax

[Form : <Form Name>]

Volatile : <Logical Expression>

Example

[Form: TSPL Volatile Form]

Parts    : TSPL Volatile Part
Volatile : ##vRefresh

Explanation

In this example, the form TSPL Volatile Form uses the Volatile attribute with the condition ##vRefresh. Whenever the variable vRefresh evaluates to True, the existing contents of the form are discarded and the form is regenerated using the current context. This ensures that any changes affecting the form’s structure, layout, or displayed data are immediately reflected in the regenerated form.

As long as ##vRefresh evaluates to False, the form continues to use the existing content without rebuilding. This demonstrates how the Volatile attribute can be used to dynamically refresh a form whenever a specified condition indicates that the form needs to be regenerated.

XML exports often require additional metadata to be attached to the generated XML tags in the form of attributes rather than nested elements. XMLAttr is an attribute used at the Form level to specify an attribute name and its corresponding value for the XML tag generated for the form during export. Its primary purpose is to provide document-level metadata on the root XML element, such as the document version, export type, company identifier, schema version, generation timestamp, or other properties that describe the exported document as a whole. For example, an exported XML document may contain a root tag such as <SalesReport Version=”2.0″ CompanyID=”ABC001″ ExportType=”Summary”>, where Version, CompanyID, and ExportType are metadata attributes describing the document. This helps generate XML documents that conform to external integration and data exchange standards. While XMLAttr can also be specified at the Part and Line levels to attach attributes to their respective XML elements, those definitions are typically used for section-specific or record-specific metadata. Together, the Form, Part, and Line level XMLAttr definitions enable developers to build a well-structured XML hierarchy with appropriate metadata at each level of the exported output.

Syntax

[Form : <Form Name>]

XMLAttr : < Expression for Name> : <Expression for Value>

Example

[Form: TSPL Led]

XML Tag  : “Sales Register”
XML Attr : “Version” : “2.0”
XML Attr : “CompanyID” : “ABC001”
XML Attr : “ExportType” : “Summary”

Explanation

In this example, the form TSPL Led uses the XML Tag attribute to generate a root XML element named Sales Register. The XMLAttr attributes are then used to attach additional metadata to this root element. The attribute Version is assigned the value “2.0”, CompanyID is assigned “ABC001”, and ExportType is assigned “Summary”. When the form is exported, these values are generated as XML attributes of the Sales Register tag rather than as separate XML elements. This allows important document-level information to be embedded directly within the root XML element, making the exported XML more descriptive and easier for external systems to identify, validate, and process.