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. 


These controls are technically descendants of the standard System.Web.UI.WebControls.Table class with a few nested controls inside (buttons and the actual editors: text box or combo box).

A customer wanted to disable tab stop for the lookup editor and this typical task can be accomplished in ASP.NET by setting the standard WebControl.TabIndex property.

While testing this simple solution I found that the focus still goes to the editor's buttons, which requires more work from the developer to access these buttons and set the TabIndex property for them.
Since I am a bit "lazy" developer (like any XAFer out there;-)), I decided to improve usability in this common scenario by modifying the ASPxLookupFindEdit or ASPxLookupDropDownEdi classes in the following manner:

        public override short TabIndex {
            get {
                return base.TabIndex;
            }
            set {
                base.TabIndex = dropDown.TabIndex = newButton.TabIndex = clearButton.TabIndex = value;
            }
        }

As you can see, the container control now more cares about its children to help you write less code in this scenario:

                if(propertyEditor.FindEdit != null) {
                    propertyEditor.FindEdit.TabIndex = -1;
                }
                if (propertyEditor.DropDownEdit != null){
                    propertyEditor.DropDownEdit.TabIndex = -1;
                }

It is a small improvement, but hopefully you will like it. BTW, I also exposed public properties to access the editor's New, Find and Clear buttons, which may be helpful for you as well.
After writing the unit test, I tested how this works in the MainDemo app, and I must admit that it become more usable, because you do not need to skip tab over several buttons.

This improvement will be available with the version 13.1.6 and higher.

UPDATED:
Starting with v15.1 you can remove this customization code completely, because the ASPxLookupDropDownEdit class was refactored to avoid the original problem by default. Instead of inheriting the standard Table class and adding separate button controls into table cells, we now leverage the built-in functionality of the ASPxComboBox buttons.