UnitOptimizer

[jaenicke]

Zitat:

Zitat von stifflersmom (Beitrag 1464867)

Ich träume davon, dass alle Vorkommen einer Suche im Quelltext hervorgehoben werden und dass mann dann auch noch diese Treffer direkt und alle auf einmal verändern kann, ohne dass man extra Suchen&Ersetzen benutzen müsste.

Markieren und Strg + Shift + J (oder den Knopf unterhalb der Markierung drücken) kennst du aber?

[stifflersmom]

Nein, kenne ich tatsächlich nicht.
Bei mir tut sich da aber auch nichts, wenn ich Strg+Shift+J drücke...

[stahli]

@stifflersmom

Im Delphi-Editor kann Du auch einen Block markieren und mit der Maus links unten über einen kleinen Button so einen Änderungsmodus einschalten.
Das ist aber offenbar problematisch, wenn der markierte Block größer als der sichtbare Bereich sein soll (hatte jedenfalls da schon Probleme).


Für mein Tool könnte ich es mir so vorstellen:

Das Markieren von Treffern im originalen Quelltext bekomme ich hoffentlich hin.

Ändern von gefundenen Wörtern kann ich mir aber schwer vorstellen. Vor allem wird es heikel sein, auszuschließen, dass man nicht versehentlich auch nicht gewünschte Stellen versehentlich ändert.

Aber vorstellen könnte ich mir folgendes:

* mit Ctrl-F Schnellsuche starten (wenn man z.B. auf "Kunde" steht wird in der aktuellen Unit "Kunde gesucht und markiert"
* wenn man jetzt Kunde umbenennen möchte ruft man über Ctrl-Shift-F das große Formular auf (das kleine eingebettete verschwindet) - zu sehen sind die gleichen Treffer wie im Code aber gebündelt für den besseren Überblick.
* bei Bedarf könnte man die Suche erweitern oder verkürzen
* jetzt könnte man einen Treffer anklicken und bekommt direkt daneben ein Edit für Eingabe des neuen Textes "Customer"
* mit Enter kann man die Änderung durchführen (auch gleich für unterschiedliche Units), mit ESC abbrechen

Die Funktion Suchen&Ersetzen würde ähnlich funktionieren, würde aber noch ein paar Optionen wie "Rückfragen für jeden Treffer" ermöglichen.

Wäre das ok?

[stifflersmom]

Hallo Stahli,

erst einmal Danke für die Aufklärung mit dem Bearbeiten-Modus für die Suche.
Den habe ich irgendwann mal gesehen und weil der absolut unintuitiv war, gleich wieder vergessen.
Auch ist das markieren mit der Maus über den sichtbaren Bereich hinaus ziemlich unglücklich gelöst.

Im Anhang habe ich, ein als Zip verpacktes Gif angefügt, da kann man erkennen, wie schlank das in Sublime funktioniert.
Das wäre traumhaft, aber wahrscheinlich doch ziemlich tricky zu implementieren.

[jaenicke]

Zitat:

Zitat von stifflersmom (Beitrag 1464876)

Im Anhang habe ich, ein als Zip verpacktes Gif angefügt, da kann man erkennen, wie schlank das in Sublime funktioniert

Genau so funktioniert es in Delphi auch. Das ist da schon seit Ewigkeiten drin (das wurde mit der neuen IDE mit Delphi 2005 eingeführt).

[stifflersmom]

Hab ich mir gerade noch mal vor Augen geführt...
Gerade wegen Deiner angegebenen Tastenkombination Strg+Shift+J

Tatsächlich greift das erst ab einer bestimmten Länge des markierten Textes und darauf bin ich vorhin reingefallen.
Und ja, es geht aber Sublime macht es deutlich besser und übersichtlicher.

Trotzdem danke ich Dir für den Tip.

[jaenicke]

Zitat:

Zitat von stifflersmom (Beitrag 1464880)

Tatsächlich greift das erst ab einer bestimmten Länge des markierten Textes und darauf bin ich vorhin reingefallen.

Um genau zu sein greift es unabhängig von der Länge sobald ein Wort doppelt vorkommt, da es ansonsten schlicht keinen Sinn macht. ;-)
Es geht also auch mit einer Markierung auf

