https://help.tallysolutions.com/docs/td9rel54/tdl_reference/release_4_6.htm

What’s New in Release 4.6

COM DLL Support in TDL

A dynamic link library (DLL) is an executable file that acts as a shared library of functions. Dynamic linking provides a way for a process to call a function that is not part of its executable code. The executable code for the function is located in a DLL, which contains one or more functions that are compiled, linked, and stored separately from the processes that use them. Multiple applications can simultaneously access the contents of a single copy of a DLL in memory.

DLL support has been provided in TDL for quite a while. The focus was primarily on extending Tally for bringing in capabilities which could not be achieved within Tally. ‘CallDLLFunction’ allowed calling native/unmanaged DLLs which were written and compiled in C++.

In further releases, this moved a step further where the support was extended to use Plug-In and Activex Plug-In , where the XML output from the DLL could be used as a data source in the collection artefact, and thereby, consumed in TDL. This paved the way for new possibilities on extending Tally as per customer needs, which required interactions with external hardware, etc. However, this required changes in the DLL as per the processing capabilities of the collection. The XML output from the collection had to be necessarily from a function within DLL which had to be named mandatorily as TDLCollection within the DLLClass.

The Com p onent O b ject Mo d el (COM) i s a component software architecture that allows applic a tions and systems to be built from componen t s sup p lied by di f ferent so f tware ve n dors. C OM i s the un d erlying architecture that forms the foun d ation for higher level software services. These DLLs provide the stand a rd benefi t s of shared libraries. Component O b ject Model (CO M ) w as introduced by Microsoft to enable inter process communication a n d dyn a mic object creation acr o ss a v a ried range of programming languages. In other words, objects can be implemented in enviro n men t s seamlessly different from the one in w hich they are crea t ed. This technol o gy s p ecifies manip u lation of data associated with objects through an Int e rfac e . A COM i n terface refers to a pre d efined group o f r elated functions that a COM class im p lements. The object implemen t s the i n terface by using the code that implem e nts each method of t h e i n terface, a nd p rovides C OM binary-compli a nt pointers to those functions, to the COM librar y . COM then makes th o se func t ions available to the requesting clients.

COM DLL Support w ill p ave t h e way for providing features like ‘Tally For B lind’ using the generic s p eech API provided by M icroso f t. This Release comes with e nhanced capabili t ies in the language to support COM D L L pr o cessing. A new d e finition ty p e c alled COM Interface has been introduced for the same.

COM Servers and COM Clients

A COM Server is any class/method that provides services to clients. These services are in the form of interface implementations which can be called by any client that is able to get a pointer to one of the interfaces on the server object. A COM Client makes use of a COM Server, and uses its services by calling the methods of its interfaces.

COM Server DLLs are DLLs which have objects exposed to COM and can be used by COM Clients. Let’s take the following DLL Code as an example:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace MathLib

{

public class MathCl a ss

{

public doub l e Add(d o uble p D ouble)

{

return pDou b le + 9;

}

public int D ivide(i n t Divi d end, int Divis o r, out i nt Rem a inder)

{

int Q uotien t ;

Quotient = D ividend / Diviso r ;

Remainder = Dividend - (Di v isor * Q uotien t );
retur n Quot i ent;

}

public void datefun c (ref D a teTime d ate)

{

date = date . AddDays ( 40);

}

}

}

In C# DLL, three functions are called. They are:

Add - It takes an input parameter, and returns it, after adding 9 to it.

Divide - It accepts a Dividend and a Divisor as inputs, and returns the Quotient, along with the Remainder.

datefunc - It accepts a parameter ‘date’ as input, and updates it by adding 40 days to it.

Registering th e DLL

For . NET COM Servers, we need to register with a p arameter/CodeBase.

Example:

regasm/Cod e Base <D L L Name with ab s olute p ath>

Registering COM DLLs

To register DLLs on 32-bit operating system

1. Go to the folder where 32-bit windows Microsoft.net framework. Generally, Microsoft.net framework is available at C:\Windows\Microsoft.NET\Framework .

