A WinForms example for collapsing/expanding layout groups and persisting their state

As you probably know, the New Web UI was recently enhanced with built-in options for this scenario. Today, I have updated the https://www.devexpress.com/kb=S135134 thread with a WinForms solution:

Please don't hesitate to write to us about each use case scenario that requires additional code to adjust the layout controls to better meet your business needs. My team and I will be more than happy to research them and see how to manage this situation better at the XAF or DevExpress component level. For instance, here we are thinking about providing platform-agnostic Application Model extensions for managing this task for Windows and the Web.

A custom XAF PropertyEditor example based on the WinForms TimeSpanEdit component

As you know, XAF is very flexible and provides many ways of integrating custom controls for various scenarios; e.g., where something is not covered by the default controls pack: Concepts > UI Construction > Using a Custom Control that is not Integrated by Default

As far as our framework development flow is concerned, it is absolutely natural to perform this sort of customizations, and this extensibility was baked in from the very beginning for XAF users. For instance, there is a built-in WinForms TimeSpanPropertyEditor class for representing and editing System.TimeSpan type properties in the standard delivery:

        public TimeSpan TimeSpanProperty {

            get { return GetPropertyValue<TimeSpan>("TimeSpanProperty"); }

            set { SetPropertyValue<TimeSpan>("TimeSpanProperty", value); }

        }

Technically, our TimeSpanPropertyEditor just wraps a TextEdit descendant from the XtraEditors Library and provides a custom mask for it. One may want to use another visual control for the same task (e.g., the TimeSpanEdit control from the same XtraEdititors library) and that is quite easy to implement in XAF. You can implement a custom PropertyEditor as per  Concepts > UI Construction > View Items > Implement Custom Property Editors

What is New in Help in XAF v16.2

As you probably know, in addition to the new great features the version 16.2 introduced, there are also various improvements to the learning materials that will allow you get the most of DevExpress products and become a better developer. The XAF documentation changes are listed below. I highlighted the topics I personally like or value the most in yellow. I would also greatly appreciate it, if you tell me about your favorite topics in comments!

The good news is that there are even more documentation updates currently in the works, and hopefully, I will be able to announce them to you soon.

How to view and edit only time values without the date part

I would like to promote a new KB article on integrating the WinForms TimeEdit and ASP.NET WebForms ASPxTimeEdit components in XAF:

https://www.devexpress.com/kb=T411714

My team and I would greatly appreciate it if you leave comments on whether you experienced similar tasks in the past and how you were solving them, or if you remember any difficulties with these solutions/maintenance.

Displaying the currently logged user name and photo near the Log Off Action (UPDATED)

We continue to evolve our framework and save time to its users by removing routine work for the most popular customizations like this one. Now in the New Web UI, an image associated with the current user is displayed at the top right corner of the application page when the IModelApplicationWeb.CurrentUserDisplayMode is set to Image or CaptionAndImage.

To provide an individual image for each user, do the following: 
 - Declare a property of the MediaDataObject type in your User business class.
 - Apply the CurrentUserDisplayImageAttribute attribute to the class and pass the property name to it:

[CurrentUserDisplayImage("Photo")]
public class MyAppUser : DCUser, IXafEntityObject, IObjectSpaceLink {
// ...
public virtual MediaDataObject Photo { get; set; }
// ...
}

The result is demonstrated in the image below (look at the top right corner):

The table below demonstrates the effect of different CurrentUserDisplayMode values.

Implementing State Machines at the Business Object vs Controller levels - YOUR FEEDBACK IS NEEDED!!!

I wanted to seriously question the current approach for declaring state machines in code using the StateMachine<T> class and IState/IStateMachineProvider interfaces (Predefined State Transitions Created in Code) and hear what you think of it in general. The main reasons behind this interest are the limitations this originally implemented approach has compared to other available solutions and hence associated support costs.

"Yet Another Controller"© 

