Developer Express Inc.

.NET Reports and exporting to PDF

Julian M Bucknall — Thu, 21 Aug 2008 18:47:20 GMT

Recently an issue came up with regard to the export to PDF functionality in our printing and reporting suites, XtraPrinting and XtraReports. The issue was in regard to the use of characters that weren't the normal 7-bit ASCII characters and whether the fonts should be embedded or not in that case.

I decided to take a peek at how we've implemented the export to PDF functionality in order that you can gain a better understanding of the issues. Since the whole subject is pretty complicated, I took the hit so that you didn't have to .

With PDF, there is a fundamental distinction between the notion of a character and a glyph. A character is a symbol, like "A" or "4", whereas a glyph is an image or rendering of that character. A collection of glyphs is known as a font.

Easy enough, except that a character has to be encoded in some way into a binary number. We're used to thinking of the character "A", for example, as being encoded as 0x41. This particular encoding started life in ASCII and has now propagated into Unicode.

That's all very well, but in the days when a character was encoded in a byte value, there weren't enough bit values available to encode all possible characters. So the notion of codepages evolved to encode different characters in the range 128 to 255. In the Latin codepage or character set (sometimes known as Latin-1 or Windows 1252), for example, the character à is encoded as 0xE0 (and, again, that propagated to Unicode). However, on the Mac the character à is encoded as 0x88.

