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.
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.
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.
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.
The following attributes are supported in this definition:
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.
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.
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.
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.
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.
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.
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
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.
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 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:
.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.
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:
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:
.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.
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
.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
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
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
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:
.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.
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
.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 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
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
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
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:
.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.
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.
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
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
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.
.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.
.jpg)