In fact, in certain scenarios, creating a custom Controller with the SingleChoiceAction Action or a set of SimpleAction Actions can be simpler and more straightforward than defining a coded State Machine at a domain level. To give you a concrete example of such an alternative solution, check out this Controller that eventually does the same thing as the code in the original documentation article above, but with old-good SimpleAction objects manipulated on View and other suitable events. You can find another example with a SingleChoiceAction in this test project (it's from this SC ticket, so process it with the Project Converter tool first). Even though the alternative Controller-based approach requires more code, it allows you to provide a more granular control over created states and their visual representations. It is cleaner and easier to understand/extend for other business requirements, because it is your own code that uses only the basic XAF APIs.

Implications of using the questioned approach
Contrary to that, the questioned approach is really a bit shorter with the help of 'state', 'transition' and 'state appearance' abstractions defined near your business class, but everything has its own trade offs.

50 shades of grey or thoughts on making the XAF Web UI closer to its clients

Last week, I posted a case study on the New XAF Web UI from our DevPark customers, which caused another wave of feedback on the subject in our team blog, Support Center, social networks and in private discussions with passionate users. All of this was very much appreciated. In this post, I want to address some of the hot points raised as well as communicate our plans regarding this Web theme evolution. 

First, let me provide a little more background on the new web style. Originally, the XAF theme was designed and implemented bearing both hand-held touch devices and desktop browsers in mind. The new design fully reflects our vision of modern web interfaces and was created in close collaboration with our lead UI designer Mike, whom I respect a lot.  He also made up our company web sites, as well as a ton of other DevExpress desktop, web and mobile products and the ASP.NET themes in particular. Being derived from the Moderno theme, the XAF theme and the ideas built in it were  later reflected in newer themes like Moderno and iOS.

Like with any new thing in the world, when this XAF feature was first presented, there were (and still there are) "haters" and supporters who have their own values  and arguments. For instance, for ones it may be a positive change (e.g., "The new web style with its larger UI elements has also allowed us to rethink the whole UX concept and focus on the application data and functions that matter for end-users most of all"), while for others the same goodies may be not desirable (e.g., "Currently I develop LOB applications where these larger UI elements are not very well suited at all (screens with lot of info)..." or "my ideal UI is like the 75% zoom view of the current new UI"). Similarly, some may not like grayed icons or miss the old theme chooser, while others may truly love the current single theme with its large space, increased fonts and editors, collapsible layout groups, emphasis with capital letters and other essential attributes of the new web style. That is totally understandable, and we appreciate each side.  It is also clear that everyone's client needs for a line-of-business web portal may differ a lot and require different tools or customizations. Like I recently commented in the blog: "There is no "one size fits all" product/theme/whatever and as developers we sometimes need to customize things to meet our client's needs better. For instance, large UI elements can be made smaller, white colors can be made gray using CSS and other techniques."

The latter does not mean, however, that the development of this theme is frozen and we do not want to better meet varying customer needs. Ideally, and at least for the most typical tasks, it must be equally suitable with little or no customization for both an HTML/CSS newbie or a professional web master easily locating and changing required DOM element styles in the Developers Tools window of a favorite browser (learn more...).

Thus, we always listen to each user feedback and are constantly improving the theme according to the most popular requests.  Just to give you a few recent examples: there were a good number of requests to simplify the process of adjusting the New Web UI to match corporate colors. With v16.2, this process became much easier with the new options for changing the base color and font in code or configuration files of your app. Our XCRM.Web demo now contains a custom color/font scheme picker to demonstrate the use of these new release capabilities:

Object reference not set to an instance of an object. Part 2.

Before you get totally overwhelmed with the upcoming major v16.2 release (learn quick about XAF bits there), I want to further discuss troubleshooting errors while debugging your app, which is something any developer has to do regularly regardless of the used development tools.

Problem

If you have followed my blog for a long time, you may recall my first post devoted to this problem.

In short, it talks about debugging and analyzing exceptions in Visual Studio or looking into the built-in XAF log file for them. More information on the subject is also available in the online documentation at Concepts > Debugging and Error Handling. 

Unfortunately, we still receive quite a lot support calls with just this meaningless screenshots like " Object reference not set to an instance of an object" or similar without any callstacks, inner exceptions, loaded assemblies or any other meaningful diagnostic information that would allow us to help users in the most effective manner. Since such a screenshot does not provide any opportunity to the author or us to learn about the underlying cause of the error, an unnecessary clarification turn around and an accompanying delay always occurs in this case... This is certainly bad for both sides and thus is something we seek to avoid.

Possible solution

With v16.2, XAF WinForms apps will display a better error dialog while you are debugging your app:

We have not integrated a similar thing in the Web UI yet because the ASP.NET platform already provides quite a rich error page where the original problem was less noticeable, at least according to our internal figures.

Notice that the extended error form now  not only displays the top-most error message, but also shows the full call stack for you to research or copy to the DevExpress support crew, if necessary. At the bottom, there is also a link to the new help article describing the most common troubleshooting techniques that should help you save time and hunt "bugs" more effectively. In the majority of cases, these pointers should be sufficient to either research/fix your own custom code or submit an effective ticket to the Support Center, if the underlying issue has something to do with DevExpress routines.

This dialog should NOT appear when no debugger is attached to your app, e.g., when your end-users use your app in production - the former dialog will be shown there to avoid any possible confusion concerning technical details, as in previous versions.

Your feedback is needed!

We hope this will help our users and us to eliminate unnecessary delays and speed up overall problems troubleshooting in Visual Studio. As always, we are also looking forward to hearing from you on this small, but necessary service feature. For instance, to better communicate to developers that it is for development time only, we are also thinking about appending something like " (Debugging...)" to the form title, near the app name or adding some clarification tooltip on mouse hover. Or, is it already clear enough? Please let me know what you think. 

I also welcome other thoughts on solving the original problem in case we overlooked something.