The CollectionsEditMode option gets more flexible

Let me quote myself from the 

Layout.Web - provide the capability to manage the display of detail collections, not on the global application level but, for each DetailView separately feature request, which we have just implemented in 13.2, while working on a bigger feature:

"Starting with the version 13.2, you will be able to control this behavior vis-a-vis the DetailView via the CollectionsEditMode property exposed in the Model Editor for Web projects:

 

[XML]
<Views>
    <DetailView Id="Contact_DetailView" CollectionsEditMode="View"></DetailView>
</Views>

The above setting in the XAFML file will enable the View mode only for the Contact DetailView, while the rest application will use the default mode or the one specified in code:

 

[C#]
protected override void OnLoggedOn(LogonEventArgs args) {
            base.OnLoggedOn(args);
            ShowViewStrategy.CollectionsEditMode = ViewEditMode.Edit;
}

Personally, I love when working on something big small things like this one get attention and are resolved. I hope you like this too:-)

Developing the new Reports module

You are probably aware that we have a very popular feature request for our XAF Reports module:

Reports - Make it possible to easily use XtraReports designed in Visual Studio.

It is primarily about allowing you to easily reuse regular XtraReports created in Visual Studio in an XAF application

I must say that nothing has already prevented you from displaying regular reports in XAF in exactly the same way as you would do in a non-XAF app, but of course the XAF reporting is not only about that: our built-in module also integrates reports into the application navigation and menu systems, enabling end-users to create reports at runtime and store them in the database, adds the Show In Report command to list and detail forms, as well as adding many other features requested by our customers.

I wanted to inform you that the aforementioned request is planned for version 13.2, and we are currently working on it.

Overview
Here is a very short overview of the new features:

Short vs Long View identifiers in version 13.1 (MUST READ)

Let me quote myself from the Core - Introduce an ability to have two or more classes with one and the same name, but declared within different assemblies thread:

"After receiving customers feedback, we decided to change our original implementation (it exists in versions 13.1.3-13.1.5 only) to completely avoid a breaking change here for existing customers (optionally refer to the Core - Make it possible to find a View node by its short identifier ticket for more details on the consequences of the previous change and conflict resolution options).

So, starting with version 13.1.6 the generation mechanism will stay unchanged (short identifiers like Customer_ListView will be used), while having the capability to resolve a name conflict in advanced scenarios (see the updated description of this thread).

According to all our estimates (tickets in the Support Center and other stats), the number of people migrated to version 13.1 and who already started using long identifiers should be small. 
If you already migrated your app to 13.1, it will be required to change long identifiers to short ones after 13.1.6 is out and ONLY in places where you compared View.Id == "MyObject_ListView" in code (the rest should be automatically resolved!). We do not think that it should affect many developers (we only had a single customer call as of now), because the previous conflict resolution options we introduced should cover 95% of cases. 

If you are upgrading your app to version 13.1.6 directly, no changes will be required from you at all. In any event, if you experience any difficulties with this upgrade, our Support Team will be happy to help you resolve all problems.


I want to thank you all customers who provided their great feedback during this time and also want to apologize for all the inconvenience here."

Here is what you can do if you encounter such a naming conflict in your app:

Developing the validation warnings feature - Feedback is needed!

You probably saw my recent post about the feature we are developing for 13.2. This nice addition to the framework was welcomed by the XAF community and there were some questions from customers which I would like to answer here. So, let's do it!

Q1: Chris G. Royle It's difficult to see from the screenshots how you've implemented Dennis. If you've used the snippet that Tolis posted recently in a blog,
A1: No, we have not used the eXpand Framework implementation.
Take special note that a validation warning rule is declared as follows:

[RuleCriteria("RuleWarning", DefaultContexts.Save, @"IsWarning = false", SkipNullOrEmptyValues = false, ResultType=ValidationResultType.Warning)]

You can learn more about our implementation from these short videos:

Winforms: 

About profiling memory leaks...