2. Choose the latest version of .NET Framework.

3. Copy the folder path where the regasm.exe is available. For example, C:\Windows\Microsoft.NET\Framework\v4.0.30319 .

4. Open Command Prompt in administrator mode.

5. Replace the path using the command: cd /d C:\Windows\Microsoft.NET\Framework\v4.0.30319 .

6. Place the DLL in Tally.ERP 9 folder and copy the entire path.

7. Register the DLL using regasm/codebase "G:\Tally\Tally 5.3.4\TFI.dll" .

To register the DLL on 64-bit operating system

1. Go to folder where 64-bit windows Microsoft.net framework. Generally, the Microsoft.net framework is available at C:\Windows\Microsoft.NET\Framework64 .

2. Choose the latest version of .NET Framework.

3. Copy the folder path where the regasm.exe is available. For example, C:\Windows\Microsoft.NET\Framework64\v4.0.30319 .

4. Open Command Prompt in administrator mode.

5. Replace the path using the command: cd /d C:\Windows\Microsoft.NET\Framework64\v4.0.30319 .

6. Place the DLL in Tally.ERP 9 folder and copy the entire path.

7. Register the DLL using the command. For example, regasm/codebase "G:\Tally\Tally 5.3.4\TFI.dll" .

For further details on steps to register DLLs, please refer to the section How to Register DLLs .

Note: If the DLL is written using VB.NET or C#.NET; before building the DLL, please ensure that the COM Visible Property is set. After registering the DLL, ensure that the registry entries are available as under:

ProgID : The value for which should be <ProjectName>.<ClassName>

Inprocserver32 OR InprocHandler32 OR LocalService – The default value for these keys in registry should be the path to the DLL/EXE which we have registered.

To find the Registry Entry, one can open regedit, and locate the project name of the DLL that has been registered and ensure the above.

Implementation in Tall y .ERP 9 using TDL

A new definition ‘COM Interface’ has been introduced to call a function available in external DLL/ EXE (COM Server). This will help the TDL Developer to use external libraries and devices. With this enhancement, Tally.ERP 9 can now act as a COM Client.

Definition - COM Interface

The definition ‘COM Interface’ has been introduced to accept the external DLL/EXE details like Project name, Class name, Function name and other required parameters.

Syntax

[COM Interface : <COM Interface name>]

Where,

< COM Interface name > is the name of the COM Interface definition.

Attributes supported by definition ‘COM Interface’:

The following attributes are supported in this definition:

Attribute - PROJECT

This attribute is used to specify the name of the project.

Syntax

Project : <Project Name>

Where,

< Project Name > is the name of the Project/Name space of the COM Server.

Attribute - CLASS

This attribute is used to specify the Class name under the project specified.

Syntax

Class : <Class name>

Where,

< Class Name > is the name of the Class of the COM server to be used.

Attribute - INTERFACE

This attribute is used to specify the interface name under the class that needs to be executed. It corresponds to the name of the function within the DLL Class to be executed.

Syntax

Interface : <Interface name>

Where,

< Interface Name > is the name of the actual Interface name of the DLL which is to be called.

Attribute - PARAMETER

This attribute denotes the list of parameters along with their data types required by the COM Interface. The TDL Data types supported are:

Number

Long

String

Logical

Date

Syntax

Parameter : <Parameter Name> : <Data type> [: <Parameter Type>]

Where,

< Parameter Name > is the name of the Parameter.

< Data Type > is the data type of the parameter being passed.

< Parameter Type > is the nature of the parameter, viz. In (Input), Out (Output) or InOut (Both Input and Output)

Example

Parameter of type String for accepting output will be written as:

Parameter : Parm1 : String : Out

In the absence of the specification of the nature of Parameter, the parameter is defaulted as in parameter.

Note : All the parameters must sequentially correspond to the ones accepted by the COM Interface.

Attribute - Returns

This attribute denotes the return data type of the COM Interface.

Syntax

Returns : <Return Data Type>

Where,

