Aber nicht wenn man folgendes macht:
Code: Alles auswählen
type
TMyClass = class(TSomeClass)
private
// hier werden Methoden deklariert
end;
function BlaBla(ArgList): SomeResult;
implementation
end;
Nun mach das mal in der Klasse mit Strg+Shift+C oder wenn Du das Caret vor die Funktion stellst. Dann kommt mal nix was ein Header, bau ich den hinterher da drüber, dann muß ich das ganze Geschisse von Hand eingeben. Genau das stört. Und ich kriege nicht raus wie der in diesem Fall den Code produziert oder wo die Vorlagen dafür sind.
Es würde ja schon reichen, wenn man dafür die Einstellungen so ändern könnte das sie auf ein eigenes Tool verweisen, das die Arbeit übernimmt. Aber wo finde ich das nun wieder?
Dafür müßte aber ne generalisierte Schnittstelle her, die vom UnitEditor(den habsch ja schon gefunden) mit den Umgebungsparamtern bestückt wird, würde ja schon als String reichen den man parsen kann und das Template entsprechend der Makros ausfüllt.
Die SysUtils ham mer ja, wenn die die gleich Funktionalität wie bei Delphi hat, kann man den Usernamen aus den Systemvariablen holen. Die Codetool-Options müssen lediglich um die Eingabe für den aktuellen Benutzer erweitert werden. Der wird dem SystemUser vorgezogen wenn er da ist. Das wäre dann auch noch schnell gemacht.
Der Witz ist halt, das man in diesen Fällen nur noch Subject und Comment ausfüllt, alles andere ist einfach da und schwupps.
Normal müßte man wohl irgendwo eine Klasse:
Code: Alles auswählen
TCodeToolMakro = class(TObject)
private
FMakro : string;
public
function ProduceTemplate(AParams, ATemplate, AMakro: string): string;
published
property ThisMakro: string read FMakro write FMakro;
end;
Oder so ähnlich. AParams in ProduceTemplate muß dann halt den Unitnamen, Usernamen und den Funktionskopf oder eben den Klassennamen und den Methodenrumpf enthalten. Dann wird das Template geparst und die Makros entsprechend ersetzt. Sind ja nun keine Unmenge.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.
(Ringelnatz)