Ticket T439521
Visible to All Users

Enabling/disabling code templates is a slow, frustrating experience

created 8 years ago

CR ships with a lot of templates that I don't care about or use. I don't want them getting in the way of either templates I've defined or Intellisense. Therefore when setting up a new CR instance I go through and disable almost all the templates. This is a painful and tedious process. It is also likely to break the few templates that I do care about. Here's my list of issues with this process.

The first issue I struggle with is that I can disable an entire folder of templates but most folders have 1 or 2 templates I care about and the rest I don't. I have to select each one and disable. I'd prefer to be able to do something akin to checkboxes where the enable/disable state of a folder is based upon whether some or all the templates in it are set. I could then disable an entire folder and then enable the specific templates I want. As an alternative allow for selecting multiple templates for enable/disable.

The second issue is with System templates. A system template, to me, is a template that is really designed to be used by other templates. In the default templates they tend to start with #. System templates are mixed in with other templates. There is a System folder for some system templates but most system templates tend to be nested under subfolders. System templates seem to be used heavily by other templates so disabling a system template breaks templates that may not even be in the same folder. As an example, if I want to create a custom template that generates a specific property I'm going to rely on the system template #ReadWritePropertyRouter#. I tend to not use any of the default property templates so I would normally disable the entire Properties folder. But that would disable the system and generic system templates. So, because of the issue mentioned earlier, I'd have to enable the Properties templates and then navigate each of the child folders and ensure the Generics\System and System folders are enabled but the remaining templates are not.  Ideally all templates that are designed to be used by other templates (i.e. the # system templates) should be contained under the root System folder (in child folders for organization). I could then ensure that System root is enabled and disable the other folders.  This would also force me, as a template creator, to consider whether I should depend upon other templates beyond the system templates that are designed for reuse.

Comments (1)
DevExpress Support Team 8 years ago

    Hi Michael,

    Thank you for contacting us and sharing your ideas. We really appreciate this.
    We find both ideas useful for our product and will consider implementing them in the next updates.

    To address these ideas more efficiently, I created two tickets, describing each of them separately: Exporting settings to a file that exists fails and Templates that are designed to be used by other templates should be contained under the root System folder.

    These tickets are currently in our processing queue and we will answer them shortly.

    Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

    Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.