< Return Data Type > is the data type of the value returned by the COM Interface. Let us define the COM Interfaces required for the previous DLL code:

[COM Interface : TSPL Smp Addition]

Project   : MathLib

Class     : MathClass

Interface : Add

Parameters: p1 : Number : In

Returns   : Number

[COM Interface : TSPL Smp Division]

Project    : MathLib

Class      : MathClass

Interface  : Divide

Parameters : p1 : Long : In

Parameters : p2 : Long : In

Parameters : p3 : Long : Out

Returns    : Long

[COM Interface : TSPL Smp AddDate]

Project    : MathLib

Class      : MathClass

Interface  : DateFunc

Parameters : p1 : Date : InOut

In this code, 3 COM Interfaces are defined, each for executing 3 different functions inside DLL:

MathLib is the DLL Project Name.

MathClass is the DLL Class under the Project MathLib.

Add, Divide and DateFunc are the Functions under the Class MathClass, which are specified in the Attribute Interface.

Action – Exec COM Interface

A new action Exec COM Interface has been introduced to invoke the defined COM Interface.

Syntax

Exec COM Interface: <COM Interface name> [: <Parameter 1> [: <Parameter 2>…… [: <Parameter N>]…]]

Where,

< COM Interface Name > is the name of the COM Interface Definition.

[: <Parameter 1> [: <Parameter 2> …… [: <Parameter N> ]…]] are the subsequent parameters, which are passed considering the following aspects:

If the parameter corresponds to IN parameter, it can take any expression or constant.

If the parameter corresponds to an OUT or an InOut Parameter, then only the variable name must be specified, without prefixing a ##. In other words, expressions are not supported. The variable, in case of:

o InOut P arameter , will send the variable value t o the Interface as i n put, and in r e turn, will bri n g back the value a ltered by the Interface.

o OUT Paramete r , will o nly bring back the updated value from the DLL .

In the previous TDL Code, three COM Interfaces are defined. A function is then called, inside which the action Exec COM Interface is used to invoke the COM interface definitions as follows:

[Function : TSPL Smp Execute COM Interfaces]

Variable : p1 : Number : 90

Variable : p2 : Number : 102

Variable : p3 : Number : 5

Variable : p4 : Number

Variable : pDate : Date

00 : Exec COM Interface : TSPL Smp Addition : ##p1

10 : Log : $$LastResult

20 : Exec COM Interface : TSPL Smp Division : ##p2 : ##p3 : p4

25 : Log : $$LastResult

30 : Log : ##p4

40 : Set : pDate : $$Date:"20-04-2013"

50 : Exec COM Interface : TSPL Smp AddDate :pDate

60 : Log : ##pDate

Note:

If this action is invoked from within a TDL function, then the Objects created are retained until all the Actions within the function are executed. This behaviour was designed so that multiple functions in a COM Class can be used on the same COM Object (state of COM Object is maintained). For instance, there are some functions of a COM server which depend on each other, and are required to be called in sequence, then the same object needs to be present and functions should be called on that same object to give correctness.

As a Global action, this would create a COM Object once per COM Interface execution. In other words, if there are two functions of a COM Server and they depend on each other, then this action would work only if used within a procedural Code.

Function - $$COMExecute

This function is similar to the Action Exec COM Interface , except that Interfaces with only In Parameters can be executed with the Function $$ COMExecute . In other words, this Function can only execute a COM Interface , if it has no Out Parameters.

Syntax

$$COMExecute : <COM Interface name>: [<Parameter 1>[:<Parameter 2> [....[: <Parameter n>]....]]]

Where,

< COM Interface Name > is the name of the COM Interface definition.

[< Parameter 1 >[:< Parameter 2 >[....[:< Parameter n >]....]]] are the IN parameters, which correspond to the parameters specified in the COM Interface definition.

As mentioned earlier, the first function of DLL only takes In Parameters. Hence, the function COMExecute can be used only for the first COM Interface definition in the example shown above.

Example

$$COMExecute:TSPLSmpAddition:##p1