Delphi-Quellcode:

B B

als kürzeste mögliche Variante.

[stahli]

Aktueller Zwischenstand zur Synchronisation der Suchergebnisse und Markierung des aktuellen Wortes unter den Cursor im sichtbaren Feld: https://youtu.be/7hRoQLlKJOE (1 Min)

[stahli]

Hallo zusammen,

hier mal wieder ein neuer Stand: https://youtu.be/C_eTzdV6-fw

Die Suchfunktion finde ich jetzt schon ganz gelungen. :-)
Demnächst will ich mal Tester suchen. Allerdings gibt es dann zunächst nur erst einmal die Suchfunktion und den Installer zu testen.

Ich werde das dann natürlich Stück für Stück weiter ausbauen.
(Teile davon hatte ich schon einmal in zwei Vorprojekten realisiert.)

Im Video zeige ich schon mal, welche Features und Preise mir da so vorschweben.
Sagt mir mal gern, was Ihr davon haltet...
Dass das englisch fragwürdig ist, ist mir aber bereits klar. :cry:

(Wenn sich Tester finden, könnte man einen Austausch vielleicht in einer Discord-Gruppe realisieren...)

[jaenicke]

Die Suchfunktion sieht funktionell schon sehr gut aus. Es gibt ja diverse Grep-Suchen, aber die Integration ist gut gelungen.

Da passiert ja viel live. Was passiert da eigentlich bei einem großen Projekt? Da ist das ja gar nicht in der Form möglich, wenn da tausende Units im Projekt sind, denn da dauert die Suche ja eine Weile. Ist das entsprechend berücksichtigt?

Wenn man nun das große Fenster noch eindocken könnte... Ja, ich weiß, das Thema hatten wir schon, aber nun ist ja die Mini-Version auch eingedockt... ;-) :duck:

[venice2]

Mal eine ketzerische Frage.
Das Teil scheint mir schwer überladen, braucht man so etwas?
Die IDE ist ja eh schon träge und mit dem Teil fast un-bedienbar so wie im Video suggeriert.

Zitat:

Da passiert ja viel live. Was passiert da eigentlich bei einem großen Projekt? Da ist das ja gar nicht in der Form möglich, wenn da tausende Units im Projekt sind, denn da dauert die Suche ja eine Weile

[stahli]

@jaenicke

Das Formular für die Vollsuche ist auch dockbar.
Das Styling passt dann nicht ganz, die Darstellung anders ausfällt als im nicht gedockten Modus. Irgendwie sind da auch die Abständer der Controls anders.
Die Buttons muss ich dann noch etwas anders anordnen (GridPanels passen optisch nicht im Docking-Modus) und meine Slider (basierend auf Frames) passen auch nicht optimal ins Bild.

Man muss den Desktop einmal nach Wunsch einstellen (incl. Position und auch Sichtbarkeit der Formulare) und speichern.


Mit tausenden Units habe ich keine Erfahrungen. Ich habe schon versucht, das zu optimieren.
So wird grundsätzlich erkannt, wenn man etwas in einem Editor ändert und dann nur die Suche dieser Unit aktualisiert.
An ein paar Schrauben muss ich noch drehen, aber grundsätzlich gibt es da schon Unterscheidungen.
Wenn das so noch nicht reicht und keine Lösung zu finden ist, könnte man die Syncronisatzion bei zu vielen Units ggf. auch optional ausschalten.

Da müsste man sich dann halt mal ran tasten.


@venice2

Was findest Du unbedienbar?

Ich merke da keine Einschränkungen (abgesehen, dass es noch unfertig ist).
Es soll dann die normal Suche einfach ersetzen und dann wäre das 1:1 zu benutzen.

Die neue Suche hat sich als notwendig ergeben, weil ich den Code ja komfortabler formatieren möchte.

Statt:

Code:

var
  I: Integer:
  FirstName: String;

soll dann do etwas unterstützt werden:

Code:

var
  I         : Integer:
  FirstName: String;

(Das ist weiter oben schon alles beschrieben.)

