Wo fügt die IDE ein ON-Event ein?

[Perlsau]

Für meine Zwecke bzw. mein Sortierschema wäre es sinnvoll, wenn eine neue Methode, die ich z.B. via Shift-Ctrl-C erstelle, genau dort eingefügt wird, wo analog dazu die Methodendeklaration steht. Meine Sortierung sieht meist so aus:

Delphi-Quellcode:

    Procedure FormCreate(Sender                  : TObject);
    Procedure FormShow(Sender                    : TObject);
    Procedure FormActivate(Sender                : TObject);
    Procedure FormCloseQuery(Sender              : TObject; var CanClose: Boolean);
    Procedure FormClose(Sender                   : TObject; var Action: TCloseAction);
    Procedure FormDestroy(Sender                 : TObject);

    Procedure PgCtrl_MainChange(Sender           : TObject);
    Procedure PgCtrl_RechercheChange(Sender      : TObject);
    Procedure PgCtrl_LandChange(Sender           : TObject);
    Procedure DBGrid_KontinentColumnMoved(Sender : TObject; FromIndex, ToIndex: Integer);
    Procedure DBGrid_StaatenColumnMoved(Sender   : TObject; FromIndex, ToIndex: Integer);
    Procedure DBGrid_WaehrungColumnMoved(Sender  : TObject; FromIndex, ToIndex: Integer);
    Procedure DBGrid_KontinentTitleClick(Column  : TColumn);
    Procedure DBGrid_StaatenTitleClick(Column    : TColumn);
    Procedure DBGrid_WaehrungTitleClick(Column   : TColumn);
    Procedure DBRich_KontinentURLClick(Sender    : TObject; const URLText: string; Button: TMouseButton);
    Procedure DBRich_StaatenURLClick(Sender      : TObject; const URLText: string; Button: TMouseButton);
    Procedure DBRich_WaehrungURLClick(Sender     : TObject; const URLText: string; Button: TMouseButton);

    Procedure Panel_StaatenResize(Sender         : TObject);
    Procedure Panel_WaehrungResize(Sender        : TObject);

    Procedure Lbl_Staaten_WikiDblClick(Sender    : TObject);
    Procedure Check_WaehrungPicsClick(Sender     : TObject);

    Procedure AL_DB_LoginExecute(Sender          : TObject);
    Procedure AL_DB_LogoutExecute(Sender         : TObject);
    Procedure AL_DB_NewUserExecute(Sender        : TObject);
    Procedure AL_DB_CloseExecute(Sender          : TObject);
    Procedure AL_ED_AppendExecute(Sender         : TObject);
    Procedure AL_ED_DeleteExecute(Sender         : TObject);
    Procedure AL_ED_EditExecute(Sender           : TObject);
    Procedure AL_ED_PostExecute(Sender           : TObject);
    Procedure AL_ED_CancelExecute(Sender         : TObject);

Die Reihenfolge der Form-Ereignisse entspricht der Reihenfolge ihres Auftretens. Die Reihenfolge der untenstehenden ActionList-Ereignisse entspricht einerseits der Reihenfolge in der Actionlist, andererseits auch der Reihenfolge in den entsprechenden Menüs. Ebenso entspricht die Reihenfolge der PageControl-Ereignisse der Reihenfolge, in der die Pagecontrols im Formular angeordnet sind. Ob man das automatisiert anordnen kann, bezweifle ich, und wenn, dann nur mit enorm hohem Aufwand. Leider muß ich eben nicht nur die Methoden-Deklarationen im Interface-Abschnitt von Hand sortieren, sondern immer auch die Methoden im Implementation-Abschnitt. Aber was soll's, ich hab mir das längst angwöhnt und mach's inzwischen fast automatisch.

[Der schöne Günther]

Ich habe überhaupt keine Sortierung. Ich packe die Deklarationen der VCL-Eventhandler sogar noch immer in eine Region damit ich sie nicht sehen muss

[Medium]

