0

I just created a new VCL application and placed the following controls on the form in this order:

  1. MainMenu
  2. ToolBar
  3. StatusBar

The controls appear in the TForm class in the order I added them to the form. When I compare the TForm class to the DFM the controls are in a different order.

Class:

type
  TForm5 = class(TForm)
    MainMenu1: TMainMenu;
    ToolBar1: TToolBar;
    StatusBar1: TStatusBar;
  private
    { Private declarations }
  public
    { Public declarations }
  end;

DFM (properties removed for illustration purposes)

object Form5: TForm5
  object ToolBar1: TToolBar
  end
  object StatusBar1: TStatusBar
  end
  object MainMenu1: TMainMenu
  end
end

I'd like to order the controls in the class definition so they match the DFM file. Is there an option within the IDE to do this?

Michael Riley - AKA Gunny
  • 5,074
  • 4
  • 42
  • 89
  • Why, Mike? The .DFM file is the property of the IDE. What difference does it make what order they're streamed out to the .DFM? The only (rare) occasion you're usually touching the .DFM is to try to undo something that you've done that broke it or to remove a property that can't be there for compatibility reasons. But no, there is no such option in the IDE. – Ken White Dec 23 '14 at 01:33
  • Because over time when building an application controls are added to the class in the order they are introduced. It would be nice to have a quick way of grouping all the items within the class definition. For example: suppose you add two new options to the main menu later on... now those items appear at the bottom instead of up where the other menu items are listed. – Michael Riley - AKA Gunny Dec 23 '14 at 01:37
  • There's no way to sort either the .DFM or the class definition. You can always arrange them yourself in the class definition, but the IDE just adds them in the order they're created and there's no option to do otherwise. I have to admit I've never found this to be an issue, because the Object Inspector can locate them pretty quickly; its drop-down list *is* sorted by component name. – Ken White Dec 23 '14 at 01:42
  • 1
    @Cape - Use edit->creation order to change the order of non visual components. Not for menu items though, use the menu designer to change item order - it is reflected in the dfm. – Sertac Akyuz Dec 23 '14 at 01:46
  • There is no utility in having any form of organisation in that area at all. It may as well not even exist. You cannot edit those declarations directly, so being able to find them in the **editor** is useless. You can only [reliably/safely] change them via the Object Inspector, which as Ken says already takes care of ordering them for you. For more contextual groupings you have the visual design itself (all the menu items for a menu are... *in that menu in the menu designer*). Why do you care what order the declarations are in the class definition ? – Deltics Dec 23 '14 at 01:47
  • 1
    @Deltics - I've never forced myself to look at the "Structure" pane, I've always gone straight to the code page. Besides I might be OCD (Obsessive Compulsive Delphi) – Michael Riley - AKA Gunny Dec 23 '14 at 01:58
  • @CapeCodGunny - but what is it that you think you can do in the code pane for/with these declarations ? You cannot rename the components there; you have to use the *Object Inspector* for that and the Object Inspector has those names in an alpha sorted list for you. The Structure Pane gives you an alternate, 'DFM content' ordered organisation. both of these alternate views give you access to the things they present (component properties). Where-as the *code view* provides no such access. I'm just trying to get a handle on the need/requirement/motivation here. What's the user story ? :) – Deltics Dec 23 '14 at 02:03
  • @Deltics - You can rename using refactor Ctrl-Shift-E. I find this renaming technique much faster than using the object inspector. – Michael Riley - AKA Gunny Dec 23 '14 at 03:01
  • Aah, OK. That makes some sense. I have to say though that you are fortunate indeed to work with forms where the components are already named in a way that allows you identify them purely by name for the purpose of ... um ... changing their name. :) I sadly more often find myself dealing with Label1, Label2, Button1, Button2 etc. (not in my projects, I hasten to add. My day-to-day mostly involves working on other people's). – Deltics Dec 23 '14 at 05:36
  • Probably worth adding that to the question as an example of why/how it is useful, and also then clarifying the Delphi version being used since of course this refactoring user story is not relevant in all Delphi versions. – Deltics Dec 23 '14 at 05:43
  • This might actually be a useful addition to GExperts. Maybe I'll find some time during the "holidays" to implement it (which is unlikely but one can dream...). It should also allow to sort the event declarations which I personally would find much more useful than sorting the component declarations. – dummzeuch Dec 23 '14 at 10:52

1 Answers1

1

As noted in the comments to the question, there is no such mechanism in the standard IDE and the utility of any such mechanism (or outcome) is dubious and limited at the very best.

But if you absolutely must have some sort of order/organization in this area and do not wish to have to arrange these declarations manually, then I would simply use the GExperts "Sort source lines" editor tool periodically, as required to maintain the order/grouping you desire.

Select the declarations you wish to sort and sort ascending or descending according to preference.

As long as you have consistently named all your components this will give you any 'grouping' you desire, as long as you enforce that by a sort order embodied in your component naming convention. e.g. all menu items begin "mi...", all File menu items then beginning with "miFile..." etc etc.

However, you are then at the mercy of your names to determine the resulting order. For example a hypothetical set of File menu items will end up as:

miFileExit
miFileNew
miFileOpen
miFilePrint
miFileSave
miFileSeparator1
miFileSeparator2

Which is almost certainly not the order in which they appear in the menu itself. But why this should matter is not clear and, as a way to facilitate the location of declarations, an alpha sort is most likely to be useful to a human who doesn't have a copy of the persisted form component declaration order in their head.

Deltics
  • 22,162
  • 2
  • 42
  • 70