Wenn man dann mit der normalen Suche "I: Integer" sucht, findet man das nicht mehr.
Wenn man also so eine Formatierung möchte, braucht man eine angepasste Suche.


Eigentlich wollte ich zunächst nur eine bessere Interface- und Klassenvervollständigung.
In die anderen Themen bin ich dann so reingerutscht... :-)

[stahli]

Also das abweichende Design liegt an den zwei eingesetzten GridPanels und den 2 Frames.

Dann werde ich mal in den sauren Apfel beißen und
- die Buttons in Panels setzen und die Ausrichtung selbst berechnen
- statt den Frames eigene Controls bauen.

(Ein kleiner Test lässt vermuten, dass es dann passen sollte.)

Immer wieder stößt man auf unnötige und unverständliche Probleme... :-(

[stahli]

Ich habe es jetzt hinbekommen.
(Die Inhalte aus den Frames habe ich jetzt einfach direkt auf ein Panel gesetzt und dieses dann über Änderung des Parents verschoben.)

Ist aber schon fragwürdig, dass es solche abweichenden Darstellungen gibt. :-(

[bernau]

Stahli, ich muss dir ein großes Kompliment geben. Es ist schon beeindruckend, was man so machen kann, wenn man sich mit OTA beschäftigt. Hut ab. :thumb:

[stahli]

Nochmal ein neuer Stand: https://youtu.be/927qq5DWZS4

Hat jemand eine Idee, wie eine komplexe Suchen- und Ersetzen-Funktion aussehen könnte?

[stifflersmom]

Erst einmal, oder noch einmal: Respekt für dieses Projekt!

Tatsächlich muss ich aber sagen, dass mich die Komplexität der ganzen Möglichkeiten, die Du jetzt ermöglichst bzw. ermöglichen willst, schon fast erschlägt.

[stahli]

Ja, das kann ich verstehen. Geht mir gerade auch so.
Eine gute Lösung will (muss) ich aber finden...

Ich versuche das mal zusammenzufassen:

Ursprünglich wollte ich nur eine bessere Klassen- und Interfacevervollständigung auf Knopfdruck und eine Sortierung der Units.

Da ich dafür ohnehin die komplette Unit zerlegen und neu zusammenbauen muss, kam ich auf die Idee, auch einen neuen Formatter einzubauen, der einige sinnvolle Optionen anbietet.
Nachher kamen dort noch die virtuellen Tabs hinzu, so dass Code untereinander ausgerichtet werden kann.

Die drei Dinge will ich nun UNBEDINGT!

Dann hat sich herausgestellt, dass die normale Suchfunktion mit unterschiedlichen Einrückungen nicht wirklich klar kommt.

Entsprechend habe ich versucht, da auch eine Lösung zu finden.

Bis hierher (was ich bisher so gezeigt hatte) finde ich das auch praktikabel und deutlich übersichtlicher als die normale Suche. Es gibt die schnellsuche in der aktuellen Unit oder eine Vollsuche in vielen Units.

Die Suchergebnisse werden m.E. besser aufbereitet und der Vorgang der Suche ist etwas angenehmer.
Wenn man ein Wort oder einen einfachen Ausdruck sucht hat man keine Nachteile und etwas hübschere Ergebnisse.

Man kann aber auch komplexere Einstellungen vornehmen - wenn man es halt braucht. Hier erkenne ich auch noch keinen Nachteil.


Wo ich jetzt auch nicht weiter komme ist halt eine komplexere Suche (mit Einstellungen pro Suchwort) und das vor allem das Suchen&Ersetzen.

Die Möglichkeit, für jedes Suchwort individuell Sucheinstellungen vorzugeben, ist sicherlich idR verzichtbar. Andererseits braucht man ja keine individuellen Einstellungen pro Wort vornehmen, wenn man es nicht braucht.

Das Suchen&Ersetzen muss ich aber schon irgendwie ermöglichen, wenn ich die originalen Suchen-Formulare ersetzen will...


Da ich Klassenvervollständigung, Unitsortierung und Formatierung mit virtuellen Tabs UNBEDINGT will, muss ich eine gute Lösung für das Suchen bzw. Ersetzen finden.

Mein ursprüngliches Anliegen war das nicht, aber jetzt ergibt sich doch die Notwendigkeit und ein Großteil funktioniert ja auch schon ganz gut.

[stahli]

Hallo zusammen,

ich bin jetzt auf dem Weg, das Tool real einzusetzen und stoße nach und nach noch auf einige Dinge, die ich noch anpassen muss oder sollte.
Insgesamt läuft es aber schon ganz gut und vor allem stabil! :-)

Ich will Euch mal fragen, wie Ihr die Formatierung der Case-Anweisung sehen würdet bzw. welche Optionen Ihr dazu für wünschenswert haltet.
In der Beziehung bin ich selbst nicht ganz schlüssig.
Vor allem weiß ich natürlich auch nicht, welche Formatierungen (Einrückungen, mit oder ohne Umbrüche) da so im Umlauf sind und auf welche "Überraschungen" sich das Tool einstellen muss. ;-)

