This Blog


Favorite Posts


October 2007 - Posts

  • In which Julian laughs an evil laugh and doesn't give out any details at all

    Something we're going to demo at DevConnections next week: 


    Remember: Booth #131; DevConnections; Monday 5th - Wednesday 7th November.

  • CTO does lazy load. Film at 11.

    Sometimes a CTO needs to get back to coding. Here's something that came up in an internal discussion.

    Suppose we have this code:

        public class HeavyFoo {
          public HeavyFoo() {
            // big honking constructor
          public void DoSomething() {
        public class UserOfHeavyFoo {
          private HeavyFoo heavyFoo;
          public UserOfHeavyFoo() {
            // don't want to create heavyFoo here
          public void UseHeavyFoo() {
            if (heavyFoo == null) 
              heavyFoo = new HeavyFoo();

    We imagine we have this useful class called HeavyFoo. Unfortunately its constructor does some heavy processing, maybe by setting up some connection to somewhere, setting up a bunch of data, reading a file, or whatever. So we'd rather create a HeavyFoo object only when we really, really need it. This is exactly what the UserOfHeavyFoo.UseHeavyFoo() method does: if the internal field hasn't been initialized yet, go ahead and create the HeavyFoo instance. This pattern is known as the lazy load pattern.

    All well and good, but it imposes a hidden contract on the developer of the UserOfHeavyFoo class: you can never "just" refer to the heavyFoo field, you always have to make sure that it's initialized beforehand.

    So people traditionally refactor this code to something more like this, to use a read-only property:

        public class UserOfHeavyFoo {
          private HeavyFoo heavyFoo;
          private HeavyFoo HeavyFoo {
            get { 
              if (heavyFoo == null) 
                heavyFoo = new HeavyFoo();
              return heavyFoo;
          public UserOfHeavyFoo() {
            // don't want to create heavyFoo here
          public void UseHeavyFoo() {

    At a superficial level this seems to help, but we still have a hidden contract: when we write a new method, we should never use the heavyFoo field and always use the HeavyFoo property. If we don't, the code will still compile, but it may fail in weird ways at run-time depending on the order of execution of our new method vs. UseHeavyFoo(). Call the UseHeavyFoo() method first and everything works, call the new method first and you'll get a crash.

    What we'd like to do is to make sure that we can't access the bare heavyFoo field. The only way to do that is to take it out of the UserOfHeavyFoo class and put it somewhere else. My current idea is along these lines:

        public class LazyLoad<T> where T : class, new() {
          private T item;
          public T Item {
            get {
              if (item == null)
                item = new T();
              return item;
        public class UserOfHeavyFoo {
          private LazyLoad<HeavyFoo> heavyFoo;
          public UserOfHeavyFoo() {
            heavyFoo = new LazyLoad<HeavyFoo>();
          public void UseHeavyFoo() {

    This is much better in one way since we can no longer refer to an uninitialized HeavyFoo instance in our UserOfHeavyFoo class, but it looks a little awkward in another: we now have a double dereference when we want to do something. Also, the LazyLoad generic class can only deal with classes that have a constructor with no parameters; something I think is unlikely for heavy duty constructors. We can avoid both of these by having a specific lazy load class for HeavyFoo, but I can imagine that if we were to have a series of these lazy load classes, there would be a lot of code and behavior duplication.

    So I'm still thinking about this one, although I'm beginning to think that HeavyFoo has something to do with the code smell.

  • Breaking changes for DXperience v2007 vol 3 (aka 7.3)

    It's that time again, when I describe the breaking changes you can expect in the next release of DXperience, v2007 vol. 3. We do try hard to minimize these types of changes, but sometimes we just have no alternative in order to provide new functioanlity or a bug fix or two. By making this list available before the release gives you some time to prepare.

    So without further ado:


    • DevExpress.Web.ASPxClasses.ItemImagePosition, DevExpress.Web.ASPxPager.PagerButtonImagePosition and DevExpress.Web.ASPxEditors.ButtonImagePosition have been replaced with DevExpress.Web.ASPxClasses.ImagePosition.
    • The link appearance has changed in the TabControl's and RoundPanel's default appearance stylesheet (autoformats). Now the link appearance in TabControl is defined only for tab links. The link appearance in RoundPanel is no longer defined.
    • The default BackColor was changed to Transparent for both the ASPxTabControl and ASPxPageControl (see image)


    • Both GotFocus and LostFocus client events were removed the from ListBox and RadioButtonList classes.


    • The GridViewLoadingDivStyle class has been replaced with LoadingDivStyle.


    • We've introduced a new assembly: DevExpress.XtraCharts.Web. The WebChartControl class has been moved to the new assembly from the DevExpress.XtraCharts.UI assembly. The new assembly references the DevExpress.Web assembly.
    • The WebChartControl class now inherits from ASPxDataWebControl instead of System.Web.UI.WebControls.DataBoundControl. This is declared in the DevExpress.Web assembly.
    • We've completely removed the old chart wizard (the DevExpress.XtraCharts.Design.ChartWizard class).
    • The SideBySideBarSeriesView.BarDistanceVariable property, previously marked as obsolete, has now been removed.
    • The SideBySideBarSeriesView.DefaultBarDistanceFixed, SideBySideRangeBarSeriesView.DefaultBarDistanceFixed, SideBySideGanttSeriesView.DefaultBarDistanceFixed constants have been replaced with the SideBySideBarDefaults.DefaultBarDistanceFixed constant.
    • The SideBySideBarSeriesView.DefaultBarDistance, SideBySideRangeBarSeriesView.DefaultBarDistance, SideBySideGanttSeriesView.DefaultBarDistance constants have been replaced with the SideBySideBarDefaults.DefaultBarDistance constant.
    • The SeriesLabelsPageTab.ManhattanBarShadow, SeriesLabelsPageTab.Line3DShadow, SeriesLabelsPageTab.StepLine3DShadow, SeriesLabelsPageTab.Area3DShadow, SeriesLabelsPageTab.StackedArea3DLine, SeriesLabelsPageTab.StackedArea3DShadow, SeriesLabelsPageTab.FullStackedArea3DShadow, SeriesLabelsPageTab.Pie3DShadow, SeriesLabelsPageTab.StockLine, SeriesLabelsPageTab.CandleStickLine, SeriesLabelsPageTab.RangeBarLine, SeriesLabelsPageTab.SideBySideRangeBarLine, SeriesLabelsPageTab.GanttLine, SeriesLabelsPageTab.SideBySideGanttLine enumeration members, previously marked as obsolete, have now been removed.
    • The ChartControl's and WebChartControl's Border property has been renamed to BorderOptions.


    • It is now always required to reference the DevExpress.Data assembly.
    • The PrintingSystem.DrawingPage property has been removed.
    • The RichTextBrick class now inherits from VisualBrick (instead of TextBrickBase).
    • The BrickPagePair class no longer has a default constructor; you should use its Create() method instead.
    • The PageCustomBrick, PageCustomWrapperBrick, PageVisualBrick classes have been removed. PageInfoBrick now inherits from PageInfoTextBrick; PageImageBrick from ImageBrick; UserPageBrick from UserVisualBrick; PageTableBrick from PanelBrick. All these bricks now implement the IPageBrick interface, containnig Alignment and LineAlignment properties.
    • The CustomBrick class has been removed. All CustomBrick descendant classes now inherit from the Brick class.
    • The PrintPreviewForm, PrintPreviewBar and PrintPreviewStatus classes, previously marked as obsolete, have been removed.


    • It is now always required to reference the DevExpress.Data assembly
    • We've introduced a new assembly: DevExpress.XtraReports.Web. The ReportViewer and ReportToolbar objects have been moved to the new assembly from the DevExpress.XtraReports assembly. The new assembly references the DevExpress.Web and DevExpress.Web.ASPxEditors assemblies.
    • The ReportViewer class now inherits from ASPxWebControl declared in the DevExpress.Web assembly (instead of System.Web.UI.WebControls.WebControl).
    • The ReportToolbar class now inherits from ASPxWebControl declared in the DevExpress.Web assembly (instead of System.Web.UI.WebControls.WebControl).
    • Concerning the Web ReportToolbar Control, when any report toolbar button is disabled it is drawn using the new ReportToolbarButton.ImageUrlDisabled property.
    • The ReportToolbar.HorizontalAlign property has been removed
    • When you remove the styles collection from the report, its StyleName property will be cleared. Previously, style names remained in the designer file, although invisible in the property grid, and could have taken effect for another stylesheet with the same style names.
    • The XRDesignForm and XRDesignFormattingToolBar classes, previously marked as obsolete, have been removed.
  • We've gone bananas

    We've just opened a new forum for the DXperience v2007 vol 3 Release Candidate. In this forum — open for reading by everyone, but you can only post if you have a DXperience license — we'll be preannouncing what's coming up in this new version (no specific release date yet, but think in terms of a month or so) and once DXperience customers get it in their hands, there'll be lots of tidbits you can read about as questions and bugs are posted and answers and fixes delivered.

    Just to emphasize: this release candidate, once published, can only be downloaded by existing DXperience customers, and it's only those customers who will be able to post in this new forum. Being a release candidate — a posh word for a late beta — it will have bugs, which we'll be fixing, but the functionality will be pretty much fixed.

    Also, this release candidate does not address eXpressApp Framework (stay tuned for news on that), or our IDE tools, nor does it contain any of our WPF work. For information on those, the place to be is still DevConnections in Las Vegas at the beginning of November.

    So, take advantage of the fact that we seem to have bought stock in Del Monte and Chiquita, and hop on over to the DXperience v2007 vol 3 RC forum. Max has already posted some news about our Scheduler for ASP.NET.

  • Integrating products in DXperience

    Recently Tony in our XtraScheduler team came to the management team with an interesting proposition.

    With our XtraScheduler product, we ship a very basic AppointmentEdit form. Since the scheduler ships with the XtraEditors library, we designed the form to use just the editor controls so that all owners of XtraScheduler could use and develop with the product "out of the box".

    Tony noticed a couple of things: first, there are an awful lot of customers using the scheduler who have the full DXperience product, either at the Professional or at the Enterprise level, and so have access to the full panoply of our WinForms controls; and, second, those users are constantly reinventing the wheel as they develop nicer looking and more functional AppointmentEdit dialogs with the controls they also own.

    So Tony wanted to create a new more sophisticated AppointmentEdit form that would ship with DXperience, but not with XtraScheduler. A form that would use XtraLayout, XtraBars, the Ribbon, and XtraSpellChecker, for example, and that would remove the need for customers to write their own.

    Sure, we said, and he did.

    Here's a few screen shots of the new form that's based on the traditional toolbars, The first one shows the form partially filled in, the other three show various features of the form.



    And here's a corresponding set of screen shots for the new form that's based on the Ribbon, and that show the same four views of the form as above:



    I think he's done such a good job that we're now looking at doing other integration projects where we combine controls from several of our products, and whose results would be part of DXperience but not the individual products themselves. This would obviously add extra value to the DXperience products, but also provide us with ready-made examples of how to use our controls and that we could use for demoing.

    Forms like AppointmentEdit are an obvious example, and in a way eXpressApp Framework is another, albeit at the opposite end of the spectrum. Are there any other integration points you've wished for? Are there any forms in the individual products you'd like to have jazzed up like this as an extension to DXperience? Apart from this particular form, it's probably too late for any more such extensions in 2007.3, but next year is a whole new ball game.


  • Using our ASP.NET controls in CodeGear RAD Studio 2007

    Just thought I'd pass this along, in case you were wondering how it's done. It's from Plato in our support team (thanks, Plato!):

    To add our ASP.NET controls to the component palette in RAD Studio 2007, invoke the Installed .NET Components dialog, go to the Assembly Search Paths tab and add a path to our DLLs to this list. Then close the dialog and open it again. You'll find that our controls have been added to the component palette.

    Wow, that was easy...


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


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. 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-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners