- Performing a dynamic audit from the development environment
- Starting a dynamic audit during the project test
- Starting a dynamic audit during the automated tests
- Performing a dynamic audit in the deployed application
- Starting a dynamic audit through programming
- Starting a dynamic audit by using the ".WX" file
- Starting a dynamic audit in an application currently run
- Examining a dynamic audit
- Opening the status report of dynamic audit
- Window for analyzing a dynamic audit
- Types of events collected by the dynamic audit
The dynamic audit of an application analyzes its runtime performance. A dynamic audit can be performed in a test environment or on a live application. The audit detects problems such as:
- Excessive memory consumption.
- Slowness of algorithms used.
- Errors "hidden" at runtime.
A dynamic audit can be performed:
Performing a dynamic audit from the development environment
The dynamic audit can be started:
Starting a dynamic audit during the project test
1. Automatic dynamic audit
During each window or project GO, a dynamic audit is performed in background task, without slowing down the execution. When the test is ended, the number of problems that occurred is displayed in the "Dynamic audit" widget of Project dashboard. To see the detailed status report, simply click the widget.
To disable this automatic dynamic audit:
In this case, no audit will be performed during a test via a simple GO: the dynamic audit will have to be explicitly started during the project test.
- Click the widget arrow.
- Uncheck "Dynamic audit enabled".
2. Dynamic audit explicitly started
To explicitly start a dynamic audit during the project test:
- Open the project to analyze.
- On the "Project" tab, in the "Test mode" group, expand "Test mode" and select "Debug project while the audit is enabled". The project starts.
- Handle the project in order to use the features that must be audited.
- Close the application.
The editor opens the report window of dynamic audit. The status report of dynamic audit is also displayed in the "Debugger trace" pane.
Starting a dynamic audit during the automated tests
To start a dynamic audit during the automated tests:
The dynamic audit will be performed when an automated test is run. The report window of the dynamic audit is displayed at the end of test. The status report of dynamic audit is also displayed in the "Debugger trace" pane.
- Open the project to analyze.
- On the "Automated tests" tab, in the "Tests" group, expand "Run all" and select "Enable the dynamic audit during the automated tests".
Performing a dynamic audit in the deployed application
The dynamic audit can be started:
- through programming.
- via the WX file.
- via a key combination.
Starting a dynamic audit through programming
To start a dynamic audit through programming, simply call dbgEnableAudit
The audit generates a ".wdaudit" file. This file must be loaded in the development environment in order to analyze the result.
Remark: To analyze the result of application audit, the project of this application must be opened in WINDEV, WINDEV Mobile or WEBDEV.
Starting a dynamic audit by using the ".WX" file
You can also start an audit of an application in its production environment without modifying the executable: simply create a file in the same directory and with the same name as the executable, but with a ".WX" extension.
This file will have the following format:
ACTIVE = 1 (or 0 to disable the audit)
FILE = <path of the .waudit file to generate>
OPTION = <combination of the options of dbgEnableAudit>
In this file, the OPTION key can take the following values:
- "CA": The audit comments are written into the dynamic audit.
- "WA": The execution warnings regarding the detected anomalies are written into the dynamic audit.
- "WP": The execution warnings regarding performance are registered in the dynamic audit.
- "EA": The assertions are written into the dynamic audit.
- "ER": The non-fatal errors not processed are written into the dynamic audit.
- "EX": The fatal errors, processed by WHEN EXCEPTION or not processed, are written into the dynamic audit.
These options must be preceded by a "+" sign to specify that they must be taken into account. Example: OPTION=+CA+WA+WP
The audit generates a ".wdaudit" file, this file must be loaded in the development environment to analyze the result.
Remark: To analyze the result of an application audit, the project corresponding to this application must be opened in WINDEV or WEBDEV.
Starting a dynamic audit in an application currently run
To start recording a runtime audit, press Ctrl + Alt + A. This shortcut performs the same action as calling dbgEnableAudit
Examining a dynamic audit
Opening the status report of dynamic audit
The status report of the dynamic audit is a file whose extension is ".waudit".
To open this file, you can:
- Open the file in the editor directly: on the "Home" tab, in the "General" group, click "Open" and select the audit file.
- Use the "Dynamic audit" widget of the project dashboard: click the widget arrow and select "Open an audit". Then, select the audit file.
Window for analyzing a dynamic audit
When loading a dynamic audit, the following window is displayed:
- 1: Name of the audit file currently analyzed.
- 2: Period of time during which the audit was performed.
- 3: Selecting the period of time to view. If the audit spans over a long period of time, you can read a specific part of it using a range slider. The range slider covers the entire duration of the audit. The active section of the control (modifiable with the arrow keys) is displayed below. This area can be clicked and it automatically selects the event closest to the moment that was clicked (in the list of events).
- 4: Display mode of audit events. The audit events can be displayed in in a chronological order in the list of events or they can be grouped by family of events
- 5: Filtering button used to choose the types of events that will be displayed.
- 6: List of events displaying all the elements collected by the audit. On each table row:
- a "..." button is used to access the event details.
- if the event is linked to a particular code row, the "Code" button allows you to open the code editor directly at the corresponding location.
- the "-" button is used to disable the error. CAUTION: The error will no longer be displayed if it is disabled. It cannot be re-enabled.
Types of events collected by the dynamic audit
The different types of events collected by the dynamic audit are:
- The exceptions: an exception is a fatal error of the application (unless it is intercepted in a WHEN EXCEPTION block). An exception can be voluntarily generated by ExceptionThrow.
All the exceptions are reported by the dynamic audit (exceptions processed through programming or exceptions that have stopped the application). In most cases, an exception is the result of a programming error.
- Errors: an error can be triggered by a WLanguage function to signal the failure of an operation (for example, fDelete returns an error if the deletion of the requested file failed). The errors can also be triggered by the developer via ErrorThrow.
In most cases, an error is caused by an invalid action of the application user or by a failure in the application environment.
- The runtime warnings: these warnings are reported by some WLanguage functions to signal a potential problematic behavior but that causes no error. For example, if the WLanguage detects a performance problem in the code of the application.
Examples of runtime warning:
- Using zipExtractFile in a loop to extract an important number of files from a Zip or 7z archive is not very efficient. We recommend that you use zipExtractFileList.
- Possible improvements on Chart controls: activation of anti-aliasing, use of labels inside pie sections, ...
- Access to controls not recommended from the secondary threads.
- Low client-to-server send rate. This warning indicates a network performance problem. It appears when opening a connection to a server in HFSQL Client/Server mode if:
- latency is higher than 50 milliseconds,
- a small network frame takes a long time to go back and forth between the client and the server (more than one second for 256 kB).
- Assertions: the runtime audit reports all the calls to dbgAssert in which the condition turned out to be False.
- The debugging events: these events are triggered by the call to the debugging functions (dbgSaveMemoryDump for example).
This page is also available for…