Ein paar Rückmeldungen und Vorschläge würden mir sehr helfen...

Video: https://youtu.be/Q2All1u5T0M (10 Min)

[ConnorMcLeod]

Zitat:

Zitat von stahli (Beitrag 1476227)

Ich will Euch mal fragen, wie Ihr die Formatierung der Case-Anweisung sehen würdet bzw. welche Optionen Ihr dazu für wünschenswert haltet.
In der Beziehung bin ich selbst nicht ganz schlüssig.

Servus und Gratulation zu diesem schönen Projekt!

In meiner Erfahrung hat es sich als vorteilhaft gezeigt, wenn bei den Schleifen und Verzweigungen _immer_ begin und end dazugeschrieben werden. So kann man sich blind darauf verlassen.

Daher mein case-Vorschlag :

Delphi-Quellcode:

case Bedingung of
  1:
    begin
      Tuwas;
    end;
  2:
    begin
      Abwarten;
    end;
  else
    begin
      MachNix;
    end;
end;

[dummzeuch]

Meine Bevorzugte Einrückung:

Delphi-Quellcode:

case bla of
  0: begin
    doSomething;
  end;
  1: begin
    doSomethingElse;
  end;
else
  DefaultCode;
end;

Auch ich verwende meist begin/end, auch wenn es nicht unbedingt notwendig ist.

Wenn ich mir eine Syntax wünschen dürfte, wäre sie:

Delphi-Quellcode:

case bla of
  0:
    doSomething;
  end;
  1:
    doSomethingElse;
  end;
else
  DefaultCode;
end;

Also ohne begin, aber das geht ja leider nicht.

[venice2]

Zitat:

Also ohne begin, aber das geht ja leider nicht.

Nein?
Klar geht das solange man nur eine Funktion -> Aufruf im case verwendet.
Dein End hat da nichts zu suchen.

Delphi-Quellcode:

case bla of
  0:
    doSomething;
  1:
    doSomethingElse;
else
  DefaultCode;
end;

[Uwe Raabe]

Für den Else-Zweig funktioniert das aber jetzt schon. Da wäre ein zusätzliches begin-end überflüssig:

Delphi-Quellcode:

  case Bedingung of
    1: begin
        Tuwas;
      end;
    2: begin
        Abwarten;
      end;
  else
    MachNix;
    MichWasAnderes;
  end;

Siehe: http://docwiki.embarcadero.com/RADSt...se-Anweisungen

Zitat:

Jeder in einer caseList angegebene Wert muss innerhalb der case-Anweisung eindeutig sein. Teilbereiche und Listen dürfen sich nicht überschneiden. Eine case-Anweisung kann über eine abschließende else-Klausel verfügen:

Delphi-Quellcode:

 case selectorExpression of
   caseList1: statement1;
    ...
   caselistn: statementn;
 else
   statements;
 end

statements ist eine Folge von Anweisungen, die durch Strichpunkte voneinander getrennt sind. Bei der Ausführung einer case-Anweisung wird höchstens eine statement1 ...statementn-Anweisung ausgeführt. Dabei handelt es sich um genau diejenige, deren caseList-Wert mit dem von selectorExpression identisch ist. Ist kein entsprechender selectorExpression-Wert in caseList vorhanden, werden die Anweisungen in der else-Klausel (falls vorhanden) ausgeführt.