I want to pay your attention to this Support Center ticket, because here I was involved in memory profiling with my colleague, and also because I remember that some time ago somebody from the XAF community asked to elaborate more on the memory profiling process. 

I doubt this info will be interesting for experienced developers, but we should not forget that there is a large number of people who are using XAF and who love it because it helps them to care less about the underlying technology and what happens behind the scenes.

Hence, my colleague and I wrote a detailed explanation of how we profiled a case when a report preview window is opened and then closed. So, let me quote us from that ticket:

"In fact, it is not guaranteed that the CG will be called automatically after a period of time.
During the normal application life cycle, GC may not be called at all, unless its garbage collection is forced by the CLR.
You can learn more on how the GC works at http://msdn.microsoft.com/en-us/library/ee787088.aspx#conditions_for_a_garbage_collection.

Now please let me elaborate on how we find memory leaks in .NET apps internally.
For example, you may want to check for memory leaks when a report preview is shown.

Here are the steps you would perform:

Guess the feature by screenshots;-)

Yes, you are right, and let's be honest that it was quite easy to guess:-)
I am referring to the Validation - Warn end-users about mistakes/inconsistencies without preventing them from saving changes request, which we are currently working on, and hope to include a solution into the standard XAF delivery in 13.2 (no exact promises, as always!)

Improving ASPxLookupPropertyEditor tab stop behavior

The approach from this article is now obsolete. See the update below.

Today I made the ASPxLookupPropertyEditor a bit more usable with regard to how it handles the tab stop (yes, again!). Thanks to the customer who drew my attention to this scenario.

If you are reading our docs from time to time:-), then you are probably well-aware that this Property Editor can render different controls based on whether the search functionality is required or not:

Let me quote the Built-in ASP.NET Property Editors help article for more details:

The ASPxLookupPropertyEditor creates either an ASPxLookupFindEdit or ASPxLookupDropDownEdit.
The ASPxLookupFindEdit is created when the Search functionality is required. This occurs in two cases. First, when the number of objects to be displayed exceeds the value of the IModelOptions.LookupSmallCollectionItemCount property of the Application Model's Options node. Second, when the LookupEditorMode property of the BOModel | Class | Member node or the corresponding Views | DetailView | Items | PropertyEditor node is set to AllItemsWithSearch or Search. For details on the Search functionality, refer to the How to: Add a Search Action to Lookup Property Editors and Link Pop-up Windows topic.
ASPxLookupDropDownEdit is created when the Search functionality is not required. 

Skipping tab stop for disabled/readonly editors and columns

I've recently refactored (for XAF 13.2) the WinPropertyEditor, DXPropertyEditor and a few descendants to provide a common code for updating the control's availability (technically the System.Windows.Forms.Control.Enabled property) and also added support for skipping tab stop if the control is disabled. Check out the video below to see how it works in action (take special note that the FullName property is readonly):

Reordering enumeration values by setting the Index property under the Localization | Enums node

I would like to let you know about another usability improvement I have recently committed.

Starting with version 13.2, you will be able to configure the order of enumeration items in the Model Editor under the Localization | Enums | <Your Enumeration> node by setting the Index property as shown in the attached screenshot:


































Previously, these values were sorted alphabetically by the caption, and it was only possible to customize this order in code by accessing the underlying editor and customizing its items collection. This had to be done differently for both Windows and the Web due to the differences between these platforms. So, I hope you can see how this small improvement can save your time since you will be able to enable it in platform-agnostic module.

Providing predefined values in the property inspector for a custom application model attribute

As you probably know, XAF Application Model is flexible enough to allow you to extend it to store own UI and behavior options (learn more...) for all users or individually. Today I would like to spent a few minutes to show you one of the possible approaches to provide default values for your custom options.

Scenario
Let's consider a real-life scenario, which I believe many of you deal with in XAF: you create a validation rule via the Model Editor and specify the TargetContextIDs property to tell XAF when to check it:

Technically, there is a string property declared in the IRuleBaseProperties interface:

        [Required]
        [Category("Behavior")]
        [DXDescription("DevExpress.Persistent.Validation.RuleBaseProperties,TargetContextIDs")]
        string TargetContextIDs { get; set; }

Our goal is to provide a drop down editor in the property inspector (instead of the plain text box) to be able to choose the predefined "Save" or "Delete" strings instead of typing them manually.

Solution:
One of the possible solutions is to use the standard .NET Framework TypeConverter mechanism. I should explicitly note that there are many other possible solutions for the same in XAF, and I just would like to describe this one because of its simplicity and popularity even outside of our framework.

Basically, I will perform the two simple steps:

1. Create a custom TypeConverter by descending from the standard StringConverter class and overriding a couple self-explanatory methods (learn more...):

public class DefaultValidationContextsConverter : StringConverter {
        public override bool GetStandardValuesSupported(ITypeDescriptorContext context) {
            return true;
        }
        public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context) {
            return new StandardValuesCollection(Enum.GetNames(typeof(DefaultContexts)));
        }
    }

2. Mark the required model element property with the TypeConverterAttribute passing my custom converter as a parameter:

        [TypeConverter(typeof(DefaultValidationContextsConverter))]
        string TargetContextIDs { get; set; }

That's it.


Results
You can see what we are after in the screenshot below:

BTW, this small improvement will be available starting with in the next minor update (13.1.6), and it should improve usability for beginners in this scenario.

If you know about other scenarios in our framework where usability can be tuned, do not hesitate to let us know as we will be glad to see to it.


Alternative solutions
Depending on your business requirements it would be possible to achieve the same or similar effect using other techniques:
1. a custom UITypeEditor;
2. DataSourcePropertyAttribute/DataSourceCriteriaAttribute;
3. Domain Logic,
to name just a few.  I hope to talk through them in the future when I have some time.

A possible way to improve the ergonomics of a large and complex detail form

When something gets very complex and there is no space for all the info on the screen (imagine a form with 300 text boxes and other controls on it - yes, I saw such forms in my life!)  you can use various techniques to temporarily hide or completely remove certain info (probably rarely used) or allocate it in a way it will occupy less space.

Many container UI elements like tab controls, panels and our layout control are designed to help you with this task. Talking about XAF apps, the most popular way of accomplishing this I saw was putting unwanted fields behind the tab groups, which were activated by end-users on demand:

This approach does not involve any refactoring of your underlying data model, but just means re-layouting the default form in a way where most often used data appears on top while having less popular data hidden. It seems that this all comes from trying to mimic the behavior and look & feel of legacy apps or even papers, because many end-users might be accustomed to such a UI in the past.

Another, but less popular approach I saw was in refactoring a huge data model, which technically means aggregating similar data into a separate part, adding a reference to it from the main object and then showing a separate detail form on demand, e.g. via a button in the toolbar. A perfect example of this can be our ObjectPropertyEditor that can be used for an aggregated reference property and that displays a nice UI for editing its details:

Today, I would like to show you an alternative way of solving the problem of complex detail forms usability. I am double excited about this solution, because it comes from our XAF customer, Sergey Zaycev and his team from Galaktika, whom I recently blogged about.
These guys implemented a custom Property Editor - TabbedDetailPropertyEditor (check this help link to learn more on how it is possible to create such extensions yourself), which is essentially a tree-like navigation panel at the left side and a detail panel on the right. Each node in the tree represents a small portion of data, which is then displayed on the right side as user focuses it in the tree:

This hierarchy is fully customizable at runtime, thus allows you to meet the needs of a very demanding client right in front of his/her PC.


In my opinion, this is a very good alternative to the standard approaches described above. If you think about it, you may find the analogy with how the main application navigation works. Of course, this displaying a small portion of data at a time also works faster and thus is more usable.

I liked this idea very much, what about you?

If you liked this stuff, then I suggest you learn more on it as well as check out other XAFARI platform features at http://xafari.ru/