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

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.

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

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.

Free DevExpress Products - Get Your Copy Today