[dummzeuch]

Zitat:

Zitat von venice2 (Beitrag 1476251)

Zitat:

Also ohne begin, aber das geht ja leider nicht.

Nein?
Klar geht das solange man nur eine Funktion -> Aufruf im case verwendet.
Dein End hat da nichts zu suchen.

Delphi-Quellcode:

case bla of
  0:
    doSomething;
  1:
    doSomethingElse;
else
  DefaultCode;
end;

Tja, genau das ist das Problem: Ich will ein End, aber eigentlich kein Begin.

[Uwe Raabe]

Theoretisch wäre auch das

Delphi-Quellcode:

end

nicht notwendig, da die Befehlssequenz entweder durch ein neues case-Label, das

Delphi-Quellcode:

else

oder ein

Delphi-Quellcode:

end

beendet wird. Aber das ist nun mal schon vor langer Zeit eben so festgelegt worden...

[venice2]

Zitat:

Tja, genau das ist das Problem: Ich will ein End, aber eigentlich kein Begin.

Ok!
Nur der sinn dahinter erschließt sich mir nicht.

Zitat:

Theoretisch wäre auch das end nicht notwendig

Nun. Er hätte es gern :)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1476227)

Ich will Euch mal fragen, wie Ihr die Formatierung der Case-Anweisung sehen würdet bzw. welche Optionen Ihr dazu für wünschenswert haltet.
In der Beziehung bin ich selbst nicht ganz schlüssig.

Ich finde die Schreibweise aus dem Styleguide am übersichtlichsten (wobei ich die erste wegen 1 Befehl pro Zeile suboptimal finde und die Leerzeilen aus der zweiten überflüssig und daher die letzte präferiere):

Zitat:

Delphi-Quellcode:

  // CORRECT
  case Control.Align of
    alLeft, alNone: NewRange := Max(NewRange, Position);
    alRight: Inc(AlignMargin, Control.Width);
  end;
  

  // CORRECT
  case x of

    csStart:
      begin
        j := UpdateValue;
      end;

    csBegin: x := j;

    csTimeOut:
      begin
        j := x;
        x := UpdateValue;
      end;
      
  end;
      
  // CORRECT
  case ScrollCode of
    SB_LINEUP, SB_LINEDOWN:
      begin
        Incr := FIncrement div FLineDiv;
        FinalIncr := FIncrement mod FLineDiv;
        Count := FLineDiv;
      end;
    SB_PAGEUP, SB_PAGEDOWN:
      begin
        Incr := FPageIncrement;
        FinalIncr := Incr mod FPageDiv;
        Incr := Incr div FPageDiv;
        Count := FPageDiv;
      end;
  else
    Count := 0;
    Incr := 0;
    FinalIncr := 0;
  end;

Zitat:

Zitat von stahli (Beitrag 1476227)

Vor allem weiß ich natürlich auch nicht, welche Formatierungen (Einrückungen, mit oder ohne Umbrüche) da so im Umlauf sind und auf welche "Überraschungen" sich das Tool einstellen muss. ;-)

Das sollte dem Parser ja egal sein wie es vorher war.

[himitsu]

