• Jim Beers

Create a DevExpress Executable for Dynamics GP

The first step to using DevExpress reports with Dynamics GP is creating a mechanism to view your reports. This can be done by creating Windows applications in Visual Studio, and integrating these with the DevExpress XtraReports suite. This post outlines some key DevExpress events related to creating a reporting application. A full solution can be viewed here

With DevExpress, reports can be generated from a report definition stored in a file or database, or by referencing an XtraReports class from a dll, which is the approach we've used in this tutorial.

Create a Report Class Library

To add a report class library to an application, open the project solution in Visual Studio

Right-click the solution in the solution explorer panel>Add>New Project...

Under Visual C#>Windows Classic Desktop select Class Library (.NET Framework) and name it "Reports". Click OK.

With the project now visible in the Solution Explorer, delete the automatically generated class, and add a new DevExpress report class to the project.

Right-click the Reports project node>Add DevExpress Item>Report Wizard...>Provide a name for your report and click OK. This will launch the DevExpress Report Wizard dialogue.

The benefit of adding reports in this manner is that the project’s references will be automatically updated to reference the assemblies required by DevExpress, rather than having the developer handle this manually (though this is an option as well).

The final step is to create a reference to our report class library from our WPF project (the window we'll launch from Dynamics GP).

Under the WPF project node, right-click References>Add Reference...>Select Projects>In the main panel, select Reports and click OK. Rebuild the solution to make sure there weren't any errors.

With our project set up, we can now look at how to generate a report, and view the result in a print preview at runtime.

Modifying Report Values at Runtime

The main thing to understand about modifying reports at runtime is that as long as the data source schema remains the same between design time and runtime environments, the report's data-bindings will be dynamically updated.

We’ll design our application to generate a report document using the design-time report query, (to adhere to the rule outlined above), but modify the database connection and query parameters to reflect our runtime environment.

The Database Connection

Specifying connection details at runtime is done by modifying a report’s DataSource property. While there are several ways to connect to a SQL database using DevExpress, we’ve found the best approach for our application is to access a connection string stored in the application’s configuration file, and modify the report’s DataSource property when the report is requested.

To do this, we’ll handle the report’s DataSourceDemanded event in the report’s main class declaration. Because DevExpress opens reports in the report designer by default, the class file is accessed as followed:

Open the report in the report designer within Visual Studio>right-click anywhere on the report document>select View Code.

In the event handler, we’ll access the configuration file using Microsoft’s ConfigurationManager class as follows:

string connectionString = ConfigurationManager.ConnectionStrings["localhost_TWO01_Connection"].ConnectionString;

We’ll then use this connection string to instantiate a new DevExpress CustomStringConnectionParameters object.

CustomStringConnectionParameters connectionParameters = new CustomStringConnectionParameters(connectionString);

Finally, we’ll set the report’s current DataSource property—the data source object defined when the report was designed—to use our newly created connection parameters, and then rebuild the query’s result schema (this only effects client-side data, not the servers database schema).

sqlDataSource1.ConnectionParameters = connectionParameters;


The Query Parameters

To modify a report's query parameters at runtime, you access a report object's parameter fields after the report is instantiated. In our case, we call our report object from a button click, so we’ll update parameter values in the button’s event handler.

//Event Handler for 'View Report' Button

private void LaunchReport1_Click(object sender, RoutedEventArgs e)


//Retrieves the user's GP user ID, to execute the

//the stored procedure called below


//Call to execute a Project Cost stored procedure

//that populates the table accessed by our report with

//temporary values


//Instantiates the Project Model report object

XtraReport report = new ProjectModel();

//Sets the values for the report's query parameters,

//which were defined when the report was designed

report.Parameters["ProjectId"].Value = selectedProjectId;

report.Parameters["UserNumber"].Value = userID;

//Opens a print preview of the newly generated report document

//using the DevExpress ReportPrintTool class

ReportPrintTool pt = new ReportPrintTool(report);



The value of the ProjectId parameter is set to the project ID selected from the WPF ListBox.

The UserNumber value is set to the user number (a value used by the Dynamics GP Project Cost module to identify a GP user) that will be passed as a command-line argument when the application’s executable is launched from within Dynamics GP.

Creating the Executable

To ensure we’ll be able to call the executable file from Dynamics GP, I added test parameters to the project’s properties within VisualStudio.

I then pass these command-line arguments to my ProjectLookup window via its constructor.

The window is constructed in the application’s default App.xaml interaction class, and is the default entry-point for a WPF application created in Visual Studio.

The following snippet is from the AppStartup method in App.xaml.cs:

int userNumber = Convert.ToInt32(args.Args[0]); string projectID = args.Args[1]; string budgetID = args.Args[2]; string rateID = args.Args[3]; mainWindow = new ProjectLookup(userNumber, projectID, budgetID, rateID);


Please note there’s a lack of error handling in this snippet, but for clarity’s sake, we’ve chosen not to include it. The values passed are the values used to update the report’s data access properties as described above (mainly the query parameters).

Finally, to generate the executable, rebuild the project solution, and access the executable from the project’s bin directory.

To see how to launch this program from Microsoft Dynamics GP, follow this tutorial

37 views0 comments