ctodx

This Blog

News

Favorite Posts

Archives

November 2009 - Posts

  • Are you ready for the 2010 XAF roller-coaster?

    Recently (and maybe not so recently as all that too), customers have been voicing worries about the direction we've been taking eXpressApp Framework (XAF), some even going so far as to say there is none. Roman, Gary, Oliver and I had a long chat via email about the situation and decided that what was needed was a post about what we're doing, about the support in the company for it, and what you can expect in the near and middle future. In short: very rosy indeed.

    Inching up before the wild ride First, a little historical background to understand where we're coming from. XAF development was started in early 2004, based on some work done on an insurance line-of-business project written in Delphi. From the start, then, it has been geared to real-life projects. The first goals were simple: create a persistent object framework and a WinForms MVC presentation framework. For one reason and another, the persistent object framework had to be done first — in essence building XAF from the bottom up — so that we could then test our MVC and business object layers as early as possible. When it was good enough for our purposes, we decided to release it as a separate product: eXpress Persistent Objects (XPO).

    After that, obviously, XPO started to live its own life. It got its own team (the original designers, in fact), and much effort was invested to respond to feedback and to satisfy requirements from all customers, not just from the XAF team.

    By late 2005, DevExpress' R&D were suffering from some growing pains: the developers were being spread far too thinly across all our product lines. We reorganized what we were doing, reevaluated what products we should concentrate on for the short term, and revamped the targets for the following year.  As a result, the XPO developers were moved back onto the WinForms team and, in time, they became responsible for new WinForms products. It was at about that time that Oliver joined us.

    In early 2006, the XAF architecture was pretty much established, all the basic components were implemented, and so we released a CTP to collect feedback on what we'd done. The feedback was, to put it mildly, rather positive. Also in early 2006, an internal team successfully used XPO as a base for our internal systems (ClientCenter, sales system, SupportCenter), and used XAF as the backend UI. (In other news, I joined DevExpress right about the same time. Coincidence?) By the end of 2006, XAF was released as a part of the DXperience v2006.3 release.

    During 2007, from v2006.3 to v2007.3, the XAF team were working on implementing various feature requests from customers who were trying to use XAF to create real apps. Also in the final release of the year, XAF got design-time support. In 2008, the team released various new small and medium-sized features and XPO finally got its own team back. Roman decided that the XAF architecture needed to be changed in order to abstract XPO, so the Domain Components (DC) approach could be possible. He started working on designing the DC technology describing what we needed to do as a series of posts (1, 2, 3, 4, 5, 6, 7). The first major refactoring, the type information system, was completed for v2008.3. I'd have to say that our original goals for XAF were finally met in 2008: make the simple things simple, and the complex things possible.

    Also, at around that time, a year ago, I would say that XAF support and maintenance levels reached full bore. Some of our customers had reached the final cycles of their app development, so now we were getting a full range of support questions from the beginner to the advanced XAF developer.

    At the end of 2008, we took stock of the situation:

    • We had some strong momentum in the customer take-up of the product. Reviews and feedback were favorable.
    • XAF needed many more improvements at every level in order to become a better business app framework.
    • Even with its current feature set, we barely had enough resources to add new features, due to the support/maintenance bottlenecks.
    • The team's desire to help out and implement customer suggestions often led to local hacks instead of beneficial changes that improved the overall architecture. (Roman's current WAG is that 30% of XAF code can easily be removed without any loss of functionality.)

    So, changes were needed in 2009. The first steps were organizational, and mostly happened in the v2009.2 timeframe:

    • We hired more developers. We currently have 24 people over both the XAF and XPO teams. (This number includes tech writers and support engineers too, note.)
    • We put everyone in XAF on the same floor of the building. (Like, duh.) Everyone is now within reach of everyone else in the team.
    • We split the XAF team into several subteams — Core, UI, Base, Data, App — to make code ownership easier and create better architectural boundaries.
    • Andrew, one of our most senior developers, joined the XAF team in the summer. He spent quite some time with the new developers we were hiring doing research efforts on MVC and XAF so they could learn how we work, what we do, and what needs to be done and how.
    • We started a series of design review sessions where the whole team analyzed what should be changed in order to reach new goals.

    Now we all know that adding more people to a project or team does not immediately help. In fact, it does the exact opposite: it slows everything down at first. That's why XAF progress has been slight over the past couple of releases: lots of minor changes, no real major changes. Our main goal was to make v2009.3 the best version of the "old-style" XAF: that is, don't break anything, make many smaller improvements, and keep the radical changes for 2010. Since code freeze, we've been making many simplifying refactorings for v2010.1, basically anything and everything that will reduce complexity without losing functionality. XAF is now poised to take advantage of some stronger momentum.

    With regard to 2010, we have to deliver on Roman's DC plans. The team is poised and ready, but this will inevitably mean breaking changes along with the new features and functionality. At PDC, we also demoed our first cut at the support for WPF in XAF: still a way to go, but a good first step (another that we didn't show off was an ASP.NET MVC proof of concept). One thing is certain, though: 2010 will be a faster ride for XAF than 2009 was. Are you ready to strap yourselves in and grasp the grip bars?

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

    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.

    ScriptEditor1

    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.

    ScriptEditor2

    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.

    ScriptEditor4

    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.

    ScriptEditor5

    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:

    ScriptEditor6

    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.

    ScriptEditor7

    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.

  • Sneak peek: The Snap Lines feature 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.

    Dmitry In this first article, he hooked me up with Dmitry Barakhov (whose handle is Dem in the forums), and Dmitry talked about the Snap Lines feature he implemented.

    JMB: First of all, what do "snap lines" mean and what is their purpose?

    Dem: Basically, snap lines are for the design-time positioning of different UI elements; in our case, for the positioning of report controls.

    Let me give you a little background and tell you about the history of this problem. It is common practice to have a report with elements' edges aligned with other elements' edges. To solve this task in XtraReports prior to v2009.3, we had a grid of dots and you positioned controls on that grid:

    SnapLines1

    However this approach has several drawbacks. First, the corresponding preview of a document will differ from its design-time representation because there will be no dots in the preview. Obviously so — the grid is presented at design time but is not visible at runtime, so having the grid means the user does not get a true visualization of what the runtime preview of the document will look like.

    On the sixth day of DevExpress Christmas, I found the new and improved XtraReports Script Editor Another problem with this approach is the necessity to have report elements already aligned to the grid so that other elements would have the ability to be aligned to them. Sometimes this is just not very convenient (in the picture above you can see that xrLabel2 is aligned to the grid but not to the left coordinate of xrLabel1, we have to make sure that's aligned to the grid ourselves).

    The 'snap lines' approach, introduced by the Visual Studio Windows Forms designer as well as designers like Blend, doesn't have these shortcomings. It can work without a grid and it allows you to precisely align a control to another control's coordinates.

    SnapLines2

    JMB: Are snap lines enabled by default?

    Dem: Yes. In fact there is a new property in XtraReports — SnappingMode — that regulates this behavior. Its default value is set to SnapLines, but the user can switch to SnapToGrid to return to the old behavior.

    JMB: When are snap lines functional? Only during the drag-and-drop of controls within a band?

    Dem: Snap lines certainly work during the dragging of controls within a band, but they also work when drag-dropping from one band to another (by the way, snap lines can be disabled during a drag-drop operation by pressing the ALT key). Not only that, but they are also functional during resizing either by using the mouse or keyboard. And finally, they are operative when picking a control from a toolbox and dropping it onto a report.

    JMB: What kinds of snap lines are supported by XtraReports in v2009.3?

    Dem: For now I've implemented what might be called the "bounds" type of snap lines — that is, the ability to align a report element to another report element's Left, Top, Right, or Bottom coordinates — and the "margin" type of snap lines — that is, the ability to indent a control from another control. This indent is specified by a control's SnapLineMargin and SnapLinePadding for container controls like the XRPanel and XRTableCell.

    JMB: Neat. Any plans for expanding this functionality in the future, or (laughs) is there nothing left to do?

    Dem: Of course there is more to do [;-)]. For example: snap lines that align to the "Base line" of text is another cool kind of snap line that we are going to implement in the near future. Another is  the ability to add custom snap lines and the ability to restrict certain kinds of snap lines on a particular control.

    JMB: Dmitry, thank you for talking with me. Good luck with extending snap lines in future releases!

    Dem: You are always welcome!

  • Localized DevExpress assemblies for WinForms

    (OK, view this blog post as a way for me to remind my future self where to find this stuff.)

    I took a call this morning where the caller needed Portuguese translations of the fixed text in our WinForms controls. Now, we don't do these translations ourselves (we have enough problems getting it right in English, thank you very much Wink), but our community have stepped up to the mark and provided their own translations for other customers to use. We host these translations and you can download them from Knowledgebase article A421.

    The article provides complete instructions as to what you need to do to get these localized assemblies and how to "activate" them in your application. For reference, here are some links to help out:

    If you are writing ASP.NET applications and need translated captions and the like, check out Knowledgebase article K421 instead.

    I hasten to add that it's through the generosity of our customers that we are able to provide these satellite assemblies. I'd like to thank everyone who's helped — we really appreciate it — and to ask everyone: if you have translated the static text into another language we don't support yet, consider providing that to your fellow developers. Contact support if you have.

  • Strong sales of Professional DevExpress ASP.NET Controls

    image We had a bit of a shock this morning when checking out the Amazon sales rank for Professional DevExpress ASP.NET Controls. Here's the evidence:

    image

    Also, briefly, we broke in the top 100 for "Computers and Internet". Unfortunately we didn't see it: someone else emailed us the news.

    But, at any rate, these sales are astounding!

  • PDC 2009 Day 3

    The third day, for some reason, was pretty quiet at the booth. Nevertheless there was a constant stream of customers who wanted to discuss their scenarios with us, and how we could help.

    Another big event was Eiríkur Nilsson managing to beat Mark in the Beatles RockBand contest we were running at the booth. It goes without saying that this was an impressive achievement, and, given that Eiríkur wanted a CodeRush license instead of the game, means that he will be even faster at coding in the future. I'm guessing we'll have to send him a new keyboard in 6 months' time, and, if we happen to meet up at another conference, I think we should pit him and Mark head-to-head, both with CodeRush, to see who'd be faster…

    Of course, yesterday being the last day of PDC, as soon as the exhibit hall closed at 4pm, we had to strike the booth. The booth infrastructure was struck by the hired help, but we had to pack the LCDs/plasmas (5 32-inchers, 2 50-inchers) and cart them off ready for next time. We'd gauged our swag requirements exactly: all of the t-shirts, caps, books, blinky lights, etc, had been given away so we didn't have to cart any remaining swag off.

    All in all, a good conference. If you were there and came to introduce yourself, thank you for coming along and saying hi. If I'd promised something for you, I'll be responding next week (today's a travel day for me).

  • Eiríkur Nilsson wins Beatles RockBand contest!

    Kevin taking down Eiríkur's contact detailsThis PDC we've been running a contest: try and beat Mark in writing a useful control. The catch is that you have to write your code using Visual Studio only (so, using Intellisense, snippets, VS' refactorings if needed) whereas Mark is using CodeRush, albeit with an Xbox guitar and no keyboard. If the contestant beats Mark, they win a full Beatles RockBand game. Just for competing the contestant gets a $50 iTunes card.

    During our rehearsals last week, Mehul managed to write the code required in about 2 minutes 20 seconds and Mark was always a few seconds faster. So we thought we'd be pretty safe, and the past two days of contests has borne this assumption out.

    Of course, anything can happen on the last day, and through some virtuoso typing, Eiríkur Nilsson managed to implement the working control a couple of seconds faster than Mark.

    An awesome result from Eiríkur, and, to cap it all, he asked to swap his RockBand prize for a free license of CodeRush!

  • DevExpress Newsletter 15: Message from the CTO

    As Julian has absconded to PDC this week I am reprinting his Message from the CTO from the fifteenth newsletter so that you can comment on his thoughts.

    Assessing Risk

    We human beings are bad at assessing risk. Consequently we are bad at mitigating risk, not having a clear idea of the risks in the first place.

    Recently, I was having a chat with someone regarding loss-of-limb insurance. It's a nasty thing to have to happen to you to be sure, and getting some kind of recompense if it happens sounds great. But consider the risk you're insuring against. From the internet, I discovered that half of all 200,000 amputations in the US each year are due to diabetes. So, providing you don't have diabetes, you have roughly a 1 in 3000 chance of having to have an amputation for health reasons.

    If you look after yourself, what are the chances of losing a limb due to some kind of trauma? The latest figures I found from 1996 showed a rate of 0.6 per 10,000 people. To put that into perspective, in 2005 42,636 people died in car accidents in the US, which is roughly 1.4 deaths per 10,000 population. You are over twice as likely to die in a car accident than lose a limb through trauma (such as from a car accident). Which is why I put my money into life insurance instead.

    In software development, risks are everywhere. We mitigate the most obvious ones through source control, offsite backups, unit and functional tests, keeping our stakeholder informed at all times, short iterations, the whole panoply of Agile development. But what about other risks? Your lead developer walks and no one else knows how he implemented the communication layer. Your only customer is affected by the recession and cancels all development work until sales pick up. And so on.

    So what risks do you consider? What mitigations have you prepared for them? What risks do you ignore because the probability of them happening is so remote? How did you assess that probability?

  • PDC 2009 Day 2

    If you've been lucky enough to be an exhibitor at a large conference, you'll know that after the hectic first day, the second (and subsequent) days are more measured. You find that you talk for longer with individual customers: they're not in a hurry and want to learn more about what your company does and you can provide more attention to them and their scenarios. Such was the second day today.

    The other big event that affected today's booth "look-and-feel" was the announcements of this morning. The attendees learned all about Silverlight 4 and in addition were presented with an Acer Aspire tablet notebook that supports multi-touch. So, correspondingly we were asked more about our targets and controls for Silverlight and about our touch abilities.

    Nevertheless, I spoke at length with Anthony our contact at Microsoft about the VSIP program and about our issues with VS2010 beta 2 (to summarize: the BeginInit/EndInit codegen bug has been fixed internally, there's still more to discuss re. Client Profile); I spoke with Joseph Hill and Geoff (I forget his surname) of Novell about Mono and ASP.NET (I shall have to get back to my experimentation: Mono have produced an add-in for Visual Studio to make it all easier); I spoke with customers of companies great and small about our products and our goals for the future. I did demos of XAF, of our new DXPivotGrid for WPF, of XtraReports and XtraCharts, of the Silverlight layout control. I discussed strategies for migrating an existing WinForms application to WPF and a Delphi 2006 application to Silverlight (despite no Embarcadero or RemObjects presence here at the conference, there are some Delphi people wandering around).

    One theme came up time and again though: given the new announcements about Silverlight 4 this morning (especially regarding desktop use and access to native system resources like the filesystem), whither WPF? I had (and have) no great insights into this question unfortunately, although my gut feel is starting to need some Alka-Seltzer.

    All in all a long, pretty tiring, day, but a day where again I've been bolstered in my belief that we at DevExpress are on the right track. Now to the internal Summit next month where we decide on the particulars and the roadmap for 2010.

    And tomorrow is the last day of PDC. As I write this, I'm 48 hours from sleeping in my own bed again Smile.

  • PDC 2009 Day 1

    We all gathered together at the office this morning at 9am, with a long list of items we'd forgotten to bring to the booth on the previous two days: another monitor, a vacuum cleaner, Jeff's tripods, etc. The booth was due to open at 11am in the Los Angeles Convention Center, and we knew that we'd need most of the two hours to wade our way through the LA rush hour traffic (in LA the rush hour lasts from 4am Monday to 9pm Friday every week) to make the journey from Glendale.

    Scott Hanselman and Ringo We met up with the BackBeats (the Beatles cover band we'd hired to support us during the first day) at the booth and made all the last minute changes and fixes to the booth, when suddenly the crowds descended upon us, and we were chatting with them, demonstrating our products, listening to their scenarios and problems to see whether we could help them or not. Paul and I also got to sign a whole lot of the DevExpress books and give them out.

    Meanwhile, every now and then, Mark Miller would launch into another contest: can you write code faster with a keyboard than he can write with an Xbox guitar and CodeRush (not a keyboard in sight). So far today, the answer is no, although one contest got close when Mark started in VB, realized that a particular refactoring wasn't available, and had to start over in C#.

    Other impressions: lots of questions about WPF and Silverlight (the latter because of the announcements about Silverlight 4 earlier on in the day); my discovery that in order to create a web application in XAF, I really should have installed Visual Web Developer (big handy hint there, people); installing the latest beta of DXperience v2009.3 this morning (the previous one was already 8 days old); Gary helping me over Twitter to improve the performance of WPF in a VM (answer: disable hardware acceleration inside the VM — another huge handy hint); giving out all our shrink-wrapped guitar t-shirts; the fun half hour before the evening session when we grabbed Scott Hanselman of Microsoft to play Beatles RockBand.

    I've also had some time to browse some of the new feature in v2009 vol 3. I really must write some more blog posts tomorrow about them. But: cut, copy, paste of records between two grids in WPF? Yowza. Come on over to the DevExpress booth tomorrow if you want to see.

1
2
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners