5.1? 5.1?! I hear you ask, what happened to #6?! Don’t worry, it’ll be along tomorrow; but for the moment I thought it would be a good idea to further explain some of the things that happened in #5. By that I mean that you will have noticed that we decided to do particular things and I explained how to do those things, but I never really explained why we’d done them that way. I noticed that it took long enough to detail with what we were doing and I didn’t want to turn a long post into an epic post by going into the whys and wherefores. This post, of course, is a blank sheet so why don’t we have a look at some of the decisions that were made in post #5?
The first decision we took was to use HTML Editors to allow our users to format the description of a Project and a ProjectTask. Why did we do that and not use a RichEdit control for example? Well the reason is simple, we wanted to have the same behaviour in both the Webform and Winform application and, currently, DevExpress doesn’t have a RichEdit control for ASP.Net. :-)
The next thing you may have found a little puzzling was when we came to replace the default images with images from the XAF library. I told you to change the image view via the model editor but I never told you where exactly that was done, did I? Well it’s done here:
![Tutorial_UIC_Lesson4_1[1] Tutorial_UIC_Lesson4_1[1]](http://community.devexpress.com/blogs/garyshort/Tutorial_UIC_Lesson4_11_thumb_726A479F.png)
Also I didn’t mention what images we shipped. Well if you want to browse them for yourself you can find them at: <Program Files>\DevExpress XXXX.X\eXpressApp Framework\Sources\DevExpress.ExpressApp\DevExpress.ExpressApp.Images\Images.
Of course, I also didn’t mention how to add your own custom images. Luckily, I covered that in a previous post here.
Another thing you might have found puzzling was the when we came to format the date field on TaskWork we used this format:
<Member Name="Date" DisplayFormat="{0:g}" />
But where’d we get that format from? Well the format uses the String.Format() rules which you can read more about on the MSDN site.
We then went on to do some work on the notification, why did we do that? Well it was simply because without that the UI would not update, although the underlying property would change. Calling OnChange allows the binding to reload the property from the business object and update the UI. Strictly speaking of course this code should not reside in the business object, as it’s not the business object’s responsibility to be concerned about the UI, but this is the price we pay for having the business object bound directly to the UI, this will be examined in future releases of XAF.
In the tests you will notice the abstract class BaseXpoTest, which does some useful set up work for us. This base class can now be used by any other application we are working on in the future and there is talk, in the framework team, about maybe even making this as part of a future XAF/XPO release.
Following this we went on to create our own TaskProgressbarControl to visualize the progress of our project, but why did we do that, I mean DevExpress already ships with a ProgressBarControl right? Yeah it does, but if you look at it then you’ll find that this control expects an int for progress and we wanted to use a float (between 0 and 1), so we had to derive our own control. We also derived our own RepositoryItem – what’s that all about? Well, all in-place editors need a RepositoryItem and so we had to derive one of our own, you can read up on the RepositoryItem class for more information, if you so desire.
Of course whenever you “eat your own dog food” you can be left with a nasty taste in your mouth. Building this application has shown us that all is not rosy in the XAF garden. Specifically, you may have noticed that the text in the progress bar is not centred, why not? Well it turns out that someone hard-coded the alignment code in XAF to override the control's defaults and now, for float, it is right alignment regardless of what the control claims. Oops, as we speak that programmer is being tarred and feathered and we’re looking at fixing this in the future.
Also, you may have noticed these lines of code:
protected override WebControl CreateEditModeControlCore() {
TaskProgressBar result = new TaskProgressBar();
result.Width = Unit.Percentage(100);
return result;
}
In particular the line result.Width = Unit.Percentage(100). Now this is a hack to compensate for problems we have in some browsers, this will be fixed for the 9.3 release.
The last thing we discovered, in building this application, is that there is no easy way to show the progress bar in the web list view; again we will fix this for the 9.3 release.
Now you can see why I didn’t put all this information in the original post, as I thought it was quite long enough as it was. Okay, so I’ll be back tomorrow with post #6, until then keep on XAFing! :-)