Sneak Peek: The new Script Editor in XtraReports v2009.3

27 November 2009

A few weeks ago I published a blog post about the new report designer in our reporting product. This is due to be released very soon and, to be honest, for such a great feature, my post left a little to be desired in terms of details. Alex, who writes for the XtraCharts and XtraReports teams, thought it would be a good idea for me to interview members of the development team and get them to reveal more about the new XtraReports.

Axel2 In this second article, he hooked me up with Alexey Zhukov (whose handle is Axel Z in the forums), and Alexey talked about the new script editor he implemented.

(Aside: First, a quick bit of background about the scripting feature. Scripting in XtraReports is the capability to write custom event handlers for any report control, band, or even the  report itself. This capability is primarily intended for end-users, who can write scripts (C# or VB) in the End-User Report Designer to perform complex operations that are not natively supported by the XtraReports engine. You can add scripts not only in the End-User Designer, but also in the Visual Studio Report Designer since they are the same thing under the hood. Sometimes it is better to write scripts rather than write ordinary event handlers at design time, because the ordinary event handlers are lost when a report is saved to a REPX file, whereas scripts are saved along with it. So, all in all, scripts are an important feature of XtraReports.)

On the seventh day of DevExpress Christmas, Julian showed me screenshots of the new end-user report designer for XtraReports - very nice!

JMB: So, what prompted this work on the new Script Editor?

Axel Z: Did you ever use the old one? It was just totally inconvenient. Imagine that you wrote a script three months ago. Today you come along to make a change and you realize that you've totally forgotten all the details about it. Your issue is now doubled, trebled: how can you find information about it, where it's found, for which event of which control or controls it was written? Before v2009.3, to answer these questions you were forced to select each control at design time, look at the Scripts.* properties in the Property Grid, and if there was something there, double-click it and we would invoke the Script Editor dialog for this property so you could then read and explore the code.


And what would you do if a report contained 100 or more report controls? Which control would you select first? How would you make sure you went through them all? To be honest, it's a nightmare and a very ugly user experience. We should apologize to our customers who'd suffered from this before.

JMB: Er, OK. Sorry, everyone, we should have fixed this experience a while back. So, go on, how did you fix it?

Axel Z: Simple, really. First, the good news for those who liked the old behavior — it's still totally supported in v2009.3. You can continue to locate the Scripts.* properties in the Property grid and double-click on whichever property has code to see it. However, from v2009.3 onwards, you'll not only see the code for the script you selected, but you'll also see all the other scripts in this report around it.

Even easier though, you can also see this script on the new Scripts tab, because all the scripts are now displayed within the same tab. And the names of these methods indicate which controls and which events are handled by these scripts. There's no need to hunt and peck any more.


JMB: Nice. What other issues have you targeted with the new Script Editor?

Axel Z: Go back to v2009.2 again, and imagine you'd written some scripts but there was a mistake in your code. Unfortunately, there's no way for you to know about it until you run the Print Preview. And in order to generate the preview, you must first to populate the report's datasource with data, which may be a rather time-consuming operation. So, imagine that you did all this, waited for a couple of minutes until all the data was loaded and then, OMG, it crashes because you have an error in your scripts!

JMB: All right, that's pretty annoying, I must admit. If we have attentive readers, they will have spotted the answer already, but go ahead and explain.

Axel Z: Sure. It's the Validate button on the top right corner of the editor. You write some code, you press Validate, and, if there is a bug, you'll get the list of all the errors in all of the event handlers at the bottom of the designer panel in the Scripts Errors panel.


The messages display informative descriptions of the errors, as well as line and column values for where this error was found. Note that double-clicking an error in this grid will automatically navigate you to the correct place in the code.

Of course, if there are no errors in your scripts, you'll simply get a confirmation that everything's fine.


JMB: Very nice. Are there any other benefits now we have all the scripts in one place?

Axel Z: One of the problems of the old way of doing things is that it was pretty impossible to share script code between event handlers. There was a hacky way of doing this: you basically placed some code outside the event handler like this:


But the issue then became which script was loaded first? And if you forgot the name of the variable, you were then faced with a game of hunt-the-variable-or-method through all the possible Script properties.

JMB: I can see where you're going with this...

Axel Z: Right. Now, you have all the report scripts in the same editor. It becomes much easier for you to organize your code as you wish, in a way similar to how you write code in the Visual Studio code editor. You don't have to go look for code: it's all there in front of you. Writing event handler code that shares data and methods with other event handlers is much, much easier.


JMB: Very cool indeed. Anything else you'd like to say?

Axel Z: There were some features of the new script editor that we just didn't have time for for v2009.3, but that we'll start to address in 2010. The most obvious of these is syntax highlighting, but there's also things like spell-as-you-type, and so on.

JMB: Thanks, Alexey, for talking to me and showing us the new Script editor.

Axel Z: My pleasure. Come by again in the v2010.1 timeframe and I'll show you some more.

13 comment(s)
Steven Rasmussen

Very cool!  As far as the syntax highlighting goes, sounds like maybe you could merge the XtraRichEdit in there somehow and then the XtraRichEdit could be used as a code editor???  I don't personally have a use for this but I know that several people have asked about this type of feature for the XtraRichEdit, I figure that as long as you're working on it for one product, why not incorporate it into another... :)

27 November, 2009
Sigurd Decroos

Please add line numbers before the text. Intelisence would be nice too, a lot of customers are not the best .Net developers :)

27 November, 2009
Hans Nieuwenhuis

This is a very good enhancement/replacement! Will save a lot of time.

27 November, 2009
Julian Bucknall (DevExpress)

Steven: the problem about doing that is that XtraReports does not come with the XtraRichEdit editor. Either we add it and jack up the price, or we make customers purchase the extra product when they use XtraReports. Either way, it'll be somewhat unpalatable... Smile

Cheers, Julian

28 November, 2009
Sigurd Decroos

You could alwyas make a stripped down version of the RichEdit and use it as a Code Editor. You don't need images and tables in a code editor. And Fontstyles are also not needed I guess :)

28 November, 2009
Michael Proctor [DX-Squad]

JMB: Re: XtraRichText implementation, not sure how it all works however if you don't include the Design time libraries for the RichTextEdit couldn't you still implement it's use without giving development capabilities to the Dev with the XtraReports?

28 November, 2009

@JMB, Axel Z: First of all - thank you for these features, vital and very welcome. Very Good Job.

Intellisense and Line Numbers ---> Make sense. I have experienced this on my own ...  getting to know the reporting environment the "components" via "Intellisense", while programming is no longer a nice to have. People work this way. --> It will and can take some time for sure, but in a mid term view I think this is required.


29 November, 2009
Robert Fuchs

Strong vote for Syntax Highlighting, Intellisense and Line Numbers.

See and try SnippetCompiler:

30 November, 2009
Mark Prichard

Thank you for this improvement. I look forward to using it. I have been as frustrated as Axel said at having to select each control, and open each Script Editor individually. Productivity ++

4 December, 2009
Ben Charron

Again, this looks good and will make scripting easier for developer and end user.

Another strong vote for Intellisense and Line Numbers. Line numbers for sure since script errors report on line numbers and it could be a long count!

4 December, 2009

Believe that this is the best update they've made in the reports. It's really a great help for the generation of complex reports.

29 January, 2010

Please don't show control type in lookup Like MS Visual Studio.

It is very noisy.

Control name is enough.


10 March, 2010

It is helpful that improvement

3 October, 2010

Please login or register to post comments.