Back to PDF. PDF is a file format that is essentially text and not binary. (Yes, I'm oversimplifying since text blocks can be compressed using the Deflate algorithm and will appear as binary blobs, but bear with me.) The text is obviously represented using some encoding. There are a set of standard encodings for text in PDFs: one for Macs called MacRomanEncoding, one for "Windows ANSI" (which is essentially codepage 1252) called WinAnsiEncoding, and one for a more general PDF codepage called PDFDocEncoding. All of these encodings are single byte encodings: each byte value represents a different character.

Back to fonts in PDFs (as you can see, there are lots of strands to pull together here to get the full tapestry). There are two different ways to define the fonts in a PDF. The first, and very lightweight way, is to describe the font as a set of metrics (name, width of glyphs, slope of italics, and so on). The reader of the PDF (say, Acrobat Reader) is then responsible for locating the font on the user's machine and using it. If the actual font is not available on the user's machine, the reader then has to locate the nearest font that matches the font metrics embedded in the PDF.

If the PDF uses fonts in this way, the text in the PDF is encoded as one of the standard encodings. As you can imagine, you are relying on the user machine being pretty similar to the machine that generates the PDF, otherwise the user is possibly going to get some weird effects (wrong or missing glyphs, a different look to the page, and so on).

In XtraPrinting and XtraReports, we used to use PDFDocEncoding in this situation. However, the majority of our customers use the Latin-1 codepage, and so there was a possibility that reports could have some missing or invalid glyphs when exported as a PDF for these customers. For the next minor version (2008.2.3), we've switched to WinAnsiEncoding and this change should help more people.

Of course, you may be thinking that it's nice to generate very small PDFs in this way, but it's all a little bit too hit and miss on the reader side. That's why there is a second way of defining fonts in PDFs: to embed them.

Here the onus is on the writer of the PDF. It has to analyze the text in the PDF, work out which glyphs of the font are being used and then embed those glyphs directly in the PDF. If fonts are embedded in the PDF in this way, the text is actually encoded in a two-byte manner and a map is generated that maps the character encoding to the index of the glyph in the embedded font.

Using fonts in this way, you get absolute precision control. What You See (as the writer) Is What You Get (as the reader). There is no wishy-washy, crossed-fingers, hope-for-the-best aspect to reading the PDF: the end-user will see exactly what you wanted them to see, no dropped or swapped glyphs. The downside to this is, obviously, the PDF is "heavier" or larger since it has to have all those glyphs embedded.

(Note to those who are really clued up on PDFs and character encodings and font support. There is yet another method: the writer can define a ToUnicode character map, or CMap, that is a single-byte encoding that uses a special map to work out which glyph to use with a font that's not embedded. We don't support this variant yet.)

Having said all that, you can mix and match. You can have some text in your PDF where you assume that the reader will have the required fonts available to display it, and you can have some text where you embed the fonts. In our printing suites, you can manage this scenario by using the NeverEmbeddedFonts property. If you name a font in the NeverEmbeddedFonts property (it's a semicolon-separated list of font names) it will be defined in the PDF in the first, lightweight, way. If a font is used in the PDF that is not in this list, then it will be embedded in the PDF in the second, heavier, way.

And that's pretty much it. I hope that this exposition has made the whole issue of fonts in PDFs clearer and that it helps you make the best decisions in your particular scenario when you need to export your report to PDF for your users.

devLink Conference 2008 in Tennessee

Mehul Harry (Developer Express) — Thu, 21 Aug 2008 06:33:05 GMT

The devLink 2008 conference in Nashville, Tennessee is already here! If you were lucky enough to get registered before it sold out then drop by the Developer Express booth and say Hello. I’ll be there to answer your questions and show you some cool demos.

There are a bunch of great new tools that we’ve been working on this year and you can come talk with me about things like:

Our ASP.NET tools
WPF DataGrid
Silverlight controls
Our rich WinForms controls
My new iPhone 3G

While it’s not PDC, there’s probably some good tracks and speakers there because the event is already sold out. In fact, there’s a devLink bus on a road trip to the conference. You can follow many of the developers on the bus through their twitter stream.

Oh and if you stop by the booth and mention this post then you’ll get my thanks and probably a nice DevExpress T-Shirt too.

So drop by the booth before they’re all gone. :-)

XPOlympics – Serialising RSS Feeds Using XPO

Gary Short (Developer Express) — Wed, 20 Aug 2008 12:19:31 GMT

Although the UK is a crowded island sitting on the border of the Atlantic Ocean and the North Sea, comfortably far from mainland Europe, its population is relatively small; in fact when compared to the those of China or India it is, in fact, tiny (estimated to be 60.7 million as of July 2007). Perhaps it is this fact that means I am always surprised when the UK does well at global scale sporting events such as the Olympics, and there is no doubt that Team GB (more correctly Great Britain and Northern Ireland) has excelled at these games, putting in the best performance, in terms of medal haul, since the 1908 games.

So what has all this to do with XPO? Well I like to keep up with what is going on at the Olympics but that “work thing” just keeps getting in the way. Coupled with that I’d really like to record all the news so that I can go back and analyse it after the event. So, what I really need is a little application to handle the following requirements:

Read an XML file and fetch one or more RSS feed URLs
For each feed

Check if that feed has been serialised previously

If it hasn’t

Create it

If it has then fetch the matching feed object from the database

Send a HEAD request to the web server for the RSS feed file header information

Examine the last-modified header

If there is no last-modified header then skip this file
If the file has not been updated since last read then skip the file

Fetch all the news items from the RSS feed

For each news item

Create a news item object
Check if the fetched / created feed object has this news item already

If it does then skip this news item
Otherwise add the news item to the feed

Set the lastUpdate date to now.

Serialise the newly created object graph to the database
This process must be able to be automated using the Windows AT command

Looking at the requirements, it’s clear to see that, apart from doing a few sensible checks, all that is required is that an RSS feed is serialised to a database, that sounds to me like a perfect job for XPO. Now, a blog posting is not a suitable place to examine such an application line by line (I leave that as an exercise for the reader) but let’s look at some of the more pertinent points of the application.

Firstly I could have used an OPML file to contain my list of RSS feed URLs that is, after all, what it was designed for. However, I felt that was a little overkill for the purposes of our application and so I went with a more simplified “roll you own” file structure as shown below.

<?xml version="1.0" encoding="utf-8" ?>
<Feeds>
  <Feed>
    <Name>Feed Name</Name>
    <Url>Feed URL</Url>
  </Feed>  
</Feeds>

Having specified which feeds we wish to read (my application reads the 32 BBC feeds dedicated to the Olympics) we should now go ahead and specify our Feed and NewsItem domain objects. I’m not going to cover that here as it is clearly documented on our web site.

The first thing I’d like to draw your attention to is the fact that, by default, XPO will serialise objects to an Access database, if you want to use another database (and we support over 15 RDBMSs) then you have to inform XPO like so:

private void SetUpXPODataLayer() {
    string conn =
        MSSqlConnectionProvider.GetConnectionString(".",
            "XPOlympics");

    XpoDefault.DataLayer =
        XpoDefault.GetDataLayer(conn,
            AutoCreateOption.DatabaseAndSchema);
}

The next thing I want to draw your attention to is not specifically XPO related but is, never the less, interesting. It is the technique of only fetching the header information from the web server to ascertain whether or not a file has been updated, this prevents you having to download the entire file unnecessarily and is done like this:

//GS - Make a request for the feed header info only and 
//get the last-modified date
HttpWebRequest webRequest =
    HttpWebRequest.Create(feed.Url) as HttpWebRequest;
webRequest.Method = "HEAD";
webRequest.KeepAlive = false;

WebResponse webResponse = null;
string lastModifiedDateString = String.Empty;
try {
    webResponse = webRequest.GetResponse();
    lastModifiedDateString =
    webResponse.Headers.Get("Last-Modified");
}
catch (WebException wex) {
    Trace.WriteLine(String.Format("{0} - {1} {2}",
        DateTime.Now, wex.Message, feed.Name));
    Trace.Flush();
    Trace.Close();
    continue;
}
finally {
    if (webResponse != null) {
        webResponse.Close();
    }
}

Note the use of the “KeepAlive = false;” line above, this prevents the HttpWebRequest object from keeping the connection open and causing “connection leaks”.

Whilst I’m on the subject of things which are not specifically XPO related but are interesting anyway, note the use of LINQ to XML to extract the news items from the feed, isn’t that syntax so much nicer that the XPath way of doing things?

var newsItems =
    from item in feedDoc.Descendants("item")
    select new {
        Title = item.Element("title").Value,
        Description = item.Element("description").Value,
        PubDate = item.Element("pubDate").Value,
        Category = item.Element("category").Value,
        Url = item.Element("link").Value
    };

Anyway, this is an XPO blog so let’s get back on topic shall we? Having fetched or created a new feed and extracted the news items from the RSS document we want to add the news item to the feed, but only if it hasn’t been added before, we don’t want duplicate news items in our feed. We can use XPO to check it’s not been added already this way:

if (!aFeed.NewsItems.Contains<NewsItem>(aNewsItem)) {
    aFeed.NewsItems.Add(aNewsItem);
}

Now, all that remains for us to do is to serialise our newly created object graph to the database by calling CommitChanges() on the UnitOfWork object.

If you would like to download the full application and have a look at it, you can get it here.

Technorati tags: XPO, RSS, Olympics

Using SQL Server 2008 spatial data from XPO

Oliver Sturm (Developer Express) — Tue, 19 Aug 2008 14:00:00 GMT

Boris posted me some code that I used to play around with, in order to make XPO work with SQL Server 2008 spatial data. It is possible to make it work, quite easily actually, but there are a few things that need to be considered, and where more than one solution is possible. Let's see.

First, we need a class to store data in the client application. This is the one I'm using:

  public class PolygonData: XPObject {
    public PolygonData(Session session)
      : base(session) { }
 
    private string name;
    public string Name {
      get { return name; }
      set { SetPropertyValue("Name", ref name, value); }
    }
 
    SqlGeography polygon;
    [ValueConverter(typeof(GeographyConverter))]
    [DbType("geography")]
    public SqlGeography Polygon {
      get { return polygon; }
      set { SetPropertyValue("Polygon", ref polygon, value); }
    }
  }

This is already the first thing that probably needs some thought. In order to use the SqlGeography class as the property type, it is necessary to have a reference to the assembly Microsoft.SqlServer.Types. That assembly is not currently part of the .NET Framework, but it is installed together with SQL Server. As the SqlGeography class has several pieces of useful functionality (and there are other useful classes in the same assembly), it seems weird that they aren't available in the "standard client". Apparently Microsoft prepared these classes for server-side use, and obviously this makes some sense if you're going to use .NET on the server in some way, but still... there are a number of blog posts out there on the topic (try searching SqlGeography client side, for instance), and at least one of them points to a future solution that involves a separate redistributable which might become available at some point. For the time being, it would probably be possible to install the assembly in question on the client manually -- but please note that I haven't looked into legal issues involved with this, so be careful!

If, for whatever reasons, you don't want to go this way, you would have to create your own client-side class to represent the spatial information. The other approaches described in this post would still be quite similar though.

Now, as you can see, the property for the Polygon in my code is decorated with two attributes. The DbType attribute makes sure that the field gets created with the correct type "geography" in SQL Server. The ValueConverter attribute is used to convert the geography into the string format needed in SQL. Here it is:

  public class GeographyConverter : ValueConverter {
    public override object ConvertFromStorageType(object value) {
      if (value is string)
        return SqlGeography.Parse((string) value);
      else return value;
    }
 
    public override object ConvertToStorageType(object value) {
      return value == null ? null : ((SqlGeography) value).ToString( );
    }
 
    public override Type StorageType {
      get { return typeof(string); }
    }
  }

The ConvertFromStorageType function implementation is a bit weird, since it simply skips the conversion if the object that's getting passed in is not a string. This is perhaps not the most secure way of implementing this, but it's good enough for the purpose of the demo. The reason I'm expecting objects that might not be strings is explained further down and it has to do with performance -- depending on the decision you make at that point, you might implement this function in slightly different ways.

To create a bit test data, I'm using the following helper function in my code (the SqlGeographyBuilder is another class from Microsoft.SqlServer.Types):

    private static SqlGeography CreatePolygon( ) {
      SqlGeographyBuilder builder = new SqlGeographyBuilder( );
      builder.SetSrid(4326); 
      builder.BeginGeography(OpenGisGeographyType.Polygon);
      builder.BeginFigure(55.36728, -2.74941);
      builder.AddLine(55.40002, -2.68289);
      builder.AddLine(55.39908, -2.74913);
      builder.AddLine(55.36728, -2.74941);
      builder.EndFigure( );
      builder.EndGeography( );
      return builder.ConstructedGeography;
    }

With this in place, I can create and store some data:

      using (UnitOfWork uow = new UnitOfWork( )) {
        new PolygonData(uow) {
          Name = "Test 1",
          Polygon = CreatePolygon( )
        }.Save( );
        uow.CommitChanges( );
      }

If you are following along and you've built your own sample with these code snippets, you will be able to execute the sample at this point. It will get a table created in SQL Server and the spatial data inserted. Wonderful!

Finally, of course we want to read data back from the database. In my sample, I'm using this simple piece of code to do it:

      using (UnitOfWork uow = new UnitOfWork( )) {
        var polygons = new XPCollection<PolygonData>( );
        foreach (var polygon in polygons) {
          Console.WriteLine(polygon.Name);
          Console.WriteLine(polygon.Polygon);
        }
      }

If you try to run this, you will see an exception though. The reason for that is that there are types here which don't match up. The SQL Server client library, somewhat confusingly, returns an object that is actually of type SqlGeography, whereas our type converter defines a storage type of string ins StorageType property. As a result, a function called ReformatReadValue is called on the connection provider we're using (MSSqlConnectionProvider by default), and that function attempts to use the .NET Framework standard Convert.ChangeType function to convert a SqlGeography into a string. That function in turn expects the object to implement IConvertable, and throws an exception because it doesn't do that. Phew.

So what's the solution to this problem? Well, making the ReformatReadValue function do the conversion of SqlGeography into string, that's one solution. Let's derive a connection provider and override that function:

  public class GISProvider : MSSqlConnectionProvider {
    public GISProvider(IDbConnection connection, AutoCreateOption autoCreateOption)
      : base(connection, autoCreateOption) {
    }
 
    protected override object ReformatReadValue(object value, ReformatReadValueArgs args) {
      if (value != null) {
        Type valueType = value.GetType( );
        if (valueType == typeof(SqlGeography) || valueType == typeof(SqlGeometry))
          return value.ToString( );
      }
      return base.ReformatReadValue(value, args);
    }
  }

Now we need to make sure this is the provider we're using, instead of the standard MSSqlConnectionProvider. We can do this with an initialization line like this:

      XpoDefault.DataLayer =
        new SimpleDataLayer(new GISProvider(
          new SqlConnection("data source=.;integrated security=SSPI;initial catalog=XPOSql2008Spatial"), 
          AutoCreateOption.DatabaseAndSchema));

If you're following along, try running your application again, with the reading code in place, and you should see the geography information read back to the client and shown on the console.

There's one problem with this code, and I'm sure you have noticed already: we are getting back a SqlGeography instance from the database client code, and this gets passed in to the ReformatReadValue method in the XPO infrastructure. There it is converted into a string. Then it gets passed into the configured value converter for the Polygon property, and gets converted in a SqlGeography instance. Sounds suboptimal, doesn't it? Yeah...

There is a solution to this, but it's not entirely perfect. It is possible to simply ignore what ReformatReadValue wants us to do and just not convert the object (leave off the ToString() from the value the method returns). Then the SqlGeography type object will be passed in to the value converter, which needs to be implemented to ignore the fact that this is not really a string it receives. Remember, I already pointed this out above - if you want to go this "better performance" way, your value converter will have to be able to deal with the fact that it might receive objects to convert that have actually already been converted.

I'm only describing this solution instead of showing the code, because it's not really something I want to recommend. This solution neglects the contracts of the XPO infrastructure, and that is of course a bad thing when changes are made in the future. It might also be a problem if the data has to be serialized after being read from the database - having it in string format is what XPO normally assumes, and that works well with all types of serialization. I haven't made any real tests, so I can just say I don't know precisely what will happen if SqlGeography instances are sent across the wire using Remoting, XML Web Services, WCF or other frameworks. So - if you're interested in the performance gain, Remoting and so on are perhaps not a concern of yours (it seems unlikely anyway that Remoting and the perf gain from a few saved string conversions are *both* important to you), then it shouldn't be hard to use this approach I described. Please note though that you should take extra care to have relevant unit tests in place, so that changes in future XPO versions don't catch you out.

Overall it seems a bit weird the way this feature has been implemented. The client side seems to convert the spatial data into the original type automatically, pretty much whether you want it or not - at least that's how I understand it at this point. Since I push in string data through SQL in order to store the information, it would seem logical to be able to retrieve the string data only, and make my own decision about converting it back into object data, and specifically about the right point in time to do this. Perhaps it fits in somehow with Microsoft's decision not to make Microsoft.SqlServer.Types available in the client by default. Or perhaps there's something I missing right now in this regard :-)

Anyway, have fun! Here's the complete code of the sample I created: XPOSql2008Spatial.zip (4201 bytes)

XPO and FILESTREAM - update

Oliver Sturm (Developer Express) — Fri, 15 Aug 2008 10:40:00 GMT

Yesterday I wrote about using the new SQL Server 2008 FILESTREAM feature with XPO, and this morning Boris from our XPO team sent me an IM going "na na na, I found an easier way to do this". Okay, maybe he didn't quite put it like that :-) Anyway, here's the code he sent me:

  public class Something : XPObject {
    public Something(Session session)
      : base(session) { }
    public override void AfterConstruction( ) {
      base.AfterConstruction( );
      streamId = Guid.NewGuid( );
    }
    private string strVal;
    public string StrVal {
      get { return strVal; }
      set { SetPropertyValue("StrVal", ref strVal, value); }
    }
    private byte[] streamData;
    [DbType("VARBINARY(MAX) FILESTREAM")]
    public byte[] StreamData {
      get { return streamData; }
      set { SetPropertyValue("StreamData", ref streamData, value); }
    }
    private Guid streamId;
    [DbType("uniqueidentifier ROWGUIDCOL UNIQUE NOT")]
    public Guid StreamId {
      get { return streamId; }
      set { SetPropertyValue("StreamId", ref streamId, value); }
    }
  }

This code removes the need for any separate structural updates, which is of course very convenient. Now, in my previous post I had already mentioned I'd been playing with ways of using the DbTypeAttribute, and my solution had looked almost exactly the same - only I hadn't been aware that the UNIQUE keyword could be used in that precise way, and so I wasn't able to get the necessary index created on the ROWGUIDCOL field. Boris' code takes care of that now.

Is this preferable? I'm not entirely sure. I had one other reason to decide not to post my own similar code in my previous article, and that was the fact that the DbType parameter for the StreamId field looks very much like SQL injection. As you can see, it ends in "NOT", and that is to combine with the "NULL" that XPO inserts into the SQL code anyway, so the field ends up being "NOT NULL". Hm... I guess this is SQL injection, seeing how the text from the DbType is inserted into the DML code without any checks. Then again, that's the exact point of having a DbType attribute in the first place - the ability to use types that XPO isn't aware of - and of course it's compile time data that is injected. In the end, that code has the same effect as the other code I published previously. It is important to point out that while this may look similar to code used for SQL injection attacks, it's quite a different thing really, and there doesn't seem to be a way of exploiting this at runtime.

So is it preferable? I don't know - I guess it's more convenient to use in some cases. It's also less dynamic. With the code I published previously, it would be possible for the initialization code to determine whether SQL Server 2008 is being used, and to make the necessary changes only if it is. By decorating the field with the DbType attribute, the class can only be used with SQL Server 2008. I guess in the end everybody will have to decide for themselves.

Update: Another idea from one of our untiring XPO team members - Alex this time - you could use an XPCustomObject and establish a Guid type primary key. This will be marked with ROWGUIDCOL automatically (we introduced this originally to make the databases replication friendly) and of course it will have the required unique index. I actually had a similar idea early on, but I wasn't going to do this because I didn't want to mix the requirements of the FILESTREAM feature with other structure... Of course you'll still have to get the FILESTREAM type set correctly and using DbType on that one still makes your structure specific to SQL Server 2008. I guess my own overall decision might still be to make the modifications through SQL/DML statements, but of course (as Alex also pointed out) I should pay attention whether my table has a Guid type primary key perhaps - in which case SQL Server will not let me establish a second column with the ROWGUIDCOL attribute set.

Finally, I was asked to show how initialization code can be used in the context of an XAF application. That's actually very simple, since XAF has its own mechanism of updating database structure and content with new versions of applications. That mechanism can easily be used to call some structure modification code. It's documented in the XAF help here.

Installing Visual Studio SP1 wiped out my item templates

Julian M Bucknall — Fri, 15 Aug 2008 01:25:50 GMT

Sounds like a conspiracy theory, so maybe I should put it all in caps, with spelling mistakes: INSTALING VISHUL STUDIO SP1 NUKKED MY DX NEW ITEMS IKONS. KTHXBYE.

A customer phoned me up this afternoon saying that he'd just installed DXperience Enterprise but couldn't find any XtraReports items in his toolbox. He was worried in case the install had failed in some way. Ha, I thought, I'll just walk him through creating a new application that has a report, and show that the XtraReports controls only show up in the toolbox if the designer is showing a report form. You know, that friendly CTO helping the customer thing.

So we started off together. Create a new solution, I said, and we did. OK, to add a report to this project, I said, we right-click and select New Item, and select XtraReports... WHERE THE HECK HAVE ALL MY ITEMS GONE?

For some unfathomable reason, installing SP1 had wiped all third-party item templates from this list. It was bare. No XAF, no XPO, no XtraReports, nothing. A tiny little tab still promised some DXCore items, but otherwise zip, nada, zilch. I shivered.

Meanwhile, I'm sure my customer was slowly backing away from the phone: the CTO of DevExpress doesn't know how to create a simple XtraReports app? What the... I made some reassuring noises -- OK, maybe they were just noises -- and we finished the call with my abject apologies.

I had a look at my other machine which I use for travel. There I'd installed SP1 and DXperience 2008.2.2 (I was late in updating it on that machine) in that order, and, lo, the new items page was full.

So there was nothing for it but to uninstall XAF and DXperience and then reinstall them (hmm, now I write this perhaps Repair might have done the job in a shorter time) and full functionality was restored. So, if you run into this, you'll know what to do.

Meanwhile, if you did call me this afternoon about XtraReports, I can lead you though the basics over the phone now. Honest .

Windows 7 news starts filtering out

Julian M Bucknall — Thu, 14 Aug 2008 21:46:57 GMT

Microsoft Senior VPs Steve Sinofsky and Jon DeVaan (the former in charge of Windows and Windows Live and the latter in charge of Windows Core Operating Systems) have started a new joint blog called Engineering Windows 7 to talk about, well, Windows 7, the next version of Windows beyond Vista. So that would be Lost Horizon then (bada boom bada bing ).

They're going to be regularly blogging about the new things in Windows 7 all the way up to PDC (Professional Developers Conference)in October -- where already there's a large number of sessions booked to talk about Windows 7 -- and WinHEC (Windows Hardware Engineering Conference) the week after. It seems that, after a virtual desert from the past couple of years, we're going to be deluged with information until we're drowning in the stuff.

The blog is bound to be interesting. My recommendation then is to subscribe to the RSS feed so you're kept up to date with what they say. (Well, as soon as it's ready; must be a Windows Live thing.)

(Er, Ray? I know that we're a Platinum Sponsor of PDC this year and that we have a large booth 'n' all and it's likely to be a madhouse in the Exhibitor's Hall, but could I have lots of time off to go to these sessions? Ray? Don't walk away laughing hysterically, I'm asking a serious question. No, don't switch the light off...)

XPO and SQL Server 2008 FILESTREAM support

Oliver Sturm (Developer Express) — Thu, 14 Aug 2008 16:48:00 GMT

In a recent forum post, Reinhold Erlacher asked me whether we supported the new FILESTREAM feature in SQL Server 2008 yet. I was not familiar with the feature, not being a SQL Server expert really, but I decided to have a look.

First, I had to set up SQL Server to actually support the feature in question. A well documented process, but a bit weird nonetheless - why do they introduce features that are only available after jumping through so many additional hoops? Ah well... Here are the instructions on MSDN - there's a lot of confusing information around in blogs, apparently from pre-release versions of SQL Server 2008, so be sure to use these to get it to work with your database.

Now, first I played around a bit to try and get XPO to create a database structure automatically that would be compatible with the FILESTREAM feature. That is not currently possible, as it turns out, since there are a few requirements:

The database must have a file group for the file streams
A table that has associated file streams must also have a column marked ROWGUIDCOL
The ROWGUIDCOL column must have a unique index applied