Function - $$IsCOMInterfaceInvokable

This function checks if the ‘COM Interface’ description which was defined, could be used or not. If the COM class of the interface is not available in the COM server, it would return FALSE; while if the class and the function invoked in the COM class are present, then the interface is invokable, and hence TRUE would be returned.

Syntax

$$IsCOMInterfaceInvokable : <COM Interface name>

Where,

< COM Interface name > is the name of the COM Interface Definition.

Scope and Limitations

Only a COM Server which implements its classes using IDispatch interface (Automation interface of COM), can be used with this.

For other Native DLLs (DLLs that contain raw processor directly-executable code, e.g., Win32 DLL) or ones which do not comply with the above, another wrapper DLL can be made which makes use of it and exposes the functionality to TDL.

The data types supported are Long, Number, String, Logical and Date, which are mapped to the following data types in TDL:

TDL Type

Parameter data type in TDL

Signed Int

Long

Double

Number

Double

String

Boolean

Logical

Date

Date

Out parameters are supported in this capability. But, functions which take other data types than specified in the table are currently not supported in TDL, and hence, cannot be used.

Developer Mode

In market, there are customers using Tally.ERP 9 for their day-to-day operations. There are also developers/ partners who build solutions within the product to suit the customer requirements. For the entire spectrum of persons using Tally.ERP 9, the only mode of execution available until now was the default mode. In order to empower the developers of Tally with various tools which will help them to build solutions optimally and efficiently, the very new Developer Mode has been introduced.

From Release 4.6 onwards, Tally can operate in 2 modes, viz. Normal Mode which will be used by the end users, and the Developer Mode , which will be used by the developers. The Developer mode will offer various tools for debugging the code and optimizing the performance of reports.

The various Tools introduced for TDL Developers in Developer Mode are:

1. Profiler

Profiler is a very useful tool in the hands of the TDL Programmer. Usually, any requirement can be achieved in multiple ways using TDL. But, it is highly difficult for the programmers to choose the optimal way. Using Profiler, programmers can check the time taken to execute each TDL artefact, along with the count of how many times they have been executed. This ensures redundancy check, and the code can be optimized for the best performance and user experience.

2. Expression Diagnostics

This is a very handy tool for the TDL Programmer. At times, while writing complex expressions for huge projects, it becomes difficult to identify the expression that has failed. Usually, for debugging such code, TDL Programmers had to resort to invoking User Defined Functions and logging the values to trace the point of failure. With Expression Diagnostics, now the system automatically dumps every expression along with their resultant value in the log. For expressions which have failed to execute, the resultant value would be set to FAILED. With this, the programmer can easily reach the exact expression that has failed and correct the same without much delay. This would save a lot of programmer’s time, which can be used for other projects.

3. Key Recording, Playback and Triggering the Keys

This feature will be useful in instances where developers require to execute certain keystrokes repetitively to test/ retest the code output and confirm if the same is in line with the customer requirement. It will help in doing automated QA and ensuring utmost quality for the customer. For instance, if a data entry screen has been customised by incorporating additional fields, sub-forms, etc., then in order to validate if the data entry performance is affected, one can record the keystrokes for saving a voucher, and replay them as many times as required.

4. Onscreen Tooltip

While developing extensions on Tally, developers usually navigate through default TDL to locate the appropriate definition name and alter their attributes within their code. At times, it becomes very difficult for the developers to identify the right field names, since there are several options at various stages and finding the right ones requires a lot of effort. Hence, to make developer’s life easier, a very critical tool, i.e., the Onscreen Tooltip, has been introduced. When the mouse pointer is placed on a Field, the definition name of the Field is displayed. If the pointer points at a place where no field exists, the definition name of the Report is displayed.

All these Tools/Enhancements will be available only if the developer executes Tally in Developer Mode, using the Command Line Parameter DevMode.

Command Line Parameter - DevMode

Command Line Parameter DevMode has been introduced to execute Tally in Developer mode.

Syntax

<Tally App l ication Path>\Tally . exe/DevMode

Example

