Borland - Endlich wissen wo Funktionen landen werden...

[LoewenZahn]

Grüße ihr Veteranen,

ich programmiere des öfteren im Borland Studio 2006, dort erstelle ich fröhlich meine Zeilen und somit auch mal eine function oder procedure. Soweit so gut, doch landet das Grundgerüst meist an unpassenden Stellen!

Beispiel: Ich doppelklicke einen Button im Designer an und lande somit automatisch im (noch leeren) Quellcode der procedure TButton1.OnClick. Dieses Gerüst ist aber weder am Ende noch am Anfang, sondern irgendwo zwischen allen anderen zu finden, was, wenn man diese sortiert und kommentiert an absolut falscher Stelle sein kann.

Ich schreibe hier nun nicht "nur" um meinen Frust los zu werden, sondern auch in Hoffnung das es eventuell doch ein System oder eine Einstellungsmöglichkeit hinter dem Ganzen gibt.

Freue mich über jegliche positive Meldung.
PS: Thx für Titelkorrektur

Gruß

[jaenicke]

Das ist as-designed. Die Forderung, dass man das mal konfigurieren kann, ist bei Embarcadero durchaus angekommen, mehrfach, aber bisher nicht umgesetzt worden. Im Moment wird es alphabetisch gemacht, was aber nicht immer richtig geht, wenn man selbst schon Methoden manuell dazwischengestreut hat. Solange man die alle automatisch erstellen lässt, sollte es auch alphabetisch sein.

Nichtsdestotrotz ist die Reihenfolge auch egal. Wenn man damit Probleme hat, sollte man prüfen, ob man in der Unit zu viel Funktionalität hat. Und mit Tools wie dem CnPack kann man auch mit einer Such-Combobox oben über dem Editor komfortabel zu einer bestimmten Methode springen. Mit Strg + Shift + Pfeil hoch/runter kann man ja schon von Hause aus zwischen Implementierung und Interface springen.

[Perlsau]

Mir widerfährt es unregelmäßig, aber doch hin&wieder in RadStudio2009Delphi, daß ein Procedure-Rumpf hinter dem end. landet und die IDE daraufhin die Meldung herausgibt: Methode nicht gefunden. Gelegentlich werden Methodenrümpfe auch innerhalb einer bereits bestehender Methoden platziert oder innerhalb eines Kommentars, das ist dann besonders ärgerlich, weil man nicht so einfach erkennen kann, wo denn der erzeugte Methodenrumpf abgeblieben ist. Kürzlich sah das so aus:

Delphi-Quellcode:

proprocedure TForm1.Anzeigen;
begin
end;cedure TForm1.FormShow(Sender: TObject);
begin
   Pfad := ExtractFilePath(ParamStr(0));
   Anzeigen;
end;

Das ist dann ganz besonders ärgerlich. Mir hilft dann am schnellsten ein Compilierversuch, der den Cursor an die Stelle bringt, wo ein automatisch erzeugter Methodenrumpf den Fehler ausgelöst hat.

Ich würde mir wünschen, daß Methodenrümpfe immer am Ende der letzen Methode direkt vor dem end. platziert werden, dann müßte man nicht lange suchen und wäre mit einem Ctrl-Ende auch schnell dort – und es wäre wohl ein Clacks für Emba, das zu realisieren. Wenn mir jemand zeigt, wie ich das selber umsetzen kann, würde ich mich sogar daranwagen.

Aber dennoch finde ich, mit dieser kleinen Unbequemlichkeit kann man durchaus leben, es gibt Schlimmeres.

[jaenicke]

Seit XE hatte ich das kein einziges Mal mehr, so etwas hatte ich nur mal in Delphi 2006.

Was allerdings leider auch in XE4 noch passiert ist (in XE5 bisher nicht, aber die Hoffnung stirbt zuletzt... ):
Wenn eine neue Unit in das Projekt aufgenommen wurde, wurde zuweilen die uses-Liste komplett zerstört. Lässt sich zwar schnell reparieren, ist aber dennoch sehr ärgerlich. Insbesondere weil der Parser, der dort für das Einbringen von Änderungen benutzt wird, sogar noch schlechter zu sein scheint als mein eigener, den ich "mal eben schnell" für ein wenig Refactoring gebastelt hatte...
Der macht solche Anpassungen korrekt und misshandelt auch den restlichen Code nicht so wie Delphi in der Projektdatei...

[Mikkey]

Du kannst den Designer dazu zwingen, die von ihm generierten Funktionen an einer bestimmten Stelle zu sammeln:

Plaziere Deinen gesamten Code innerhalb eines {$IFDEF abc}. Der Designer packte die Funktionen dann nicht in diesen Bereich. 'abc' muss natürlich definiert sein.

[Union]

Bei mir hat ifdef in der dpr leider genau den gegenteiligen Effekt. Es werden dann uses plötzlich 10x dupliziert und an beliebige Zeilen angehangen.

[jaenicke]

In der .dpr meinte er das auch nicht, da ist der Parser wie ich ja auch geschrieben hatte leider kaputt (aber das ist ja "as-designed", das muss so), aber in einer Formularunit funktioniert das schon so.

// EDIT:
Und grad wo ich es geschrieben habe...
Neues Projekt in XE5, einfach ne Unit hinzugefügt, Ergebnis in der .dpr...

Delphi-Quellcode:

ususes
  System.SysUtils,
  System.Classes,
  Unit1 in 'Unit1.pas';

R *.res}

Aber das muss ja so...

// EDIT2:
Ok, der Fall ist reproduzierbar...
http://qc.embarcadero.com/wc/qcmain.aspx?d=119689