Feedback: DevExpress Layout Control Main Demo

Technorati Tags: C# , Programming , DevExpress , Developer Express , Layout Control , Feedback

 

Here is a screen shot of the Developer Express Layout Control Main Demo:

 

If I click a feature, such as Validating, I get a screen shot similar to this:

 

Its a nice demo - I want to learn from it, and so I open the source code for the demo that is included with my subscription where I see something in VS2005 similar to this:

 

Hmm... there are a LOT of custom User Controls and I start looking/ learning (as I suspect most users may) by looking at the main form (frmMain) and attempt to "go backwards" through the code. Here is the code behind frmMain.cs:

 

I highlighted where the form inherits from a base form "DevExpress.DXperience.Demos.frmMain". Can you see it in the rectangle? Its a little frustrating to chase down code in a demo, but hey... okay... so I click on "Go to Definition" and this is what I get:

 

* This is my summary *

First (metatdata): Notice... or... look carefully... the base or inherited class I chased down (the very first step I took to understand the demo code) is "FROM METADATA" and this is just "wrong" (IMO) - for any demo. Isn't a demo supposed to include the code? Inheriting from classes that are not included is not the best choice (IMO). I found numerous objects that inherit from classes that are not contained directly in the demo.

DevExpress: Please, do NOT create a demo that utilizes custom controls or features that are hidden within your source code library! I am fairly certain that the base class "frmMain" is not a standard control for your library and I am also certain that this confuses users and does not help them. Why is this "frmMain" not part of the demo solution? I certainly can understand that some elements are common to many demo solutions, but they should simply be referenced as a separate "common"  project, should they not? The common projects should be included DIRECTLY in each demo solution.

Second (organization): I started "browsing" the code and looked at the "BaseControl" which inherits from some TutorialControl which is located in a file named DemoControls.cs; yet the BaseControl is not part of DemoControls, it is special and gets its own file.  However, for some reason the LayoutAppearanceMenu is also located in the DemoControls.cs file. What I am getting at is that there is  a very difficult to follow pattern for why certain classes are located within certain files. There really needs to be some organization and logic followed to make it easy to locate objects. A possible simple approach I might recommend would be a file for every class. Grouping classes into files without clear understanding of any reasoning for grouping them makes the code more difficult to understand.

Why is the "TutorialControl" and the "LayoutAppearanceMenu" contained in DemoControls? I don't see the logical relationship here... maybe someone else does???

 

Third (Isolation): These demos, obviously, offer many benefits. For example, I was trying to understand how to properly deal with Visual Inheritance and understand Visual Studio's problem with collection members in inherited or derived forms. To understand: if someone adds a DevExpress LayoutControl to a base user control or form and then tries to inherit or derive a form from that base, the LayoutControl would be unusable in the designer because Visual Studio does not support adding, removing, or changing collections via the designer in a derived form when the source collection is in a base class. 

So why am I mentioning isolation?

Well, I suspect most users look at the choices within a Demo or the "Features" such as Validating, Localization, Image Layout , etc and they just want to understand that specific feature. This really screams or demands that code is NOT inherited. Most users (I suspect) want to see the all the code in one spot, where they can follow the logic, where they don't chase down inheritance, and where they don't get confused where pieces of the puzzle aren't even located within the demo. I suggest that each "feature" be self-contained and easy-to-follow.

 

This post is not meant to be a complaint, it is meant to suggest what I feel is the perspective of the typical end-user - the one who actually needs and uses the various demos. I am trying to share the overall experience and I simply feel the experience could be improved. Ironically, there is no specific demo for visual inheritance - it is addressed in every demo. I consider Visual Inheritance, custom user controls, deep inheritance chains, etc. to be advanced examples. It just does not seem right to make every demo based on advanced functionality and I stand by my premise that no demo should be pieced together with significant custom code elements that are not included in the demo directly, such as the frmMain.cs file I highlighted.