C:\Tally.ERP9\Tally.exe /DevMode

On invoking Tally in Developer Mode, the Tally Screen is as shown below:

Figure_1._Tally.ERP_9_in_Developer_Mode_(4.6).jpg

Note: Developers must not execute the above at the Client end unless required, because if the client continues to work in this mode, it might affect the performance adversely.

Function - $$InDeveloperMode

This function is used to check if Tally is currently working in Developer mode. It returns TRUE if the Tally application is in Developer Mode, else returns FALSE.

This tool can be used when the developer needs to write some additional code for testing purpose, so that the testing code does not appear to the end user, thereby executing only if the product is running in Developer Mode.

Syntax

$$InDeveloperMode

Example

Option : DevModeDefaultMenu : $$InDeveloperMode

Note: Extensive use of this function in the TDL code may lead to performance issues even in Normal mode.

Let us discuss the tools/capabilities and their usage, in detail:

Profiler

As briefed before, Profiler is a useful tool which helps the developers to check the performance of the TDL Program, thus optimizing the code. It returns the execution time and count of the various TDL artefacts. It gathers information of Collections, User Defined Functions and Expressions.

The steps to get the profiler information are:

Start the Profiler

Execute the desired Report

Dump the Profiler and/or Stop the Profiler, with the file name

The dumped profiler information when opened in Textpad, is as shown below:

Figure_2._Dumped_Profiler_Information_(4.6).jpg

As seen in the figure, the profile information shows the time taken for evaluating every expression as well as how many times (Count) the same expression or collection was evaluated/ gathered.

Developers are already aware that apart from performing various arithmetic operations, Calculator Panel can also be used to issue select Queries like Select $Name, $Parent from Ledger, Select * from Company, etc. Now, the Calculator Pane can also be used by developers for Profiling, Debugging, Key Recording and Playing back by setting various modes.

Commands used for Profiling

The following Calculator Pane Commands are supported for the profiling information:

Profiler Mode

It sets the mode to Profiler, which means that Profiling Commands will be accepted. It provides certain calculator pane commands to the developer in order to check the performance of code.

Syntax

MODE: Profile

Figure_3._Issuing_commands_in_the_Calculator_Pane_in_Profiler_Mode_(4.6).jpg

Once mode is set to Profile, commands issued in the Calculator Pane work in Profiling Context.

Start

This command starts gathering the count and time taken for evaluating a TDL Artefact in memory.

Syntax

START

Stop

This command is used to end the profiling.

Syntax

STOP

Dump

This command is used to dump the collected profile data to the file tdlprof.log . It also clears the memory once the data is dumped.

Syntax

DUMP

Dumpz

This command is used to dump the collected profile data, including artefacts which have consumed negligible time, i.e., zero processing time, into the file tdlprof.log. It also clears the memory after update to the file.

Syntax

DUMPZ

Status

It checks the status of the profiler, and returns the statement Profiler is ON or Profiler is OFF.

Syntax

STATUS

Reset

This command is used to clear the existing profile data from the Memory.

Syntax

RESET

Help

This command gives the list of Profiler commands, with description of their purpose.

Syntax

HELP

Actions used for Profiling

Apart from Calculator Pane Commands, there are several other TDL Actions provided, to programmatically execute the profiling operations. They are:

Action - Start Profile

This action is used to start the profiling. The Count, Time and other usage information of every function, collection, etc. gathered along with expressions within the report, are profiled in memory.

Syntax

Start Prof i le

Example:

[Button : Start Profiling]

Key    : Alt + S

Action : Start Profile

Action - Dump Profile

This action is used to dump all the profiled information to the file. It also clears the memory after dumping the information.

Syntax

Dump Profile [: <File Name>[: <Logical Value>]]

Where,

< File Name > is the name of the file to which the information has to be written. In the absence of the ‘File Name’ Parameter, the default file updated will be tdlprof.log

< Logical Value > if set to YES, the ‘Dump Profile’ action also includes zero time-taking artefacts. If it is enabled, the action is similar to calculator pane command DumpZ, else it is similar to Dump .