Finally, of course, the blob column that will store the stream data must be marked FILESTREAM. We don't support any of these things directly - i.e. through a built-in feature - in XPO, and I don't think it's likely that we will. Fortunately, it's quite easy to make the necessary changes either manually (configuring the file group in SQL Server Management Studio) or automatically (using a bit of SQL code that's executed after the default schema creation process from the XPO application). The process shouldn't be hard to integrate with a typical deployment scenario, and of course we can't help the fact that Microsoft have made it quite hard to benefit from the new feature.

I'm using this basic persistent class for my demo:

  public class Something: XPObject {
    public Something(Session session)
      : base(session) { }
 
    public override void AfterConstruction( ) {
      base.AfterConstruction( );
      streamId = Guid.NewGuid( );
    }
 
    private string strVal;
    public string StrVal {
      get { return strVal; }
      set { SetPropertyValue("StrVal", ref strVal, value); }
    }
 
    private byte[] streamData;
    public byte[] StreamData {
      get { return streamData; }
      set { SetPropertyValue("StreamData", ref streamData, value); }
    }
 
    private Guid streamId;
    public Guid StreamId {
      get { return streamId; }
      set { SetPropertyValue("StreamId", ref streamId, value); }
    }
  }

I experimented briefly with the DbTypeAttribute and I had some success with it, but since custom SQL code was still required, I decided to make all relevant changes in one place instead of spreading them out. My test application is this:

  class Program {
    static void Main(string[] args) {
      XpoDefault.DataLayer = XpoDefault.GetDataLayer(
        MSSqlConnectionProvider.GetConnectionString(".", "XPOFileStream"),
        AutoCreateOption.DatabaseAndSchema);
 
      // This sets up the DB structure. Of course we would only do this 
      // once in a real app. Since we're boring in this sample, we're just
      // going to kill the db and go from scratch.
      using (UnitOfWork uow = new UnitOfWork( )) {
        uow.ClearDatabase( );
      }
      CreateDBStructure( );
 
      // Create some test data
      using (UnitOfWork uow = new UnitOfWork( )) {
        Something something = new Something(uow);
        something.StrVal = "Entry";
        something.StreamData = UTF8Encoding.Default.GetBytes("Stuff in my stream");
        uow.CommitChanges( );
      }
      // Read the object back and show the stream data
 
      using (UnitOfWork uow = new UnitOfWork( )) {
        Something something = uow.FindObject<Something>(null);
        Console.WriteLine("Stream says: " + UTF8Encoding.Default.GetString(something.StreamData));
      }
    }
 
    private static void CreateDBStructure( ) {
      // Get the basic db structure created
      using (UnitOfWork uow = new UnitOfWork( )) {
        uow.UpdateSchema(typeof(Something));
      }
 
      // Apply schema modifications
      Action<string> execute = CommandExecutor(XpoDefault.DataLayer.Connection);
      execute("alter table Something alter column StreamId uniqueidentifier not null");
      execute("alter table Something alter column StreamId add rowguidcol");
      execute("alter table Something add constraint streamid_unique unique(StreamId)");
      execute("alter table Something drop column StreamData");
      execute("alter table Something add StreamData varbinary(max) FILESTREAM");
    }
    static Action<string> CommandExecutor(IDbConnection connection) {
      return delegate(string command) {
        SqlCommand sqlCommand = new SqlCommand(command, (SqlConnection) connection);
        sqlCommand.ExecuteNonQuery( );
      };
    }
  }

You can download the complete sample from here (VS 2008 SP1): XPOSQL2008FileStream.zip (4267 bytes)

Note: If you try to run the sample out of the box, you will be in trouble because the database is not configured to support file streams! You should therefore create a database called "XPOFileStream" manually and set it up to support file streams correctly (again, as described here), and then run the sample.

New Refactoring Video: Extract to XAML Template

Mark Miller (Developer Express) — Thu, 14 Aug 2008 14:23:00 GMT

Here's another refactoring we're working on for the 3.2 release, Extract to XAML Template. It moves an inlined control template up to the resource section of the file, which promotes reuse of the template across multiple controls.

Between now and the 3.2 release, existing CodeRush and Refactor! Pro customers can get a daily build from support@devexpress.com which includes this feature.

XPO Publication Service and XAF

Oliver Sturm (Developer Express) — Thu, 14 Aug 2008 10:57:00 GMT

I was involved in some debugging action this morning, regarding my XPO Publication Service. Please read this post (and others linked from there) to find out the basics about that service.

The problem in question was that a customer was receiving a weird Remoting exception when trying to connect to a data store published through the publication service. The first test I did was to change the dependencies in the service to 8.2, build it, and run my functional tests on it - all of those worked fine.

So I set out to create a simple client that would attach itself to a data store published through the Publication Service. At this point, I think a little excursion would be good. I have noticed that many people have the weirdest ideas of how to connect to a published service from XPO. Often they involve a line like this:

IDataStore dataStore = (IDataStore)Activator.GetObject(typeof(IDataStore), 
  @"http://tcp:2635/something.rem");

Now, this is not wrong, but it's also not necessary. Retrieving a reference from the Activator is one way of interfacing with the .NET Remoting infrastructure on the client side. But - that code is already contained in the XPO libraries, so all the gory details of using Remoting are hidden. You can easily use XPO to get a connection provider (= data store) created directly, like this:

XpoDefault.GetConnectionProvider("tcp://localhost:9999/something.rem", 
  AutoCreateOption.DatabaseAndSchema)

Or, even better, you can get a data layer set up directly, like this:

XpoDefault.DataLayer = XpoDefault.GetDataLayer("tcp://localhost:9999/something.rem", 
  AutoCreateOption.DatabaseAndSchema);

What this means is really that a connection URL for a data store published through Remoting can be used in very similar places to any other connection string. XPO will figure it out for you.

On a related note, guess how to set up an XAF application to connect to a data store publication? That's right, just use the URL as a connection string. For instance, put this into your app.config:

<add name="ConnectionString" connectionString="tcp://localhost:9999/something.rem" />

Right, end of excursion. Now, I'd created that little client app and, in contrast to all the lines above, I was using HTTP, not TCP, for the connection. The publications.xml file for the Publication Service had this Channels section:

<Channels>
  <xpopub:HTTPTargetChannel>
    <Port>9999</Port>
  </xpopub:HTTPTargetChannel>
</Channels>

I was quite surprised to find this, but I got the same Remoting exception as described in the support center issue.

One idea I quickly had was that the problem might be related to that other weird issue I had encountered at some point when using HTTP for a publication. That issue is described in this post on my personal blog, and it's certainly not irrelevant if you use Remoting or some other protocol to publish things through HTTP. So go to this article and have a look if you're interested.

Anyway, that wasn't it, since the error messages were different. Nevertheless, I was able to solve the problem by switching to TCP. Probably a good idea anyway, unless you specifically need to use HTTP for firewall reasons (though it will forever remain a mystery to me why people don't have a problem tunneling unknown content through HTTP, while being scared $$(*&less by the same data on a different port). So I changed my publications.xml to this:

<Channels>
  <xpopub:TCPTargetChannel>
    <Port>9999</Port>
  </xpopub:TCPTargetChannel>
</Channels>

I changed all the URLs I was using to tcp://, as shown in the code lines above, and then it worked. Great. A quick test with the more complex XAF Main Demo application showed that this worked as well. Fine.

So, back to the "why"... why is everything fine with TCP, but not with HTTP? Well, the answer came to me after some discussion with our support guy Dennis: the serialization formats don't match. Yeah. Let me say that again - the serialization formats don't match. Why doesn't Remoting throw a TheSerializationFormatsDontMatchException? I don't know. Anyway, that's what's happening.

The XPO Publication Service defaults to binary encoding, even for the HTTP channel. There's a property called UseBinaryEncoding on the channel, which can be changed through the config file, but it defaults to true. The XPO library, on the other hand, defaults to SOAP encoding when an HTTP channel is used. So, back to the publications.xml with the HTTPTargetChannel, and then insert this line before the code that establishes the connection to the server:

ChannelServices.RegisterChannel(new HttpChannel(null, 
  new BinaryClientFormatterSinkProvider(), null), false);

Credit for this line goes to Dennis - he had found out that this makes things work, though he wasn't exactly sure why. Here's why: because the HTTP Channel is configured to use binary encoding and thereby becomes compatible with the way the Publication Service works. The XPO library doesn't register the HTTP Channel again, since it's already there, and it doesn't change the registration either. Fine.

Now, several questions come up here. First, why are the Publication Service and the XPO defaults incompatible? I don't know. It's certainly weird and I suspect we changed something at some point, on one or both ends. It's been a long time since I wrote the Publication Service and being a pet project, it's perhaps not tested well enough - still, since we're talking about default settings here, it seems that this could have been found earlier if it had been like that forever. I don't know.

Second, is it possible to use SOAP encoding? Yes and no, oddly enough - another point where I'm not sure where a problem comes from. It is easy to switch the Publication Service to using SOAP, like this:

<Channels>
  <xpopub:HTTPTargetChannel>
    <Port>9999</Port>
    <UseBinaryEncoding>false</UseBinaryEncoding>
  </xpopub:HTTPTargetChannel>
</Channels>

The problem is, when I tried this, I got another weird exception coming up, saying that the SOAP formatter isn't able to deal with generic classes being serialized. Okay then... hm. The point where we changed XPO to have generic classes involved in the inheritance hierarchy is a really long time ago, so it's probably been like that since then. Interestingly, while I don't know how many people use Remoting with HTTP/SOAP, I'm pretty sure there are some people using XML Web Services, which use HTTP/SOAP as well. The answer to that is that the SOAP formatter for Remoting isn't the same as the one for XML Web Services. And they are both different from the one being used for WCF, if I'm not completely mistaken. Trust Microsoft to find ways of making complex things more confusing.

Summary of all the odd stuff above

If you've stopped reading my ramblings a while ago, here's the summary of important points:

The reason for the issue is that the XPO Publication Service and the Remoting client code in the XPO libraries use different formatter defaults for the HTTP channel. We should look into making some changes so this would be compatible automatically.
Using TCP instead of HTTP makes things work. This is probably the best idea for many cases, unless HTTP is absolutely required.
Using binary formatting with HTTP also makes things work. An additional line of code is required for this purpose, but inserting this into application initialization code shouldn't be a problem in most cases.
Using SOAP formatting with the Publication Service is easy, but it doesn't actually work for technical reasons in the Remoting SOAP formatter. We might look into this in a bit more detail to see if there's anything we can do about this.
Using the HTTP/SOAP combination is perfectly possible with XML Web Services as well as WCF, to my knowledge. XML Web Services are not self-hosting, so they can't really be supported by the XPO Publication Service. WCF can be self-hosting and it would be possible to extend the Publication Service to support it directly. The Publication Service can be extended externally, i.e. without changes to its own code base. With or without support in the Publication Service, there are plenty of articles on this blog that show how to tunnel through Web Services and WCF.

Update:

I've talked to the XPO team, and they have tracked down the problem with the SOAP formatter. Turns out this should actually work - so we regard it a bug and it will be fixed. Hang on... just now an IM tells me that the fix has been checked in internally. Will be in the next minor release.

The thing with the default behavior of the XPO Remoting code is that it uses defaults the .NET Framework provides, which is a good thing of course. I guess it would make sense to change the default for the Publication Service to use SOAP instead of binary... I'll probably do that soon.

Silverlight Control Builder Contest '08 complete

Julian M Bucknall — Thu, 14 Aug 2008 01:29:48 GMT

A couple of days ago the Silverlight Control Builder Contest '08 that Page Brooks organized came to an end. He'd managed to convince a whole bunch of vendors like ourselves to pony up prizes (ours was a subscription to DXperience Universal and a $500 gift certificate to NewEgg) and had managed to amass something like $17,000 worth.

So how did it go? Well, unfortunately that was a problem. Only one person entered, Faisal Waris, and of course he won. Despite this, he didn't win with a piddly progressbar control or something, but instead created a stunning FishEyeGrid control for Silverlight -- you should certainly go and check it out. (Note, for some reason it wasn't working for me in Firefox 3, so use IE7.) Certainly a worthy winner.