Perlsau, du spricht aus, was ich beim Lesen dieses Threads dachte. Ich hätte es auch am aller liebsten, wenn die Completion immer so einfügt, wie es im Deklarationsteil sortiert ist. Am besten auch noch nach Sichtbarkeit gruppiert. Und beim Implementieren abgeleiteter Methoden diese auch in der Reihenfolge in der sie in der Basisklasse deklariert sind, jedoch vor allen in der aktuellen deklarierten.
Gerade bei Get* und Set* macht mich das immer "traurig", weil ich viel lieber Getter und Setter einer Property besammen habe, statt aller Getter und dann alle Setter.

[Perlsau]

Genau dort nervt mich diese wilde Platzierung von Methoden ganz besonders. Daher hab ich mir angewöhnt, nicht nur bei Properties immer nur eine Deklaration auf einmal zu machen, dann bleibt die Sucherei im Rahmen. Auch bei der automatischen Deklaration von Komponenten-Ereignissen (Aktionslisten, Buttons usw.) nervt die Sucherei. Mit meinem Sortierschema verschwende ich keine Zeit damit, die nächste Buttonklick-Methode zu finden oder erst einmal zum Anfang der Unit springen zu müssen, um die nächste Methode mit Strg-Mausklick zu sehen. Dabei wäre es sicher irgendwie möglich, die Deklaration von Komponenten-Methoden und die entsprechenden Methoden, die man erzeugt, so anzuordnen, wie die Komponenten im Interface-Teil angeordnet sind:

Delphi-Quellcode:

TYPE
  TFormMain = CLASS(TForm)
    AktionsListe               : TActionList;
    AL_DB_Login                : TAction;
    AL_DB_Logout               : TAction;
    AL_DB_NewUser              : TAction;
    AL_DB_Close                : TAction;
    AL_ED_Append               : TAction;
    AL_ED_Delete               : TAction;
    AL_ED_Edit                 : TAction;
    AL_ED_Post                 : TAction;
    AL_ED_Cancel               : TAction;
    AL_ED_Open                 : TAction;
    AL_ED_Save                 : TAction;
    AL_ED_Print                : TAction;
    AL_ED_Find                 : TAction;

    HauptMenu                  : TJvMainMenu;
    HM_DB                      : TMenuItem;
    HM_DB_Close                : TMenuItem;
    HM_DB_Login                : TMenuItem;
    HM_DB_Logout               : TMenuItem;
    HM_DB_NewUser              : TMenuItem;
    HM_DB_1                    : TMenuItem;
    HM_ED                      : TMenuItem;
    HM_ED_Append               : TMenuItem;
    HM_ED_Delete               : TMenuItem;
    HM_ED_Edit                 : TMenuItem;
    HM_ED_Post                 : TMenuItem;
    HM_ED_Cancel               : TMenuItem;
    HM_ED_1                    : TMenuItem;
    HN_ED_Open                 : TMenuItem;
    HM_ED_Save                 : TMenuItem;
    HM_ED_Print                : TMenuItem;
    HM_ED_Find                 : TMenuItem;

    StatBarMain                : TJvStatusBar;

    Panel_Navi                 : TPanel;
    BitNavi_Append             : TJvBitBtn;
    BitNavi_Delete             : TJvBitBtn;
    BitNavi_Edit               : TJvBitBtn;
    BitNavi_Post               : TJvBitBtn;
    BitNavi_Cancel             : TJvBitBtn;
    BitNavi_Load               : TJvBitBtn;
    BitNavi_Save               : TJvBitBtn;
    BitNavi_Print              : TJvBitBtn;
    BitNavi_Find               : TJvBitBtn;
    BitNavi_Close              : TJvBitBtn;

    PgCtrl_Main                : TJvPageControl;
    TS_Zentrale                : TTabSheet;
    TS_Recherche               : TTabSheet;
    PgCtrl_Recherche           : TJvPageControl;
    TS_Recherchieren           : TTabSheet;
    TS_Kategorien              : TTabSheet;

    TS_Land                    : TTabSheet;
    PgCtrl_Land                : TJvPageControl;
    TS_Kontinente              : TTabSheet;
    Panel_Kontinent            : TPanel;
    DBGrid_Kontinent           : TJvDBGrid;
    DBImg_Kontinent            : TJvDBImage;
    Panel_KontinentEdit        : TPanel;
    DBEd_Kontinent             : TJvDBMaskEdit;
    DBSpin_Kontinent_Flaeche   : TJvDBSpinEdit;
    DBSpin_Kontinent_Einwohner : TJvDBSpinEdit;
    DBSpin_Kontinent_Dichte    : TJvDBSpinEdit;
    DBSpin_Kontinent_Laender   : TJvDBSpinEdit;
    DBRich_Kontinent           : TJvDBRichEdit;
    Lbl_Kontinent              : TLabel;
    Lbl_Kontinent_Flaeche      : TLabel;
    Lbl_Kontinent_Einwohner    : TLabel;
    Lbl_Kontinent_Dichte       : TLabel;
    Lbl_Kontinent_Laender      : TLabel;

    TS_Staaten                 : TTabSheet;
    DBGrid_Staaten             : TJvDBGrid;
    Split_Staaten              : TJvSplitter;
    Panel_Staaten              : TPanel;
    DBEd_Staaten_Staat         : TJvDBMaskEdit;
    DBLU_Staaten_Waehrung      : TJvDBLookupCombo;
    DBLU_Staaten_Kontinent     : TJvDBLookupCombo;
    DBEd_Staaten_Hauptstadt    : TJvDBMaskEdit;
    DBEd_Staaten_Wiki          : TJvDBMaskEdit;
    DBSpin_Staaten_Einwohner   : TJvDBSpinEdit;
    DBEd_Staaten_KFZ           : TJvDBMaskEdit;
    DBEd_Staaten_Vorwahl       : TJvDBMaskEdit;
    DBEd_Staaten_TLD           : TJvDBMaskEdit;
    DBEd_Staaten_HDI           : TJvDBMaskEdit;
    DBEd_Staaten_Iso           : TJvDBMaskEdit;
    DBRich_Staaten             : TJvDBRichEdit;
    DBImg_Staaten_Wappen       : TJvDBImage;
    DBImg_Staaten_Flagge       : TJvDBImage;
    Lbl_Staaten_Staat          : TLabel;
    Lbl_Staaten_Kontinent      : TLabel;
    Lbl_Staaten_Waehrung       : TLabel;
    Lbl_Staaten_Hauptstadt     : TLabel;
    Lbl_Staaten_Wiki           : TLabel;
    Lbl_Staaten_Einwohner      : TLabel;
    Lbl_Staaten_KFZ            : TLabel;
    Lbl_Staaten_Vorwahl        : TLabel;
    Lbl_Staaten_TLD            : TLabel;
    Lbl_Staaten_HDI            : TLabel;
    Lbl_Staaten_Iso            : TLabel;

    TS_Waehrungen              : TTabSheet;
    DBGrid_Waehrung            : TJvDBGrid;
    Split_Waehrung             : TJvSplitter;
    Panel_Waehrung             : TPanel;
    DBEd_Waehr_Waehrung        : TJvDBMaskEdit;
    Lbl_Waehr_Waehrung         : TLabel;
    DBLU_Waehr_Einheit         : TJvDBLookupCombo;
    DBLU_Waehr_Einteilung      : TJvDBLookupCombo;
    DBLU_Waehr_Kuerzel         : TJvDBMaskEdit;
    DBDate_Waehr_Datum         : TJvDBDateEdit;
    TimeEd_Waehr_Zeit          : TJvTimeEdit;
    DBSpin_Waehr_Kurs          : TJvDBSpinEdit;
    DBLU_Waehr_Iso             : TJvDBMaskEdit;
    DBLU_Waehr_IsoNum          : TJvDBMaskEdit;
    Check_WaehrungPics         : TCheckBox;
    DBRich_Waehrung            : TJvDBRichEdit;
    Lbl_Waehr_Einheit          : TLabel;
    Lbl_Waehr_Einteilung       : TLabel;
    Lbl_Waehr_Kuerzel          : TLabel;
    Lbl_Waehr_Iso              : TLabel;
    Lbl_Waehr_IsoNum           : TLabel;
    Lbl_Waehr_Kurs             : TLabel;
    Lbl_Waehr_Datum            : TLabel;
    Lbl_Waehr_Zeit             : TLabel;

    TS_Kurse                   : TTabSheet;
    TS_Optionen                : TTabSheet;

[Namenloser]

Zitat von Medium:

Ich hätte es auch am aller liebsten, wenn die Completion immer so einfügt, wie es im Deklarationsteil sortiert ist.