Example

[Button: Dump Profiling]

Key    : Alt + R

Action : Dump Profile : “Profiled @ ” + @@SystemCurrentTime

Action - Stop Profile

This action is used to stop the profiling. If the Optional parameter ‘File Name’ is passed, then information is also dumped into the file, without requiring the action Dump Profile.

Syntax

Stop Profile [:<File Name>]

Where,

< File Name > is the name of the file to which the information has to be written.

Example

[Button : St o p Prof i ling]

Key    : Alt + T

Action : Stop Profile

Functions used for Profiling

The following function has been introduced to support profiling:

Function - $$IsProfilerOn

This function is used to check the current status of the TDL Profiler. It returns logical value TRUE, if the status of the profiler is ON.

Syntax

$$IsProfilerOn

Example:

[Function : Switch Profiler OnOff]

10 : If : $$IsProfilerOn

20 : Stop Profile

30 : Else

40 : Start Profile

50 : End If

Expression Diagnostics

This will help the developers to debug the TDL Program much faster by evaluating the complex expressions and logging the values evaluated at every stage. In other words, this feature would provide the breakup of the expression, the result of each sub-expression, as well as the expression which has failed to evaluate.

The steps to get the Expression Diagnostics information are:

Start the Expression Diagnostics

Execute the desired Report

Dump the information and/or Stop the Expression Diagnostics with the file name.

The dum p ed de b ugger informati o n, when opened in Tex t pa d , is as shown below:

Figure_4._Dumped_Debugger_Information_(4.6).jpg

As seen in the figure, each expression in the developer’s code, as well as the default codes are evaluated and the result values are shown for the purpose of debugging. If any expression evaluation fails, the Result would display as Failed.

Commands used for Expression Diagnostics

The C a lculator pa n e c o mmands used for Expression Diagnostics a r e as foll o ws:

Debugger Mode

This sets the mode to Debug, which means that any Debugging Commands will be accepted. It provides certain calculator pane commands in the hands of developer in order to diagnose the errors in the code, as well as to evaluate and/or set the values to the environment variable.

Syntax

MODE: Debug

Figure_5._Issuing_Debugging_commands_in_the_Calculator_Pane_(4.6).jpg

Once mode is set to Debug, commands issued in the Calculator Pane will work in Debug Context.

Start

Start command is used to start diagnosing the data. Subsequent to issuing this command, when any report is viewed, the data will start gathering every expression along with their values, and will be updated in the log file later.

Syntax

START

Dump

This command dumps the collected Expressions data to the file tdldebug.log . It also clears the memory.

Syntax

DUMP

Status

This command is used to check the status of the debugger and returns the statement Expression Debugger is ON or Expression Debugger is OFF.

Syntax

STATUS

Eval

This calculator pane command is used for evaluating an expression.

Example

EVAL : ##SV F romDate

In t h is exampl e , the value of SVFromDate will be returned in the Calculator Pane .

Set

A variable value can also be set from within a Calculator Pane. This feature helps the developer to set the variable value in the Calculator Pane itself and check the behavioral change. This will speed up the testing process of the Developer by not requiring him to write the code, create an interface element to alter the variable values, and then check the same.

Example

SET : DSPS h owOpeni n g : Y es

This will set the value of the variable DSPShowOpening . For instance, prior to viewing Trial Balance, one can set the value of this variable in the Calculator Pane and the Trial Balance will be displayed with the Opening Column.

Print

Print displays the value of a system variable.

Example

Print : SVFromDate

This will return the SVFromDate value.

Reset

This command is used to clear the existing diagnosis data from Me m ory .

Example

RESET

Stop

This command will stop further diagnosis of d a ta.

Example

STOP

Help

This gives the list of Debug commands, with description of their purpose.

Example

HELP

Actions used for Expression Diagnostics

Apart from Calculator Pane Commands, there are several TDL Actions provided to programmatically execute the debugging operations. They are:

Action - Start Debug

