Search This Blog

Wednesday, February 14, 2018

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.

  1. The customization forms will preserve their size and position. In the Model Editor, the settings will be stored permanently either in the Application Model (runtime) or in the *.SUO file (design time). The same form at runtime will maintain its settings during application life time only. This small difference is intentional: it should still be convenient to make several extensive customizations at once, but will certainly avoid any possible confusion and support calls from end-users saving and forgetting their forms in some unexpected place/state. This must work fine with multiple monitors, tabbed MDI and SDI, multiple root and nested Views (last closed form settings win). Anyway, should you notice anything unexpected here during your tests, please let us know.
  2. The customization forms will have the search box enabled by default. In real world applications with 100-200 items it should greatly save time on searching a required item.
  3. The customization forms will handle the Up/Down Arrow and Delete keys to quickly navigate or remove items in the main list. Again, it must save time in complex apps.
  4. The last item added from the Object Model dialog will be focused in all the customization forms. We experimented with this a few months ago and decided to enable this helpful function everywhere.
  5. Finally and not related to the customization forms, we have enabled the behavior shown in this blog post by default. Note that here we intentionally did not add another grouping level by namespace, not to complicate access, but we welcome to your thoughts on it.

As always, my team and I welcome your feedback on these improvements if you want to test the nightly 17.2 build: DevExpressNETComponents-17.2.exe. This test build does NOT yet include certain functionalities for the PivotChart, TreeListEditor and PivotGridListEditor, so test them with the GridListEdior and DetailView's layout for now. Should you have problems with the customization forms or anything else, we will be more than happy to listen and help.


  1. Great improvements to improve usability. There have been a few updates to the model editing that has saved us countless hours.

    Improvement for the future may be to show the full path of a property in the dialog with a tooltip when hovering over it. This is useful when trying to find a property with the same name in 2 different objects. Example: Client.Name vs Client.Company.Name. Both show up as Name in the customization dialog.

  2. I'll support Dave's suggestion. In fact the same problem occurs in the column customization in the list views and trickles down to the actual list view confusing the end user about which exactly column it is.

  3. Thx for this Guys - i just tested it and i noticed that position is not saved for TreeListEditors!

    And i also support Dave and Evgeniy, in fact it is the same as we discussed yesterday Dennis!

  4. Hello,
    I have exactly the same problem as Dave described. I hope it will be addressed too.

  5. It's a pity we cannot post images here, but we've rolled our own changes to the run-time layout dialog/selection - which I could demonstrate for discussion. I might have even added the code to a DX suggestion a few years ago.

    (Cue gripes about no longer having a XAF community forum etc)

    For indented fields we add a prefix, so e.g. if we've added a field SalesOrder.Consumer.AccountStatus, in the layout window this is displayed as [Customer].Account Status (note it uses model naming for the indented properties). We did tinker with \ delimited captions, but this did not look good.

    In terms of what would be useful to us, a multi-select remove fields facility.

  6. Also, Dennis if you look at my screenshot on FB I think there might be an issue with font sizes/scaling on the 'Hidden Items' & 'Layout Tree View' tabs. This is running on 17.2.4 iirc, a multi-monitor setup, 40" 4K monitor, Win 10 and a whopping 350% setting for custom scaling. There are also issues on the list itself.

  7. In terms of tooltips in the layout selector, we've coded our own data-driven property selectors for another task (adding merge fields to templates). For this selector we've added tooltips.

    What was handy for us was to show the property name and then if the property had been recaptioned in the model to also show the original property name in parenthesis. Also, to include the value in the model tooltip. We also show the data type, but this might be OTT for end-users.

    So something like a Shipment Property might have a tooltip like:

    |Consignment (Shipment)
    |The consignment associated with this Sales Order transaction.

    The reason for including the original property name is that often customers will report an issue and it can take some time to understand as they'll have renamed properties/classes in the model.

  8. FWIW,

  9. @Dave, Evgeniy, Martin, Pawel, Chris: I have been waiting for this feedback, because was already on my list, but I wanted more confirmations. We will take it into account for the future.

  10. @Martin: I overlooked it as this test build did not cover it yet. I hope that TreeListEditors will be covered in v17.2.6 (official).

    Agreed. It's very similar to what we discussed in

  11. @Chris: I've logged a private ticket for your High DPI issues.
    Thanks for describing your additional problems and implementations - we will take them into account.
    BTW, you may also be interested in checking the link from my previous comment to see how Martin approached fields identification in the layout customization's property grid. Just in case end-users will be confused with showing original property name in tooltips.

    1. Hi @Dennis, thanks for creating a ticket... I was happy to live with the issue until/if it was raised by a customer. Having said that, Nadezhda suggested I add a manifest file to my existing app & that appears to have resolved the issue.