Zeilenumbrüche, Leerzeichen und Tabs sind erstmal vollkommen egal. (eigentlich sogar alles von #1 bis ' ')
Einzige Ausnahme ist der Zeilenumbruch hinter //-Kommentaren.
Ein ; vor einem END wäre auch "optional", sowie doppelte ;; ... aber ich empfehle immer ; zu schreiben (außer vor einem ELSE bzw. nach einem THEN/DO)

Das ist ja auch der Grund, warum ein Code-Formatierer alles umformatieren und nach "belieben" Zeilenumbrüche und Einrückungen einfügen/entfernen/ändern kann. :zwinker:
(nicht so wie bei Python, wo die Einrückung essenziell ist und mit zum Programm-Code gehört)

[stahli]

Danke an Euch alle.
Das hilft mir schon mal weiter.

@jaenicke
Ich habe das Beispiel gleich mal durchlaufen lassen.
Also die Standardfälle passen schon ganz gut. Nur der gesamte Else-Block wird noch nicht korrekt eingerückt. Das werde ich aber heute noch lösen können.
Das ist eben auch wieder so ein spachlicher Sonderfall. Else zum if ist etwas anders zu händeln als else zum case.
Ich konvertiere die Schlüsselwörter in Klassen mit bestimmten Eigenschaften. Bei Else im Kontext von Case werde ich wohl nur die Eigenschaft für die Einrückungsvorgaben ändern müssen.
Schaue ich mir heute Abend an.

Zitat:

Zitat von jaenicke (Beitrag 1476260)

Zitat:

Zitat von stahli (Beitrag 1476227)

Vor allem weiß ich natürlich auch nicht, welche Formatierungen (Einrückungen, mit oder ohne Umbrüche) da so im Umlauf sind und auf welche "Überraschungen" sich das Tool einstellen muss. ;-)

Das sollte dem Parser ja egal sein wie es vorher war.

Hier meinte ich eher die Wünsche und Anforderungen, welche Varianten unterstützt werden müssen.
Hier muss ich immer abwägen, was beibehalten werden muss und was einfach "korrigiert" werden kann.

Z.B. Kann ein Zeilenumbruch innerhalb der Parameter einer Prozedur ausdrücklich gewünscht sein oder es kann sinnvoll sein, einen solchen automatisch zu entfernen, um die Parameter in einer Zeile zu haben. Solche Fragen stellen sich viele.
Deswegen maskiert der Optimizer weiche (automatische) Umbrüche mit einem ESCAPE (das Kästchen am rechten Rand). So weiß er, dass dieser Umbruch auf jeden Fall entfernt werden kann.

Je nach Entscheidung können in beiden Fällen (Umbruch belassen oder entfernen) potenzielle Nutzer das Tool genau deswegen ablehnen.
Ich werde also viele Optionen anbieten müssen, allerdings wären weniger Optionen grundsätzlich natürlich wünschenswert.

[stahli]

... also das mit dem Einrücken funktioniert wie erwartet :-)


Wer mal einen kleinen Einblick möchte:

Delphi-Quellcode:

                if SupportsIn(lItemBlockStart, [IDetectThen, IDetectElse, IDetectDo]) then
                  begin
                    if Supports(lItemBlockStart, IDetectElse, lDetectElse) then
                      lDetectCaseFlag := Supports(lDetectElse.ItemBlockStartLink, IDetectCase)
                    else
                      lDetectCaseFlag := False;
                    if (lDetectCaseFlag) then
                      currentRealAlign.LeftSpaceNext := currentRealAlign.LeftSpaceNext + 1 // Sonderfall Else zum Case  --> NEU <--
                    else
                      if (not lDetectExceptFlag) then
                        currentRealAlign.IncLeftSpaceMove; // sonst nach then/else/do eine Zeile/Anweisung einrücken (wenn Zeilenende)
                  end;

Zu den Format-Sonderfällen ist jetzt ein neuer Sonderfall hinzu gekommen. ;-)
Ich versuche das halt alles durch zugewiesene Eigenschaften zu deklarieren, die der Formatierer dann entsprechend umsetzt.
Da spielen dann noch die ganzen Verschachtelungen und Blöcke hinein.

[stahli]

Nochmal 4 Varianten von if-then-else...
Mal ist einrücken der nächsten Zeile sinnvoll und mal nicht.

Der Algorithmus sollte jetzt m.E. alle gängigen Formatierungsvarianten vernünftig optimieren.

[stahli]

Nur mal ein kleiner Zwischenstand für die reale Arbeit mit der aktuellen Suchfunktion: https://youtu.be/A1fURA7KFDk (2 Min)

Geht schon ganz gut aber ich muss das noch weiter ausbauen und optimieren.

[ConstantGardener]

Respekt! Das sieht schon sehr gut aus!:thumb:

[stifflersmom]

Sehr vielversprechend!

Ich hoffe, ich kann das bald selbst mal ausprobieren.

[stahli]

Danke Euch! :-)
Ich denke, im Dezember kann ich mal eine Testversion anbieten (incl. Installer usw.)