This action is used to start debugging. All expressions evaluated would be debugged. The information collected can be dumped to a file anytime.

Syntax

Start Debug

Example

[Button : Start Debugging]

Key    : Alt + D

Action : Start Debug : “Debugged @ ” + @@SystemCurrentTime

Action - Dump Debug

This action is used to dump all debugging information to the file. It also clears the diagnosis data from the memory, once dumped.

Syntax

Dump Debug: <File Name>

Where,

<File Name> is the name of the file to which the information has to be written.

Example

[Button : Dump Debugging]

Key    : Alt + E

Action : Dump Debug : “Debu g ged @ + @@Sy s temCurr e ntTime

Action - Stop Debug

This action is used to stop debugging. If the file name is passed, then the information is also dumped into the specified file.

Syntax

Stop Debug [: <File Name>]

Where,

< File Name > is the name of the file to which the information has to be written.

Example

[Button: Stop Debugging]

Key : A l t + O

Action : S t op Debug : “De b ugged @ + @@ S ystemCu r rentTi m e

Functions used for Expressi o n Diagnost i cs

The following function has been introduced to sup p ort Debug g ing o perations:

Function - $$IsDebugg e rOn

This function is used to check the current status of the Expression Debugger. It returns logical value TRUE if the status of the Debugger is ON.

Syntax

$$IsDebuggerOn

Example

Inactive : N O T $$IsD e bugger O n

Key Recording and Playback

The recording and playback features will allow the developers to record all the keyboard keys and later play/replay them, as and when required.

This will help the developers to automate and replay certain keystrokes repeatedly during testing of the code for various performance testing needs, as well as while debugging a project, and automate multiple steps required to do the needful.

The steps to get the Key Recording done are:

Start the Recording

Navigate through the sequence of key strokes

Dump the Recorded information

Stop the Recording

The dumped recorded information when opened in Textpad, is as shown below:

Figure_6._Dumped_Recorded_Information_(4.6).jpg

As seen in figure, the macros are appended to the file macros.log within the application path. Comma-separated Keys are written in the file against each macro name separated with the separator symbol specified while dumping the macro from the memory to the file.

Commands used for Key Recording and Playback

The following Calculator Pane Commands are supported for Key Recording and Playback:

Record Mode

Record Mode gives various commands to help the developer in recording keys. The mode should be set by specifying the mode as Record.

Syntax

MODE : Reco r d

The following commands can be specified in the Calculator Pane once the Mode is set to Record:

Start

This command is used to start recording a macro.

Syntax

Start[:<M a cros name>]

Where,

< Macros name > is the name assigned to a macro. In the absence of a Macro Name, it is defaulted to the name Macro.

Example

START : BSView

Replay

It is used to replay the recently recorded macro from the memory, but before the same is dumped into a file. If the macro is already dumped into a file, the same is cleared from the memory and will not be available for Replay. The macro from the file can then be replayed using File I/O Approach and Action ‘Trigger Key’ (explained later), but cannot be replayed through Calculator Pane.

Syntax

REPLAY

Pause

This command is used to pause the recent recording.

Syntax

PAUSE

Resume

This command is used to resume the recently paused recording.

Syntax

RESUME

Dump

This command is used to dump the recording to the file macros.log . The macro name will be separated from the keys with the ‘separator character’ specified as the parameter. It also clears the keys in the memory.

Syntax

DUMP[: ~]

Stop

This command is used to stop recording the recent macro.

Syntax

STOP

LS

This command is used to list the macros which are recorded and available in the memory. The dumped macros will not be listed as they are cleared from the memory as soon as they are dumped in the file.

Syntax

LS

Help

This command provides a list of all the recording commands, with description of their purpose.

Syntax

HELP

Note:

To reset command prompt to regular behaviour, you need to mention MODE.

To perform all the above actions or Calculator Pane Commands, Tally must be executed in DevMode.

Actions used for Key Recording and Playback

Apart from Calculator Pane Commands, there are several TDL Actions provided to programmatically execute the Key Recording operations. They are:

Action - Start Recording

