Learning through reading the source code

I will start this post with the new Visual Studio 2017 function, which I hope will be helpful for XAF developers too. I have both RTM and Preview versions installed, but I am mostly using the latter one for testing. The new function I spotted in their change logs is called "View decompiled source definitions instead of metadata (C#)".

As you can guess from its name, it changes the very often used "Go To Definition" command (F12) so that it displays the actual code of a C# type or member who's source code is unavailable - very useful and convenient, IMHO. It is decompiled using ILSpy, the tool I have already been using for years as default program association for opening *.dll files -  partially the reason of why this news got my attention. This experimental feature is new in Visual Studio 2017 version 15.6 preview 2+ and it must be turned on explicitly using the Tools > Options  >  Text Editor > C# > Advanced > Enable navigation to decompiled sources menu item. 

Customization Forms and Model Editor Improvements - XAF v17.2.6

Customizing Views layout, e.g., making certain fields visible, changing their locations is something that XAF developers usually learn and appreciate from day one. That is because you can drastically change the UI of your app by just moving the mouse and without any coding and recompilation, also at runtime. 

The next maintenance release (v17.2.6) should come with a few minor improvements to the customization forms in DetailView, ListView and the Model Editor, which we hope will be welcomed by both developers and end-users as well.

Beware of the failures when uploading JPEG/JPG images using the System.Drawing.Image type properties - XAF ASP.NET WebForms v17.2.5

I want to draw your attention to the T604395: Web - JPEG/JPG images cannot be uploaded to properties of the System.Drawing.Image type

 issue, which is already fixed in XAF v17.2.6. 

We apologize for the inconvenience, and if you cannot wait for the hotfix or did not plan to spend additional time on upgrade right now, please consider using the workarounds.

Important notes and workarounds

From v14.2, Image Property Editors (both WinForms and ASP.NET) support images saved as byte array objects (in addition to previously supported System.Drawing.Image objects). This allows us to significantly decrease web server memory consumption because the byte array can contain an image in a compressed format and the server does not have to unpack it. The previous approach with the System.Drawing.Image type property is still supported, but we recommend that you migrate to the byte array storage to improve performance. Refer to the BLOB Image Properties in XPO  and How to change the image property type from System.Drawing.Image to byte array help topics for more details. 

Minor improvements to the ConditionalAppearance and ViewVariants modules - XAF v17.2.6

I also wanted to inform you of some "home work" done by us in v17.2.6 to improve your XAF development experience with these modules:

GridListEditor - An appearance rule has no effect in the new item row until a value is entered into any cell
View Variants Module - ListView variant always takes the DataAccessMode value from the root node instead of own model differences, which may cause an exception due to an incompatible ListEditor type

While the first scenario is quite specific (we heard about it from our largest XAF customer and a few others), the second one was likely encountered if you use the ViewVariants module. For instance, when having one variant as a grid operating in server mode while having another variant as tree, pivot, scheduler or whatever ListView editor that does not support server mode. In the past, this unsupported configuration could cause an exception at runtime. Starting with v17.2.6, it all works as the majority our users expect - at least we believe so based on the feedback we received. The online documentation on the ViewVariants module will be updated accordingly by release time, of course. Finally, many thanks to Dave Hesketh, Martin Praxmarer, our MVPs, as well as other customers for bringing this to our attention.

If you cannot wait for the next maintenance update (v17.2.6) to test both things, install this night build: DevExpressNETComponents-17.2.exe

As always, my team and I are looking forward to hearing what you think, even on such small things and maybe others that could make your life a bit easier.

No Visual Studio designers for generic ViewController versions

XAF Controllers are technically descendants of the System.ComponentModel.Component class, primarily to be smoothly integrated with the Visual Studio design time features. The standard Component designer does not support generic classes due to a Visual Studio limitation: https://stackoverflow.com/questions/6877217/can-visual-studio-designer-show-classes-inheriting-generic-types 

This is a Microsoft functionality and we cannot do much about it on our side. So, if you have a class like this, and try to double click it or use the Enter key for it in the Solution Explorer, you will receive this error, which is expected here:

This has always caused support calls to us from day one and still causes them today. Check out this support article to learn more about this situation and our previous recommendations.

Starting with v17.2.6, we have removed the visual designer association from the base ViewController<ViewType> and ObjectViewController<ViewType, ObjectType> classes - they will always be opened directly in the Code Editor now. This should work fine in Visual Studio 2015, 2017 and newer versions. This does not work for Visual Studio 2013 and older versions and we decided not to investigate this further, because of the very low usage rate of these IDEs nowadays.

We believe that this new behavior is most expected here and really hope that it will not cause new questions😀. Originally, generic View Controllers were specially designed for users who prefer to do everything manually and want to have a more elegant and compact code. So, opening the Code Editor for such classes is naturally expected. Taking this opportunity, we also improved our online documentation to further promote generic View Controllers, since most of our Support Center answers, demos and docs use this concise code approach anyway.

My team and I are looking forward to hear from you on what you think of the new behavior.

Faster opening of a DetailView with lots of items - XAF WinForms v17.2.6

How big is the DetailView in the question? 

Well, in the T581043 ticket's test project, there are 250 editors in the detail form layout. Big enough, huh?

How much we could speed it up? 

On our powerful test machines, the time to open DetailView with just plain editors (no layout groups or tabs) has dropped from 3 seconds to almost 1. In real world applications, time to open a detail view depends on the application configuration (controllers, data, collection properties, calculated fields) and deployment specifics.

If you cannot wait for the next maintenance update (v17.2.6), install this night build: DevExpressNETComponents-17.2.exe

My team and I would be interested in hearing whether it is something you and your clients will notice too or if there are any problems with that new build. Thanks in advance.

Regards,
Dennis

P.S. If you already migrated to XAF v17.2, make sure you set XafApplication > OptimizedControllersCreation to True as well (read the prerequisites in the docs, first). The How to measure and improve the application's performance article may also help your app perform faster (magically, just after looking at it😜), so check it as well in case of problems in other scenarios.

XAF Security System enhancements in v17.2.5

After updating your XAF project to 17.2.5, you may notice a new option in the Application Designer:

The new SecurityStrategy.RolesMergingMode property specifies how the Security System determines if a user can perform a specific operation in case this user has multiple roles with different permission sets. The available modes are listed in the RolesMergingMode enumeration.