Zuvor will ich noch zwei Punkte ausbauen.

1) das Dockingprinzip
Die Suchformulare verhalten sich im Zusammenspiel mit der IDE etwas anders, je nachdem ob sie eingedockt sind oder nicht.
Vielleicht können ja diejenigen, die es demnächst mal testen möchten schon mal mitteilen, welche Auflösungen Ihr nutzt (wie ist die IDE ausgerichtet, gibt es mehrere Monitore?).
Würdet Ihr das Vollsuchformulare eher eindocken (nimmt halt dann recht viel Platz ein) oder das lieber über die IDE setzen (wie im Video zu sehen).
Oder doch auf einen zweiten Monitor?
Diesbezüglich habe ich noch keine optimale Lösung gefunden.

2) der Optimizer
Hier muss ich noch ein Problem klären, wenn die begin-end-Schachtelungen nicht aufgehen.
Dadurch, dass alle Methoden komplett aus der Unit entfernt und umsortiert neu eingesetzt werden, kann das noch zu Problemen führen.
Das muss ich natürlich noch erkennen und dann auf eine Umsortierung verzichten. Sonst wird die Unit "zerschossen", weil nicht mehr alles aufgeht.
An diesenigen, die das demnächst mal testen wollen: Würdet Ihr dann eine Umsortierung der Methoden überhaupt wollen?
In Interfaces und Klassen werden die Methoden nach Sektionen geordnet und dann innerhalb dieser nach Member (Funktionen/Prozeduren/Properties) sortiert und dann nochmal alphabetisch.
Die Methoden im Implementationsteil werden dann analog der Deklarationsreihenfolge sortiert.
Grundsätzlich finde ich das unbedingt sinnvoll, ist halt nur die Frage, ob man das für erste Tests gleich will. Wobei es natürlich funktionell auch keinerlei Nachteile hat, selbst wenn man es erst mal so nicht gewöhnt ist. Wer seinen Code in ein Versionssystem eincheckt würde damit jedoch wohl ein Problem haben.
Ich könnte natürlich auch den originalen Formatierer auf Ctrl-D lassen, so dass man standardmäßig weiter den nutzen kann.


Das wären jetzt noch meine Vorab-Überlegungen vor einer Testversion.

Für den Austausch würde ich mir dann einen Server auf Discord vorstellen...
(Ich habe schon einen angelegt, aber noch keine Erfahrungen damit. Hier mal der Link: https://discord.gg/5xHfSpvg Keine Ahnung, ob das so reicht.)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1477731)

Vielleicht können ja diejenigen, die es demnächst mal testen möchten schon mal mitteilen, welche Auflösungen Ihr nutzt (wie ist die IDE ausgerichtet, gibt es mehrere Monitore?).

Full-HD und 4K.

Zitat:

Zitat von stahli (Beitrag 1477731)

Würdet Ihr das Vollsuchformulare eher eindocken (nimmt halt dann recht viel Platz ein) oder das lieber über die IDE setzen (wie im Video zu sehen).

Wenn man es eindocken kann, kann man es auch auf automatisch einklappen stellen oder loslösen. Diese Möglichkeiten sollten dann doch für alle Zwecke passen...

[ConstantGardener]

34 Zoll, 3440 x 1440 Pixel, leider nur ein Monitor :) Suchfenster eingedockt fände ich wahrscheinlich am besten.

[ConnorMcLeod]

Hi, ich bin dabei ;-) Ich arbeite mit zwei bis drei Monitoren mit 1920x1200. Als eigenständiges Fenster wäre es super praktisch.
Gruß aus dem Inntal!

[stifflersmom]

- 5K, allerdings dann nicht den ganzen Bildschirm

- die Suchergebnisse angedockt, das Eingabefenster kann ruhig im Vordergrund "aufploppen"

[stahli]

Die Schnellsuche enthält nur Eingabefelder, keine Suchergebnisse.
Die Komplexsuche enthält beides in einem Formular. Das würde ich auch erst mal so belassen wollen. Eine Trennung vielleicht mal irgendwann später, wenn es dann sinnvoll erscheint...