Search This Blog

Wednesday, December 7, 2016

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.

Wednesday, November 30, 2016

How long since you have seen the "Dictionary already contains ClassInfo ..." error for the Model Editor?

Old XAFers can remember this old sporadic issue caused by a Visual Studio bug that could not be fixed on the IDE side for years (learn more...). We were frustrated by it no less than our users, and this April (15.1.11+, 15.2.8+, 16.1+) we finally found a way to bypass this nasty behavior of an internal IDE assemblies cache on our side by changing the process of  loading assemblies at design time. This was quite a risky change, but so far our testing of many projects under various circumstances went well. We also have not received user reports on the original problem or other side effects with our designers since then (more than 8 months).



That said, I wanted to explicitly clarify with the XAF community whether it is really gone after our changes or not. Please leave a comment below on whether you have seen this error with the latest XAF versions OR you already cannot recall when it occurred last time. If this still bothers you, I would kindly ask you submit a ticket using the Support Center and attach a project where this behavior is stably reproducible, exactly as this kind guy did in the past.

My team and I look forward to hearing from you!

Tuesday, November 8, 2016

How to show a specific View at application startup, right after the logon window or after loading the main window

I have recently updated my old KB article with several solutions and wanted to bring this for your information:


Here is the information on typical scenarios to get a better understanding of where this article can be applied: 

"One may want to show a dialog view at startup (after logging in). Typically, this view appears after the successful logon and allows a user to select or edit personal or global settings such as current password, company, currency, language, etc. Also, it may be often required to display this View as modal before a user can access the navigation menu or any other forms in the application. In other scenarios, it may be required to display a kind of notifications popup right after loading the main window, with unread messages, active orders, etc."





As always, it would be great to hear whether you are already using these techniques (specify approach #) in your XAF apps or you had to invent new solutions for a similar task. I am looking forward to hearing from you in the comments.


Monday, October 17, 2016

Welcome the EnableMultipleBrowserTabsSupport feature toggle for an XAF Web app - YOUR FEEDBACK IS NEEDED

Starting with v16.1.8+, we have made improvements for a quite popular ASP.NET scenario - working with several independent XAF views within tabs of the same web browser instance. Previously, it was not easily possible as the XAF web site stored the information about the current main window within the ASP.NET session between requests (learn more...). Technically, it still does, but now each loaded web window has a unique identifier by which all its requests are correctly routed on the server.

Now, with the new EnableMultipleBrowserTabsSupport feature toggle for your Web application, you can, for instance, include hyper links to two different XAF views into a customer email, and clicking these links subsequently would result into opening two separate browser tabs with the ability for an end-user to work with them independently.


To test this functionality in your Web project, do the following:
1. Install this hot fix build (or any other v16.1.8+ build when the link stops working);
2. Modify the YourSolutionName.Web/Global.asax.cs file to set the static WebApplication.EnableMultipleBrowserTabsSupport  property to True in the constructor or the Application_Start method. For instance:

namespace XCRM.Web {
    public class Global : System.Web.HttpApplication {
        public Global() {
            DevExpress.ExpressApp.Web.WebApplication.EnableMultipleBrowserTabsSupport = true;

So far, our tests were pretty stable, and we have not found any issues in standard XAF Web scenarios. We still want to collect more feedback and hear from you about how this works in your real projects. The more scenarios we cover at this stage, the better for the product. Take special note that this will still be in the preview state in XAF v16.1. If all goes according to plan and if nothing serious is found, this functionality will be officially released in the upcoming 16.2 build, which should be out around early December.