This action is used to start recording every key entered in the memory, with the specified macro name. In the absence of optional parameter Macro Name, default name assumed will be ‘Macro’.

Syntax

Start Recording[ :<Macro Name>]

Where,

< Macro Name > is the name of the macro to be recorded in memory.

Example

[Button: Start Recording]

Title   : "Start"

Key     : Alt + C

Action  : Start Recording : "BS View"

Action - Pause Recording

This action pauses the recording, which can be resumed further. For instance, while recording multiple Vouchers, we might have to run through the Report to check the Number of vouchers, Amount, etc., and then resume recording the Vouchers.

Syntax

Pause Reco r ding

Example

[Button: Pause Recording]

Title  : "Pause"

Key    : Alt + U

Action : Pause Recording

Action - Resume Recording

This action resumes the paused recording.

Syntax

Resume Rec o rding

Example

[Button : Resume Recording]

Title  : "Resume"

Key    : Alt + M

Action : Resume Recording

Action - Dump Recording

This action dumps all the recordings to a file with the given separator. Each recording is dumped with its name and keys. This also clears the keys in the memory.

Syntax

Dump Recor d ing : <Macro Name> : <Separator between keys>

Where,

<Macro Name> is the name of the macro record e d in memory.

<Se p a r a tor betw e en ke y s> is the se p arator to be u sed b etween t he recordi n g name and ke y s.

Example:

[Button : Dump Recording]

Title : "Dump"

Key : Alt + G

Action : Dump Recording : “BSView” : “,”

Action - Stop Recording

This action stops the recording.

Syntax

Stop Recor d ing

Example

[Button : St o p Reco r ding]

Title : " Stop"

Key   : Alt + N

Action : S top Rec o rding

Note: The recordings once dumped in a file against a name using the above actions, can be replayed by reading the file using File I/O approach and Triggering the keys in a loop using the Action ‘Trigger Key’, which will be covered ahead.

Action - Trigger Key

When the macro keys are recorded using Key Recording Actions or when they are dumped into the Macros File from the Calculator Pane Command; in order to play them back, one needs to make use of the Action Trigger Key, which sends the list of keys in sequence to the system as if an operator is pressing those Keys. The Keystrokes of a required macro can be copied from Macro Log file and pasted against the ‘Trigger Key’ Action, which triggers all those Keys in sequence as required.

Also, Trigger Key accepts a value with Inverted Quotes, which means - trigger this as a value in the current field. For example, V, “Cash”, etc. If the triggered keys enclosed within quotes (“ ”) are executed from a menu, they will be considered as menu keys. For example, “DAS” from Gateway of Tally menu will take the user through Display > Account Books > Sales Register .

Syntax

Trigger Key : <Comma Separated Keys/Values>

Example

Trigger Key : V, F5, Enter, "Cash", Enter, "Conveyance", Enter, "50", Ctrl+A

Functions used for Key Recording

The following function has been introduced for key recording:

Function - $$Recorder Status

This functi o n is used to check the s t atus of the recorde r . It returns a S tring value t o indicate wheth e r it is in S t arted, Stopp e d or Paused mode.

Syntax

$$RecorderStatus

Onscreen Tooltip

At times, it becomes difficult for the developer to navigate through the default TDL and identify the fields that are used in the target report. Hence, the Onscreen Tooltip feature has been provided for the developers, who can identify the Field/ Report Names by placing the mouse pointer wherever required.

This behavior will work only in Developer Mode which means that the Tally Application must have started with a Command Line Parameter / DevMode .

As seen in the following screen capture, the Field Name is displayed as a Tooltip, when the cursor is pointed on the desired field within the Report.

Figure_7._Field_Name_displayed_as_Tooltip_when_cursor_points_to_a_Field_(4.6).jpg

In the next screen capture, it can be seen that the Report Name is displayed as a Tooltip, when the cursor is not pointed on any of the fields within the Report.

Figure_8._Report_Name_displayed_when_the_cursor_does_not_point_on_a_Field_(4.6).jpg