Explore Categories

 

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 Component Object Model (COM) is a component software architecture that allows applications and systems to be built from components supplied by different software vendors. COM is the underlying architecture that forms the foundation for higher-level software services. These DLLs provide the standard benefits of shared libraries. Component Object Model (COM) was introduced by Microsoft to enable inter-process communication and dynamic object creation across a varied range of programming languages. In other words, objects can be implemented in the environment t s seamlessly different from the one in which they are created. This technology specifies manipulation of data associated with objects through an Interface. A COM interface refers to a predefined group of related functions that a COM class implements. The object implements the interface by using the code that implements each method of the interface and provides C OM binary-compliant pointers to those functions, to the COM library. COM then makes those functions available to the requesting clients.

COM DLL Support will pave t h e way for providing features like ‘Tally For Blind’ using the generic speech API provided by Microsoft. This Release comes with enhanced capabilities in the language to support COM D L L processing. A new definition type called COM Interface has been introduced for the same.

This capability has been introduced in Tally.ERP 9 Release 4.6

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 MathClass

{

public double Add(double pDouble)

{

return pDouble + 9;

}

public int Divide(int Dividend, int Divisor, out int Remainder)

{

int Quotient ;

Quotient = Dividend / Diviso r ;

Remainder = Dividend – (Divisor * Quotient); return Quotient;

}

public void datefunc(ref DateTime date)

{

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 the DLL

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

Example:

regasm/Code Base <DLL Name with absolute path>

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\Frameworkv4.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

  •  Go to folder where 64-bit windows Microsoft.net framework. Generally, the Microsoft.net framework is available at C:\Windows\Microsoft.NET\Framework64 .
  • Choose the latest version of .NET Framework.
  • Copy the folder path where the regasm.exe is available. For example, C:\Windows\Microsoft.NET\Framework64\v4.0.30319 .
  • Open Command Prompt in administrator mode.
  • Replace the path using the command: cd /d C:\Windows\Microsoft.NET\Framework64\v4.0.30319 .
  • Place the DLL in Tally.ERP 9 folder and copy the entire path.
  • 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 Tally.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:
    • InOut Parameter will send the variable value to the Interface as input, and in r e turn, will bring back the value altered by the Interface.
    • OUT Parameter , will only 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.

  1. 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.

  1. 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.

  1. 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 Application 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:

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

Once the 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 . This 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 a 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 profiling. The count, time taken and other useful information of every function, collection, etc. gathered along with expressions within the report, are profiled in memory.

Syntax

Start Profile

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 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 : Stop Profiling]

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 dumped debugger information, when opened in Textpad , is as shown below:

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 Calculator pane  commands used for Expression Diagnostics are as follows:

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 the 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

 

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 : ##SVFromDate

In this example , 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 behavioural 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 : DSPShowOpening : Yes

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 a 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 : “Debugged @ ” + @@SystemCurrentTime

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 : Alt + O

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

Functions used for Expressi o n Diagnostics

The following function has been introduced to support Debugging operations:

  • Function – $$IsDebuggerOn

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 : NOT $$IsDebugger On

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:

As seen in the 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 : Record

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[:<Macros name>]

Where,

<Macros name> is the name assigned to a macro. In the absence of a Macro Name, it defaults 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 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 Recording

Example

[Button: Pause Recording]

Title : “Pause”

Key : Alt + U

Action : Pause Recording

Action – Resume Recording

This action resumes the paused recording.

Syntax

Resume Recording

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 memory.

Syntax

Dump Recording : <Macro Name> : <Separator between keys>

Where,

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

<separator between keys> is the separator to be used between the recording name and keys.

Example:

[Button : Dump Recording]

Title : “Dump”

Key : Alt + G

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

Action – Stop Recording

This action stops the recording.

Syntax

Stop Recording

Example

[Button : Stop Recording]

Title : ” Stop”

Key : Alt + N

Action : Stop Recording

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 function is used to check the status of the recorder. It returns a String value to indicate whether it is in Started, Stopped 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 behaviour 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.

In developer mode, 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.

Release 4.61

COM Data Types Support

In Release 4.6, a new Definition Type COM Interface, a new Action Exec COM Interface, and new Functions $$COMExecute and $$IsCOMInterfaceInvokable had been introduced to extend Support for COM Servers. However, this support was limited to only a few COM Data Types.

From Release 4.61 onwards, the following COM Data Types will also be supported:

COM Data Type

TDL Data Type

Other Permissible TDL Data Types

Range of Values/Other Details

String

String

Number, Date,

Logical, Amount

 

Float

Number

String, Amount

3.4 * 10^-38 to 3.4 * 10^38

Double/Number

Number

String, Amount

1.7 * 10^-308 to 1.7 * 10^308

Currency/Amount

Amount

String, Number

This would have a precision of 4 decimal places, rather than 5, as in Tally.ERP 9. If Tally sends the number in 5 decimal places, DLL will round it off to 4 decimal places.

Char

String(1st character of String is used)

Number, Date, Logical, Amount (Only the First letter) For e.g., if the number is 987, then the result char would be 9 and similarly, for the other data types. For Date, it depends on the Date Format.

Single Character

Byte/Unsigned char

Number

String, Amount

0 to 255

Short/Wchar

Number

String, Amount

-32,768 to 32,767

Unsigned short

Number

String, Amount

0 to 65,535

Long

Number

String, Amount

-2,147,483,648 to 2,147,483,647

Long Long

Number

String, Amount

-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807

Unsigned Long

Number

String, Amount

0 to 4,294,967,295

Unsigned Long Long

Number

String, Amount

0 to 18,446,744,073,709,551,615

Integer

Number

String, Amount

-2,147,483,648 to 2,147,483,647

Unsigned Integer

Number

String, Amount

0 to 4,294,967,295

Bool/Boolean/ Logical

Logical

String (Yes/No, 0/1, True/False)

True/False

Date

Date

String

 

Variant

String, Number, Date, Logical, Amount

 

This can be an Out or InOut parameter. The value for the data type can be any one of the following data types, viz String, Amount, Number, Date OR Logical.

Scode

Number

String

0 to 4,294,967,295

This is a kind of an error code data type, used by Windows API.

The parameters can also be of the Other Permissible TDL data types, as mentioned in the table, in place of the data types mentioned in the column titled ‘TDL Data Type’. Irrespective of whether the parameter is an In, Out OR InOut parameter, Tally implicitly converts these data types to the respective COM Data Types.

In Release 4.6, while declaring the Parameters for COM Interface, only a limited number of data types could be accepted as a data type for the parameter. Let’s understand this with the help of the following example:

DLL Code

TDL Code – COM Interface Definition

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace MathLib

{

public class MathClass

{

public double Add(double pDouble)

{

return pDouble + 9;

}

}

}

[COM Interface : TSPL Smp Add]

Project : MathLib

Class : MathClass

Interface : Add

Parameters : p1 : Number : In

Returns : Number

In the codes shown in the table, the Interface Add of Class MathClass had the Parameter Data type as Double in DLL, while the same had to be mapped to Number as the Parameter Data type in TDL.

From Release 4.61 onwards, the COM Data Types listed in ‘Other Permissible TDL Data Types’ column in the table are also supported. Thus, in this particular example, the data type of the Parameter can also be specified as Double in place of Number, and hence, the same can be rewritten as:

Parameters : p1 : Double : In

However, while invoking the COM Server, the data type must be a TDL Data Type, viz. Number, String, Amount, Date OR Logical.

Example

[Function : TSPL Smp Addition]

Parameter : InputNo : Number

00 : Exec COM Interface : TSPL Smp Add : ##InputNo

10 : Log : $$LastResult

Note: It is not necessary to have the above TDL Data Type as Number. It could also be a String or an Amount. However, the value within the String should be a Number.

Release 4.7

Developer Mode Enhancements

In market, there are customers using Tally.ERP 9 for their day-to-day operations and also developers or partners who build solutions for the customers. To empower the developers of Tally with various tools to builds solutions efficiently, a new capability to operate Tally in the Developer Mode was introduced in Release 4.6. In other words, capability was introduced to operate Tally in two modes, viz., Normal Mode , to be used by the End Users and Developer Mode , to be used by the TDL Developers. Through the Developer mode, a host of Developer Tools have been offered for debugging the code, optimizing the performance of customized reports, recording the user operations and playing them back, etc.

To further enrich the Developer Mode experience, following enhancements have been incorporated in this release.

Output Profiler and Expression Diagnostics Information in Excel Format

Microsoft Excel is widely used in organizations for representing their Tabular data, as it comes with a galaxy of features for data representation. It is, therefore, ideal to output any tabular data in Microsoft Excel format, for easier and better data analysis.

From Release 4.7, the tabular Profiler or Debugger Expression data will dump the information in

Excel Format, to enable the developer to analyze the data with ease. The behaviour will be:

  • If the System has MS Office 2007 or below, then the output format will be ‘.xls’.
  • If the System has MS Office 2010 or above, then the output format will be ‘.xlsx’.
  • If the System does not have MS Office installed, then the behaviour will be the same as in Release 4.6, i.e., the format will be text files.

Thus, the developer can make use of Excel features like sorting, filtering, graphical representation, etc., thereby attaining performance optimization quickly. For example, by sorting the Profiled Information in descending order of Time or Count, the developer can quickly determine the artefact that has taken the longest time or the Collection that has been needlessly gathered multiple times, thus optimizing the performance quickly.

Key Recording and Playback Changes

With respect to Key Recording and Playback, the following enhancements have been done:

Reading Capacity Increased

In Release 4.6, when a Macro gets recorded beyond 2000 characters, it is not possible to read back the characters beyond 2000 using the Function $$FileRead, and play them.

From Release 4.7 onwards, the reading capacity of the Function $$FileRead has been increased to 4000 characters per line.

Splitting of Macros

Again, if the Macro gets recorded beyond 4000 characters, the Function $$FileRead cannot read further, which means that Keys beyond 4000 characters cannot be played back.

Hence, the Macro Recording capability has been enhanced in such a way that after recording 4000 characters, a new macro gets created automatically, and the subsequent keys are recorded in the new macro. The new macro will bear the same macro name, with a number concatenated to it. All the Macros created will be dumped in a single file, and replayed when required. Thus, n number of macros can be recorded in a file, read and played back.

For example, if the Name of the Macro is Testing, then after every 4000 characters, a new Macro is created with the Name Testing-1, Testing-2,…Testing-n. Thus, there is no limit to the number of characters which can be recorded, read and played back.

Action ‘Dump Recording’ with a File Name

In Release 4.6, using the Action Dump Recording, all the Keys, along with the Macro Name, were written to a file Macros.Log, by default.

From Release 4.7 onwards, the Action ‘Dump Recording’ has been enhanced to write the macros to a File specified by the user. The Action ‘Dump Recording’ will accept 2 optional parameters, viz. File Name and Separator.

  • If the File Name is left unspecified, then by default, the Action would dump the recording to the file Macros.log.
  • If the Separator is left unspecified, then by default, the system would consider Tilde (~) as the default separator.

Syntax

Dump Recording [: <File Name> [: <Separator between keys>]]

Where,

<File Name> is the name of the file where macro and keys will be recorded.

<Separator between keys> is the separator used to differentiate the macro name from the keys.

Example

[Button : Dump Recording]

Title : “Dump”

Key : Alt + U

Action : Dump Recording : “BSView.txt” : “-”

On clicking the Button ‘Dump Recording’, a file BSView.txt is created in Tally Application Folder.

Note: The behaviour of Calculator Pane Command Dump is retained as in Release 4.6, i.e., it will create a file with the name Macros.Log in the Tally Application Folder.

Action ‘Trigger Key’ Enhanced

When the macro keys are recorded using Key Recording Actions or when they are dumped into the Macros File from the Calculator Pane; in order to play them back, one needs to make use of the Action Trigger Key, which sends a list of keys in sequence to the system as if an operator is pressing those Keys.

Very often, some keys like Enter, Up, Down, etc., are repeated in sequence more than once. For example, to scroll down to the 7th Voucher in Daybook, one needs to trigger the Down Key 6 times. Similarly, in an Invoice Entry, moving to the first Item field needs multiple hits of Enter key. Hence, the action ‘Trigger Key’ has now been enhanced to support the <Key>:<Number> combination in the syntax, which will trigger the particular Key for the specified Number of times.

Example: 1

Trigger Key : DD, Enter : 5, “Item 1”, Enter

This is the same as:

Trigger Key : DD, Enter, Enter, Enter, Enter, Enter, “Item 1”, Enter

Following happens when the above Action is invoked from Gateway of Tally:

  • The First D navigates us to Display.
  • The Subsequent D navigates us to Daybook.
  • Enter:5 triggers the Enter Key 5 times, i.e., Drills down into the current voucher, accepts 4 subsequent non-skipped fields, and moves to the 5th non-skipped Field in the Voucher.
  • In the Fifth field, the text Item 1 is entered.
  • The Subsequent Enter then accepts the current field, and the focus is shifted to the next non-skipped field.

Example: 2

Trigger Key : DS, Enter:3

This action will take us through Display (D) -> Statement of Accounts (S) -> Outstandings (1st Enter) -> Receivables (2nd Enter) ; the 3rd Enter selecting the first item in the list and displaying all the outstanding bills within it.

Calculator Pane Changes

For the convenience of the developer, certain calculator pane commands have been introduced in this Release.

Command – Mode: ?

Mode: ? will list all the modes available in the Calculator Panel.

Command – Help

From any of the modes, Help command will list down all the supported commands for the particular mode, along with their purpose.

Command – Open

From any of the modes, the Open command will open the most recently logged file. Consider the following examples:

  • If the current mode is Debug, the file being opened will be either debug.xlsx, debug(1). xlsx, debug(2).xlsx, ……. or debug(<n>).xlsx, whichever is the most recent in debugger log. (Depending on the available Excel Version, the file extensions will vary.)
  • If the current mode is Profile, the file being opened will be either tdlprof.xlsx, tdlprof(1). xlsx, tdlprof(2).xlsx, ……. or tdlprof(<n>).xlsx, whichever is the most recent in profiler log. (Depending on the available Excel Version, the file extensions will vary.)
  • If the current mode is Record, the file being opened will be macros.log.

Figure_3._Command_Open_(4.7).jpg

Post a Comment