- 5 minutes to read
You can write scripts within report elements’ event handlers to perform custom calculations over your report’s data. Scripts run when the corresponding event occurs (for instance, a mouse click).
The following Report Designers allow you to write scripts:
- Visual Studio Report Designer for WinForms, WPF, ASP.NET WebForms and ASP.NET MVC platforms;
- WinForms End-User Report Designer;
- WPF End-User Report Designer;
- ASP.NET WebForms and ASP.NET MVC End-User Report Designers (if you enable this functionality explicitly).
You can use the XtraReport.ScriptLanguage property to specify the language to write scripts in the report. Report Designers support the following script languages:
- Visual Basic .NET
- JScript .NET
Note that the script language does not depend on the language used to create the report.
Report scripts provide access to the following assemblies:
Core assemblies that all reporting applications reference:
Standard .NET framework assemblies that all reporting applications reference:
Other assemblies that are currently loaded into your application’s domain.
You can enable other assemblies in report scripts. List them in the XtraReport.ScriptReferences property at design time or in the XtraReport.ScriptReferencesString property at runtime. You can specify a path to an assembly as an absolute (full) path or a path relative to the directory where an application runs. All the listed assemblies are loaded into the application domain when report scripts are compiled.
If you modify specific classes in the loaded assemblies, these changes are not immediately applied to the Report Designer. You should reopen the Report Designer to reload assemblies. These changes are applied automatically only if you write scripts in the Visual Studio Report Designer and customize an assembly from the same solution.
A report and every report element has an individual set of script events. For instance, the XRChart control has the XRChartScripts.OnBoundDataChanged event that is specific to this control only, while the XRControl.BeforePrint event is declared at the base control’s level and is applicable to most report controls. The XRControl.Scripts collection provides access to all events that the selected report control supports.
In Visual Studio at design time, you can switch to the Properties window and expand the Scripts property. Select an event and choose (New) in the drop-down list. This opens the Scripts tab and adds the event handler’s template. This template uses the language that the XtraReport.ScriptLanguage property specifies.
The Scripts tab contains all scripts written for all report elements. You can choose a report element from the drop-down list on the left, and an event from the drop-down list on the right. This adds a new handler if it does not exist yet or navigates to the corresponding event handler if it is already specified.
You can write any code in scripts (declare new classes, variables, methods, etc.) except for the using-like directives.
Click the Validate button to check for errors in report scripts.
The Error List panel lists all found errors.
Click an error in the panel to navigate to the line that contains this error.
Refer to Debug Scripts in Visual Studio for information on how to debug report scripts.
If you handle a report control’s event in code behind and write a script for the same event, the event in code behind is executed after the script event.
Intelligent Code Completion
Script editors support intelligent code completion for the C# and Visual Basic .NET script languages. Context-aware hints are displayed when you type a dot or press CTRL+spacebar.
The WPF End-User Report Designer does not currently support this feature.
In the Visual Studio Report Designer, intelligent code completion always requires Internet connection and supports only .NET Framework and DevExpress libraries deployed with the application.
For End-User Report Designers, you can either connect your machine to the Internet or register the local code completion engine (it also supports types defined in custom assemblies).
Do the following to activate the local code completion engine in your end-user reporting application:
Right-click the References node in the Solution Explorer and select Manage NuGet Packages in the invoked context menu.
Select DevExpress 19.1 Local in the Package source drop-down list and go to the Browse page. Find the DevExpress.Reporting.CodeCompletion NuGet package and install it.
Call the CodeCompletionRequestManager.UseLocalEngine method at application startup.
The local engine requires a storage for report layouts. You can use the predefined storage (the FileCodeCompletionContextStorage or InMemoryCodeCompletionContextStorage class) or provide your custom storage.
The UseLocalEngine(ICodeCompletionContextStorage) method accepts a storage object as a parameter.
The following code demonstrates how to pass the FileCodeCompletionContextStorage instance to store report layouts in the specified folder.
using DevExpress.XtraReports.CodeCompletion; using DevExpress.XtraReports.CodeCompletion.Storages; CodeCompletionRequestManager.UseLocalEngine(new FileCodeCompletionContextStorage("D:\\CodeCompletionContext"));
You can also implement the ICodeCompletionContextStorage interface, create its instance and pass it to the method as the parameter.
To disable intelligent code completion, set the static SyntaxEditor.EnableCodeCompletion property to false.
Script Processing Mechanism
The reporting engine processes scripts as follows:
Generates a temporary class in memory.
Adds variables that correspond to the following items:
- report bands;
- report controls;
- calculated fields;
- formatting rules;
- data sources.
The item’s Name property value defines the variable name. An exception occurs while the script run if you do not specify the Name property.
If the script code already contains a variable with the same name as a report item, a variable for this item is not generated. This functionality requires the DevExpress.CodeParser.v19.1.dll assembly. If this assembly is not added to the project’s reference list, a compilation error is raised.
Cuts the using-like directives from the script code and adds them to the namespace that contains the temporary class.
Places all the report scripts to the temporary class as methods.
Compiles the resulting class in memory.
Calls this class’s methods to execute the corresponding report scripts.