Projektweit prüfen, ob Methode als virtuell (override) im protected steht

[ZOD]

Guten Morgen zusammen,

Vorbemerkung
ich entwickle seit längerem an einem Projekt in Delphi7 (mit Anbindung an DB Firebird).
Dieses Projekt wird seit 2014 produktiv eingesetzt.
Natürlich haben sich über die Jahre sehr viele Weiterentwicklungen ergeben.
Und nicht immer wurde der Code einwandfrei gepflegt (mea culpa).
Mir ist klar, dass hier irgendwann eine große Aufräum- und Aktualisierungsaktion nötig ist.
Sobald ich die Ressourcen dafür habe .. also irgendwann ..

Zustand:
ich verwende selbstverständlich abgeleitete Formulare. Nun hat es sich ergeben,
dass im Elternformular einige Methoden von private auf protected geändert wurde.
Und zusätzlich (unsauber .. siehe oben .. ich weiß) wurden im Entwicklungsprozess
diese Methoden in den abgeleiteten Formularen neu als Klassenmethoden oder private eingebaut.

Frage:
ich möchte nun diese Fehler/Unsauberkeiten beseitigen.
Dazu muss ich herausfinden, wo diese Fehler/Unsauberkeiten gegeben sind.
Wie finde ich die entsprechenden Stellen im Code?

Das geht sicher manuell .. ist aber aufgrund der Projektgröße zeitaufwändig und evt. auch fehleranfällig.
Ich könnte die Compilermeldungen "..verbirgt die " verwenden. Das mach ich auch wenn ich sie bekomme,
aber irgendwie scheint Delphi das nicht immer anzuzeigen.

Ich suche also nach so etwas (grobe Funktionsbeschreibung):

Suche in jedem Formular nach Methode xy. Dann prüfe, ob das ein abgeleitetes Formular ist.
Wenn es abgeleitet ist und die Methode xy im Elternformular existiert, dann prüfe, ob
die Methode im abeleiten Formular im protected (oder public ) steht und ob IN der Methode ein iherited programmiert ist.

Danke für Tips hierzu!

[Der schöne Günther]

Ich glaube für einen von uns ist es noch zu früh am Morgen.

Wenn es private ist, dann ist es private. Du kannst das aus einer Unterklasse nicht mehr direkt aufrufen, auch nicht durch ein inherited .

Beispiel:

Delphi-Quellcode:

type
   TBase = class
      strict private procedure privateStuff();
   end;

   TSub = class(TBase)
      strict private procedure privateStuff();
      public procedure publicSubStuff();
   end;

{ TSub }

procedure TSub.privateStuff();
begin
   inherited; // Tut nichts
   WriteLn('TSub.privateStuff()');
end;

procedure TSub.publicSubStuff();
begin
   privateStuff();
   WriteLn('TSub.publicStuff()');
end;

{ TBase }

procedure TBase.privateStuff();
begin
   WriteLn('TBase.privateStuff');
end;

begin
   TSub.Create().publicSubStuff();
   readln;
end.

Das siehst du auch daran dass weder die Methode TBase.privateStuff() noch die Zeile

Code:

inherited; // Tut nichts

im Debugger einen Haltepunkt bekommen.

[ZOD]

oh wie war .. sicher zu früh.

Also - neuer Versuch -:
im Elternformular von private auf protected geändert,
im Kindformular als Klassenmethode oder private eingetragen - das ist falsch.
Genau das will ich ändern. Im Kindformular soll die Methode dann eben
auch protected sein, mit override gekennzeichnet und im Code das inherited stehen.

[Der schöne Günther]

Alles klar, jetzt habe ich es verstanden.

Zitat von ZOD:

Wie finde ich die entsprechenden Stellen im Code?

Mir fällt spontan nur ein die protected Methode in der Basisklasse noch mit virtual zu markieren, dann gibt es eine berechtigte Compiler-Warnung:

Delphi-Quellcode:

type
   TBase = class
      protected procedure stuff(); virtual;
   end;

   TSub = class(TBase)
      private procedure stuff();
   end;

Zitat:

[dcc32 Warnung] Project11.dpr(17): W1010 Methode 'stuff' verbirgt virtuelle Methode vom Basistyp 'TBase'

[ConnorMcLeod]

Schätze, ich würde erstmal mit Menü=>Suchen=>In Dateien suchen=>alle Dateien des Projekts alle Vorkommen finden lassen und mir merken, wo die stehen.
Danach in den Elternklassen die Methoden umbenamsen, kompilieren und beobachten, wo es dann kracht bzw wo es nicht kracht, aber sollte...

[ZOD]

@ConnorMcLeod
klar - der manuelle Ansatz ist möglich. Ich hatte die Hoffnung, hier zumindest einen Teil automatisieren zu können.

@Der schöne Günther
das zusätzliche virtual werde ich ausprobieren. Wie gesagt bekomme ich irgendwie nicht alle Compilermeldungen angezeigt bzw. habe ich nicht genau verstanden, was für die Anzeige nötig ist (Kompilerschalter sind gesetzt).

[Aviator]

Zitat von ZOD:

das zusätzliche virtual werde ich ausprobieren. Wie gesagt bekomme ich irgendwie nicht alle Compilermeldungen angezeigt bzw. habe ich nicht genau verstanden, was für die Anzeige nötig ist (Kompilerschalter sind gesetzt).

Sobald du an einer Unit etwas änderst sollten die entsprechenden Meldungen für diese Unit wieder erscheinen. Die erscheinen nur deshalb nicht mehr weil die nicht mehr compiliert werden. DCUs sind aktuell. Du kannst das aber erzwingen indem du das Projekt bereinigst. In neueren Delphis gibt es da so einen Button im Kontextmenü des Projektes in der Projektverwaltung. Alternativ kannst du die DCUs auch per Hand löschen. Dann müssten die Meldungen wieder kommen.

Aber wie gesagt nur so lange wie du an der Unit etwas änderst. Kompilierst du zwei Mal ohne etwas zu ändern, dann erscheinen die Meldungen nicht mehr. Das ist zumindest meine Erfahrung.

[ZOD]

@Aviator
das hatte ich auch schon mal vermutet. Lösche ich alle DCU Dateien und kompiliere neu, kommen immer noch keine Fehlermeldungen.

@Der schöne Günther
das virtual war bereits drin, das hat nichts geändert -> keine Kompilermeldung.

[Aviator]

Zitat von ZOD:

@Aviator
das hatte ich auch schon mal vermutet. Lösche ich alle DCU Dateien und kompiliere neu, kommen immer noch keine Fehlermeldungen.

Hast du mal versucht alles neu zu erzeugen? Siehe Anhang die beiden Screenshots. Ist allerdings 10.1 Berlin.

[ZOD]

ja - bei D7 geht das über "Projekt|xy.exe erzeugen" oder Umsch-F9.