Oh Gott, ja! Aber nicht nur Delphi braucht dieses Feature, andere IDEs auch.

Ich hab es inzwischen leider aufgegeben, die Routinen im Implementierungsteil von Hand zu sortieren. Inzwischen ist mir alles egal, die liegen da einfach nur noch kreuz und quer... (allerdings zumindest nach Klassen gruppiert). Wenn ich etwas bestimmtes suche, gehe ich den Umweg über das Interface oder Strg+F muss herhalten.

[stahli]

Ich hab´s auch aufgegeben: http://www.delphipraxis.net/180583-m...ihenfolge.html

[Dejan Vu]

Der verständlich Drang, Ordnung is Chaos einer TForm-Unit zu bringen, ist verständlich.
Aber wenn man Frames nähme, würden sich die Probleme hier gar nicht so stark äußern, denn dann hätte man auch in der UI das SRP weitestgehend abgebildet: Jeder einzelne Frame wäre dann so übersichtlich, das man auf eine logische Gruppierung der vielleicht 5-10 Events verzichten könnte, zudem die IDE einem sehr komfortable Navigationshilfen bietet.

Jedenfalls wäre ein TForm-Ungetüm in der Art

Delphi-Quellcode:

TYPE
  TFormMain = CLASS(TForm)
    AktionsListe               : TActionList;
    ...
    // gefühlte 100 Zeilen später
  end;

per se aufgeräumter (Deklaration und Code)

Delphi-Quellcode:

TYPE
  TFormMain = CLASS(TForm)
    Aktion : TActionFrame;
    HauptMenu : TMenuFrame;
    Buttons : TButtonFrame;
    Staaten : TStaatenFrame;
    Waehrungen : TWaehrungenFrame;
    StatBarMain : TJvStatusBar;
...
  end;

Auch werden hier kaum noch Events bedient (außer die der Form, versteht sich). Und ob man da denn nun wirklich die alphabetische Reihenfolge *benötigt*, sei mal dahingestellt, obwohl der Codeformatter einem das ja anständig aufräumt.

Eine aufgeräumte UI geht aber nur bei aufgeräumtem Model (Klassen), womit es folgerichtig fast unmöglich ist, seinen Spaghetticode nachträglich so aufzuräumen, Andererseits ist es aber sehr praktisch: Fängt man an, sich zu zwingen, die UI in einzelne Komponenten/Frames nach dem SRP-Prinzip zu unterteilen, landet man zwangsläufig bei aufgeräumtem Code. Man kotzt so lange rum, bis alles irgendwie passt, und man bei etwas Ähnlichem wie MVVM landet. Man kann ja nicht aus einem Frame einfach die Funktion eines anderen Frames aufrufen, denn die kennen sich ja nicht mehr: Im Gegensatz zum Spaghetti-Form, wo Menu_fooBar durchaus Lbl_Schießmichtot kennt.
Frame A kennt nur das VM, aber Frame B auch und wenn nun A im VM rumändert, kann das VM dies über ein Notify-Event publizieren und Frame B kann sich entsprechend updaten.

Allerdings verlässt man dann das R vom RAD (Rapid Application Development) und arbeitet eher im SACADWALOC (Slow and Clean Application Development with a lot of Code) Bereich. Vorteil ist dann aber, das die Maintenance, Skalierbarkeit und Erweiterbarkeit wesentlich nachhaltiger ist. Aber das Wichtigste ist (meine Erfahrung): Beim MVVM verstehen auch andere Programmierer, was man meint.

[stahli]

Das ist schon richtig, aber selbst in einem Frame oder bei einer Komponentenentwicklung würde ich mir eine übersichtlichere Strukturierung wünschen.

Zuerst gehören (wenn man schon immer eine komplette Unit im Editor hat) m.E. die Kontruktoren und Destruktoren und danach alle Methoden in der Reihenfolge der Deklaration, wobei eine explizite Zusammenfassung der Getter und Setter jeweils noch sinnvoller wäre.

Wenn das Delphi optional anbieten würde wäre das eine nützliche Sache und auch nicht störend, weil man es dann ja ausschalten könnte.

[Sir Rufo]

Auch ich empfinde es als störend, denke dann an die Fliege im Urinal und sage mir "Ist doch auch egal"