Many congratulations to Faisal. The part of your prize from DevExpress is on its way.

But my post is not about Faisal's winning entry, it's about what went awry. Why only one entrant? That's a real shame. I came up with some thoughts:

1. The competition was for US developers only. As it happens, I can understand this: in the past we've looked at whether we could organize a competition in the same vein as this and the legalities can be overwhelming. Just in the US there are rules and laws about giving away prizes (for instance, the rule that everyone has heard of: "No purchase necessary"). I can't imagine what it's like in other countries; it could be there's tax liabilities or to give away a prize you have to have a legal office/address in that country, for example. Anyway, in this international, interconnected day and age it's all a bit of a mess.

2. It's hard creating controls for Silverlight. OK, I'm being more jokey than serious.

3. Silverlight is still too new for many people to have gained expertise in writing controls. Applications, maybe; controls, not so much. This is perhaps a better reason than 2. Although there is a lot of buzz about Silverlight 2, it is still in beta and not many workplaces will be using it yet, or even experimenting with it. So without work-related experience, you're left to play around with it at home in your spare time. And of course, there's a lot from Microsoft in the same space jockeying for your attention and learning abilities (WPF, ASP.NET MVC, etc). And, to be honest, not many people write controls (and most of them would be working for companies like Developer Express .

4. There wasn't enough time. A difficult one this: you want to give the potential contestants well enough time to experiment and design and write something, but you don't want to make it so long that the buzz dissipates and people say "uh, what contest?"

5. It takes a lot of time to create a compelling control that would win a competition. And as we all know, time equals money. Perhaps the $17,000 of prizes didn't have enough in gift cards/money/cheques to make it worthwhile. Sure it's nice to have the top of the range products from us and our fellow prize-giving vendors, but in the end a lot of the contestant's spare time goes into this. I calculate $1000 in certificates that can be used to buy "stuff" to repay your efforts for the first prize, $475 for second place, $200 for third place. Maybe that's not compelling enough to sink many tens of hours into the contest.

6. There was no registration. Without that Page had no real idea about how many people were considering entering the contest nor who they were, so he couldn't email all the registrants a week from the end to say, how are you doing?, are you going to finish? Without that knowledge, it becomes hard to make a decision to, say, extend the contest another week. With registration, more people might have persevered -- it's like signing up for a beta, you tend to feel compelled to try it out.

Nevertheless, it was a good contest and, as I say, well organized by Page and we all got a great control from Faisal that everyone can use.

New Refactoring Video: Extract Method to Type

Mark Miller (Developer Express) — Wed, 13 Aug 2008 13:35:00 GMT

This is one of my favorite new refactorings coming up in the 3.2 release of Refactor! Pro. It's called Extract Method to Type, and it allows you to extract a block of code from one class to another class better suited to host the code block.

Here's a video showing this refactoring in action. I love the sub-menu allowing you to select both the target class and the calling local (when multiple target classes and calling locals exist).

While 3.2 is not released as of this writing, CodeRush and Refactor! Pro customers can get the latest daily builds from support@devexpress.com to have access to this feature right now. If you get a daily build and have a chance to try out this refactoring, let me know what you think.

DXperience and CodeRush Awards at TechEd 2008

Developer Express - Ray — Tue, 12 Aug 2008 22:26:00 GMT

Though a bit late in posting this, SQL Server magazine has published a short video on the awards we received this year at TechEd 2008.

The video can be viewed here: http://ittv.net/DesktopModules/UltraVideoGallery/UltraVideoGallery.swf?vId=96&portalId=0

.NET Framework Assistant

Julian M Bucknall — Tue, 12 Aug 2008 00:16:17 GMT

When you install the .NET Framework 3.5 SP1 that was released today, and you're running Firefox 3 as your browser du choix, the next time you run Firefox you'll get the Add-Ons dialog showing you that a new add-on has been installed.

Funny that, I don't remember okaying that particular choice, but anyway. I'm about to install SP1 on another machine, so I'll look out for it.

This add-on provides click-once support for Firefox and also will report back to whatever web server is asking the latest version of .NET that you're using. Back in May, Scott Guthrie reported that this would be part of the SP1 beta, although it's fun to try and find it:

ClickOnce Client Application Deployment Improvements

...blah blah...

FireFox browser extension to support Clickonce installations using FireFox browsers

Just a friendly heads-up from your homies at DevExpress...

Visual Studio 2008 Service Pack 1 Released!

Mehul Harry (Developer Express) — Mon, 11 Aug 2008 23:15:00 GMT

Service Pack 1 for Visual Studio 2008 and .NET Framework 3.5 is out now. We had a chance to work with Microsoft on some of the issues and suggestions that many of you have recommend. Microsoft has listened and come out with a good service pack. It addresses many of the issues as well as include fixes, new features, and improvements:

Check out the full post on Somasegar’s blog
List of improvements and details on the service pack

[Update thanks to Glenn and Heather:] If you have the beta (and some other KB hotfixes) installed, then run the Visual Studio 2008 Service Pack Preparation Tool FIRST.

Click the button to download Service Pack 1 for Visual Studio 2008 and .NET Framework 3.5:

PS - After installation, leave a comment here on how you like the new improvements, features and fixes.

Is .NET too successful?

Julian M Bucknall — Mon, 11 Aug 2008 22:04:20 GMT

Over the past few months I've been reading of rumblings in the .NET blogosphere about the directions Microsoft is taking with .NET.

The poster child for these rumblings is the dichotomy between LINQ to SQL and the ADO Entity Framework (EF). Both in essence are used to get data from your database engine into your .NET application, both implement an ORM (object-relational mapping), but it's not really clear which one to use. So there's a whole cottage industry that's grown up around this, with many august commentators opining for their readers which they'd go for (just google for "LINQ to SQL" "Entity Framework").

It turns out the reason there are two frameworks that have such wide overlap is that, ta-da!, they were written by two different teams at Microsoft. LINQ to SQL was written by the C# team, whereas EF came about through some long-winded gestation (I'm visualizing that scene from one of the Lord of the Rings movies where you see the orcs been "born") from something called Object Spaces and is owned by the ADO.NET team. LINQ to SQL was recently given over to the ADO.NET team.

Roger Jennings, in a post from May this year, wonders whether the ADO.NET team are just going to abandon LINQ to SQL. It's crippled in the sense that it only works with SQL Server and, as I said, there's a great deal of overlap between it, and EF. Why have 2 official ORMs when just having one will do?

And another example: the Patterns and Practices (P&P) group at Microsoft have been producing "best practices" type libraries, such as CAB, for a long time. Last year, just before TechEd, there was a flurry of information about a new product codenamed Acropolis that seemed to replicate a lot of what the P&P group were doing, but in a shiny new framework with designer support in Visual Studio. By October it had gone, its ideas to be subsumed in P&P and eventually the .NET framework itself. P&P has expanded its repertoire of libraries since.

And of course we have WPF, WCF and WF, all frameworks that expand on the basic .NET Framework. Ditto ASP.NET MVC. Poor old Visual Studio just can't keep up, which is unfortunate since they all really need VS's discoverability and designers to make them easier to use. So there's more blogging advice from august commentators...

The .NET Framework no longer seems to be single and indivisible. Instead it's turning into this multiheaded hydra, a victim of its own ease-of-use and productivity enhancers. Different teams at Microsoft seem to be producing libraries and frameworks as quickly as possible without anyone having much of any control over the process to try and unify them. David Worthington of SD Times seems to have a key to someone's filing cabinet at Microsoft, since he's quoting from yet another internal memo about exactly this issue in his latest article.

I don't know quite honestly what the answer to this might be. In one sense, it's great to get all this functionality flowing out of Microsoft. On the other, it just makes the whole process of developing with the .NET Framework that much more complex. Also, looking at it from our viewpoint, should we try and support everything that it makes sense for us to do? Wouldn't that spread us too thin, meaning our existing products and customers getting reduced love, but getting more marketing hits for new anemic products that support the latest framework/library? Or should we be more cautious, and test the waters a little with some experimental products before jumping in or retiring?

This is all a shame since the .NET universe was so much simpler than the previous COM and ActiveX universe. Are we getting to the point when another super abstraction is needed to make .NET simpler. together with full support in Visual Studio?

Return on Investment with Developer Tools, part II

Mark Miller (Developer Express) — Mon, 11 Aug 2008 21:48:00 GMT

A while back I talked about calculating return on investment for developer tools. That post brought in great comments pointing out limitations in a few assumptions made, including:

Some shops average more than eight hour days or five day weeks.
Many devs spend only a portion of their day actually writing new code or maintaining existing code.
Most devs work less than the 50 weeks per year used in the original spreadsheet.

So, I'm back with a revised spreadsheet, one that allows you to more accurately describe your work year, as well as how much time team members actually spend coding per day. The result is a more accurate picture of how much time it takes to achieve ROI. Many of the cells have comments to explain their values.

This spreadsheet also adds a field for Developer Gain, a value in man-months that represents the amount of dev time gained due to the productivity boost. Even for a small 3-dev team with each member spending an average of 5 hours a day writing or maintaining code, Developer Gain for CodeRush and Refactor! Pro still adds up to over five additional developer man-months every year.

Take a look at the spreadsheet and let me know what you think.

New VCL spell checking component

Julian M Bucknall — Thu, 07 Aug 2008 21:27:00 GMT

Alongside the new version of our VCL pivot table control, ExpressPivotGrid 2, that Ray introduced here, we are debuting our new spell checking component, ExpressSpellChecker, in the same release.

This component provides you with an uncomplicated way in which you can add Microsoft® Office® style spell checking capabilities into your next Windows® application. Features include:

Built-in support for Ispell and OpenOffice dictionaries.
The ability to check text in standard text editors as well as in DevExpress text input controls.
If you do use text input controls from Developer Express, words that aren't in the dictionary can be underlined.
The ExpressSpellChecker automatically checks spelling as you type, word by word. This is done in a separate thread without affecting the responsiveness of your UI.
Custom dictionary support is provided and uses a plain text format.
Dictionary dialogs allow end-users to add unrecognized words to a dictionary, so that they can build a custom word list as they work.
There is a choice of two error indication dialogs, the dialogs that allow users to correct spelling mistakes. Both replicate dialogs found in Microsoft Office:
Pre-built Options editor. Options include the ability to ignore emails, URLs, mixed case/upper-case words, repeated words and words with numbers within them:
You can force the spell checker to start scanning the text from the current cursor position or to check the current selection first.
Error correction can be done using a customizable built-in context menu:
The ExpressSpellChecker's API includes methods to spell check an arbitrary string, the content of a text editor, or the content of all text editor controls within a specified container.
The spell checker provides a complete set of events to allow you to manage the spell checking process - including the suppression of built-in forms, modifications to suggestion lists, skipped words, manual error processing, etc.

The Developer Express VCL spell-checking component will be available with the VCL Subscription.

[Supported compilers: Delphi 7, Delphi 2005, Delphi 2006, Delphi 2007, C++Builder 2007]

Redirect Callback using an ASPxHttpHandler Module

Mehul Harry (Developer Express) — Thu, 07 Aug 2008 20:51:00 GMT

Check out this three minute video on how to redirect from within an Ajax callback. Normally, to redirect, you would call the HttpResponse.Redirect method and pass the URL you want to redirect the current page to. But the Redirect method doesn’t work in a callback.

Here’s where the ASPxHttpHandler Module, with its multiple uses, comes to the rescue. With the ASPxHttpHandler Module, you can just check the IsCallback method, then set the HttpResponse.RedirectLocation property and you’ve got a seamless redirection. Click the image below to learn more. Then drop me a line here and let me know what other approaches you could use to get this redirection.

Custom Silverlight Controls: Creating a reusable MessageBox dialog. (Part III)

Azret Botash (Developer Express) — Thu, 07 Aug 2008 20:21:00 GMT

We have created the basics for the MessageBox dialog in Part I and Part II. One thing that we realized is that there is no way to block on MessageBox.Show. The cleanest solution to get the dialog result is to make our call API "asynchronous".

Something like this:

public delegate void DialogCloseDelegate(
    object sender, 
    DialogResult dialogResult);

public static class MessageBox {
    public static void Show(string title, string text, DialogStyle dialogStyle,
        DialogCloseDelegate callback) {
        InternalShow(title, text, dialogStyle, callback);
    }
}
...
public class MessageBoxControl : ContentControl {
    DialogCloseDelegate _callback;

    public MessageBoxControl(Popup owner, DialogCloseDelegate callback)
        : this() {
        this._callback = callback;
        ...
    }

    void DialogButtonClick(object sender, RoutedEventArgs e) {
        DialogButton button = sender as DialogButton;
        if (this._owner != null && button != null) {
            this._owner.IsOpen = false;
            if (_callback != null) {
                _callback(this, button.DialogResult);
            }
        }
    }
}

We can then use the MessageBox like so:

private void Button_Click(object sender, RoutedEventArgs e) {
    MessageBox.Show("Title", "Hello World", DialogStyle.OkAndCancel, 
        new DialogCloseDelegate(OnDialogClose));
}

void OnDialogClose(object sender, DialogResult dialogResult) {
    MessageBox.Show("Dialog Result", dialogResult.ToString());
}

What's Next?

Since this is just demo code, a lot of things have been simplified. For example you might want to move the hard-coded "OK" and "Cancel" button contents out into properties. You could make the default template for the message box surface a little prettier, so that it has the look and feel of your application. Hopefully, this article will get you started.

Download the Source Code

Cheers,

Azret