Unter welchen Bedingungen wird ein System-Unit Fix kompiliert und eingebunden ?

[Rollo62]

Zitat von jziersch:

Ich weiß jetzt nicht ob dies Dein Problem löst, ich habe aber für ein ähnliches Problem einen Unit-Alias auf eine umbenannte Unit mit Erfolg eingesetzt. Dies hilft auch bei der Unit FireDAC.VCLUI.Wait welche die IDE auch zu einem FMX Projekt standhaft hinzufügt.

Dankesehr für den Vorschlag, habe auch das hier von Thomas dazu gefunden.
Sowas wie "Unit-Alias" hatte ich bisher noch gar nicht auf dem Schirm, interessant.

Mit geht es insbesondere um die falsch zugeordneten Breakpoints, die mal auftreten können.
Wenn die beim Debuggen der System-Units auftreten könnte ich das ja noch verstehen,
aber beim Debuggen der gefixten Units, die ja definitiv neu kompiliert und eingebunden habe,
sollte das doch nicht passieren.
Das Seltsame ist ja das dies mal auftreten sein kann, und dann auch mal wieder weg ist.
Bisher hat es mit einen kompletten Clean des Projektes (Batch-Datei die alle Leichen entfernt, sogar die Verzerichnisse) immer geholfen.
Das trat auch immer nur selten auf, und ich konnte mir das durch Fehler im Build-Vorgang erklären.
Diesmal ist es aber hartnäckiger.
Deshalb Suche ich gerade nach den Ursachen und Möglichkeiten wie man das zweifelsfrei weg bekommt.

Ich habe als Ursache noch meine Design-Komponenten im Verdacht, die ich womöglich nochmal neu builden müsste.
Diese haben allerdings gar nichts mit FMX.ListView zu tun, aber das Problem der Verschiebung der Breakpoints könnte sich dadurch ja trotzdem darüber erklären lassen.
Das wäre meiner Meinung nach die einzige Stelle bei mir wo sowas herrühren könnte, weil ich
ansonsten Alles aus Sourcen neu kompiliere.

Das der Fehler aus den Rx10.4 Orginal-Units/statischen Libraries kommt glaube ich eher nicht,
könnte aber natürlich auch der Fall sein.
Deshalb die Frage wie man sowas exakt herausfinden könnte (Compiler/Linker geben bei mir ja keine Warnung).

Bin aber erst noch anderweitig beschäftigt, muss ich ein bischen später checken.

[Rollo62]

Ich denke Schuld and den verschobenen Breakpoints war die Design-Komponente,
welche eine gemeinsame Unit mit hauptsächlich globale Konstanten eingebunden hat.
Die Konstanten hatte ich mal ergänzt und umgebaut, aber vergessen den Design-Unit mit upzudaten.

Ich habe diese Unit jetzt neu gebuildet und installiert, die Breakpoints stimmen wieder.
Alle Fixes liegen jetzt wie bisher in der DPR, und im Verzeichnis neben der DPR.

Delphi-Quellcode:

Uses
  ...
  , FMX.ListView in '_FmxFixes\FMX.ListView.pas'
  ...
  ;

Das funktioniert soweit, so hatte ich es auch bisher.


Zum Thema Aufräumen der Units aus der DPR bin ich aber noch nicht ganz am Ziel.
Ich möchte die DPR möglichst sauber halten, aber das Zusammenfassen aller Fixes in einer Unit
z.B. FmxFixes.pas

Delphi-Quellcode:

//DPR
Uses
  ...
  , FmxFixes in '_FmxFixes\FmxFixes.pas' //<== Da kann man es genau spezifizieren
  ...
  ;

//FmxFixes.pas

Uses
  ...
  , FMX.ListView  //<== hier nicht mehr, die gefixten Units MÜSSEN wohl neben der DPR liegen
  ...
  ;

A. Das kompiliert eben leider nicht.
Wenn an anderer Stelle FMX.ListView benutzt wird, dann nimmt er das orginale System-Unit.

Ich möchte aber gerade den ganzen Müll aus der DPR entfernen, und möglichst zentral einbinden,
z.B. über FmxFixes.pas, FmxFixes.inc, o.ä.


B. Abhilfe schafft, wenn ich im Search Library als ersten Suchpfad die _FmxFixes mit angebe,
dann wird im Unterverzeichnis _FmxFixes zuerst gesucht:
  _FmxFixes\ Vergesse ich das Unterverzeichnis kompiliert es u.U. auch, aber keiner merkt es.

Kompilieren, Linken Ausführen funktioniert.

Wenn ich jetzt aber in irgendeiner anderen Unit die auch FMX.ListView benutzt (oder auch in der FmxFixes.pas selbst),
dieses File öffne (mit Ctrl-Enter oder Context-Open File at Cursor),
dann wird NICHT das gefixte, sondern das Orginal-Unit geöffnet.
Im Editor können auch mal beide FMX.ListView.pas Units geöffnet sein, was mich extrem nervt,
denn das Öffnen per IDE zeigt in der Regel immer das Falsche an.

Genauso hatte ich es damals auch mal beim Debuggen festgestelt, weshalb ich die Lösung oben mit allen Fixes neben der DPR direkt in die DPR eingebunden einsetze.
Es war für mich kein Verlass darauf von wo die IDE sich gerade die Units holt, selbst wenn das der Compiler/Linker womöglich richtig macht.
Die Gefahr in der IDE das Falsche File zu Editieren ist sehr hoch.

C. Fixes im Unterverzeichnis, aber direkt in die DPR einbinden:
Wenn ich jetzt die Fixes in den Unterveerzeichnissen angebe scheint es zu funktionieren, auch in der IDE (dankesehr nochmal an Phillip), ich werde das mal weiter beobachten.
Ich meine es gab da auch vertauschte Units beim Debuggen.
Meine Lieblingslösung wäre das aber noch nicht, weil die DPR zig Fixes enthalten muss.

Deshalb hatte ich es vor Jahren schonmal aufgegeben, ich fürchte fast ich muss den ganzen Fixes-Müll in der DPR behalten.

Es ist wirklich zu blöd das Delphi keine Verzeichnisse im Unit-Namen unterstützt, nur in der DPR.

[Delphi.Narium]

Ja, Du musst die Fixes in der DPR behalten.

Aber:

Man kann das ja auch einfach mal alles in 'ne Alle_Meine_Fixes.inc packen und dann nur die in die DPR stecken.

Die DPR wird so "nur eine Zeile länger als normal" und die Includedatei kann man in allen Projekten nutzen. Muss dann für die eigenen Fixes nur eine Stelle pflegen und vergisst dann nicht mal in 'nem Projekt das eine oder andere nachzutragen, zu entfernen, ... derweil: Steht ja alles in einer Includedatei für alle Projekte.

Man müsste mal prüfen, ob die IDE damit auch zurechtkommt und Strg+Enter immer zur richtigen Datei (hier also der in der Includedatei aufgeführten) geht.

Nur mal so als Idee zum Probieren, eventuell bringt es Dich ja ein Stückerl weiter.

[Rollo62]

Ja so was wäre schon besser sortiert.
Zumindest bleibt die DPR dann maximal sauber, und die .Inc Datei könnte die passenden Fixer mit IFDEF selektieren.

Besser wird es wohl nicht gehen.

[Rollo62]

Hallo Delphi.Narium,

ich habe es gerade nochmal gecheckt.
Auch das scheint nicht zuverlässig zu funktionieren.
Wenn ich das Projekt aufräume, und nur alle Uses im Include ergänze

Delphi-Quellcode:

program TTest;

{$R *.dres}

uses
  System.StartUpCopy,
  FMX.Forms,
  UMain_Frm in 'UMain_Frm.pas' {Form_Main},
  UMain_Modules in 'UMain_Modules.pas',
  UMain_Pages in 'UMain_Pages.pas',
{$I '_FmxFixes\_FmxFixes.inc'}    //<== hier sind ale Fixes zusammengefasst drin
  ;

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm_Main, Form_Main);
  Application.Run;
end.


// Mit _FmxFixes.inc
  , FMX.ListView.iOS in '_FmxFixes\FMX.ListView.iOS.pas'
  , FMX.ListView in '_FmxFixes\FMX.ListView.pas'
  , System.iOS.Sensors in '_FmxFixes\System.iOS.Sensors.pas'

oder auch wenn die Units selber direkt mit eingebunden werden

Delphi-Quellcode:

program TTest;

{$R *.dres}

uses
  System.StartUpCopy,
  FMX.Forms,
  UMain_Frm in 'UMain_Frm.pas' {Form_Main},
  UMain_Modules in 'UMain_Modules.pas',
  UMain_Pages in 'UMain_Pages.pas',
  FMX.ListView.iOS in '_FmxFixes\FMX.ListView.iOS.pas',
  FMX.ListView in '_FmxFixes\FMX.ListView.pas',
  System.iOS.Sensors in '_FmxFixes\System.iOS.Sensors.pas',
  ;

{Main_Styles_Form}

{$R *.res}

begin
  Application.Initialize;
...

Es kompiliert und läuft Beides.

Problem:
In beiden Fällen kann ich in irgendeiner Unit die FMX.ListView benutzt dieses File öffnen,
aber es öffnet sich immer die orginale Unit in der IDE, nicht der Fix.

Die einzig zuverlässige Lösung ist und bleibt anscheinend:
- gefixte Units müssen im gleichen Verzeichnis der .DPR /.DPROJ liegen
- alle gefixten Units müssen direkt in das Projekt, in die .DPR eingebunden werden

Nur dann scheinen Compiler/Linker UND IDE/Debugger immer die richtige Unit zu benutzen.

Mal abgesehen davon, das ein Einbinden von Includes das Einfügen von Files im Designer durcheinanderbringt, und regelmäßig die .DPR STruktur zerstört.
Was aber das kleinere Problem wäre.

Ok, ich gebe mal wieder auf, wie schon zuvor, und lasse den Müll eben in der .DPR und im Verzeichnis.
Die Hoffnung stirbt zuletzt.

[Delphi.Narium]

Ehrlichgesagt verstehe ich nicht, wieso Units, die in ein Projekt aufgenommen werden und dadurch in der DPR stehen, Müll sein sollen.

Delphi ist nunmal so konstruiert, dass das das delphikonforme Vorgehen darstellt. Was ist da so schlimm dran?

Habe bei mir seit ca. 25 Jahren die ins Projekt aufgenommenen Units in der DPR stehen. Habe damit nie Probelme gehabt. Und da ich in der DPR sowieso nur sehr selten eigenen Quelltext einfügen muss oder dort irgendwas programmatisch lösen muss, sehe ich nur sehr selten in die DPR.

Eigentlich ist die DPR der Quellcodeteil eines Projektes, mit dem ich am wenigsten zu tuen habe. Warum soll es da schlimm sein, wenn im Uses halt eben mal viele Zeilen stehen. Quellcode finde ich hinter dem ersten begin. Das ggfls. per Strg+S zu suchen ist auch nicht soviel Aufwand.

Achso: Bisher ist die Erfahrung mit vielen in die DPR aufgenommenen Units dergestalt, dass das Kompilieren schneller geht, da der Kompiler nicht erst in einer mehr oder weniger langen Pfadliste nach was passendem suchen muss. Er bekommt genau gesagt, was er gefälligst zu nehmen hat. Konflikte mit gleichnamigen Units in unterschiedlichen Verzeichnissen, die dann auch mal verwechselt werden können, gibt es so auch nicht.

Warum mit sehr viel Aufwand eine nicht den Delphi-/IDE-Vorgaben entsprechende Lösung suchen, wenn es eine seit 25 Jahren funktionierende, den Delphi-/IDE-Vorgaben entsprechende Lösung, gibt?

Naja: Wenn die IDE die falsche Datei öffnet, liegt es vermutlich daran, dass sie zuerst bei den "eigenen" Sourcen sucht und erst dann bei den in der DPR eingebundenen. Ist das ein Bug oder ein Feature? Kann man das eventuell mal beim Hersteller als feature request "einreichen"?

[Rollo62]

Zitat von Delphi.Narium:

Ehrlichgesagt verstehe ich nicht, wieso Units, die in ein Projekt aufgenommen werden und dadurch in der DPR stehen, Müll sein sollen.

Ganz einfach, da habe ich mehrere Gründe:

1. Weil das Verwalten der Fixes für mich unnützer Ballast ist.
Den bearbeite ich normalerweise nur einmal (pro Version), im Idealfall,
und will den dann komplett vergessen.
So muss ich aber in jedem Projekt, und bei jedem Update (wo ich .DPROJ neu anlegen muss,
diesen ganzen Kram wieder händisch anfassen.
Gut, die manuelle Kontrolle hat auch ihre Vorteile, aber das Copy-Paste bringt mehr Nachteile.

2. Mit "Müll" meine ich das in der .DPR ohne Fixes stehen bei mir ca. 4-5 Units pro Projekt.
Je nachdem welche Features ich nutze bekommen ich aber 5-20 Fixes-"Müll" mit da rein.
Das gleiche gilt für das Hauptverzeichnis der Projekte.
Weil ich die Fixes anscheinend nur da reinkopieren kann, damit Compiler/Linker/IDE/Debugger damit klarkommen, kommt auch dort ungewünschter "Müll" rein.
Sonste hätte ich dort ca. 10 Files pro Projekt.
Erschwerend kommt da hinzu das ich viele Mobile-Projekte habe, und dort oft .DPROJ neu anlegen muss,
damit neue Features übernommen werden.
Früher reichte eine .DPROJ bei mir auch mehrere Jahre, unter Windows, die Zeiten sind vorbei.

3. Ich benutze gerne immer gleiche, funktionierende Konfigurationen, wo die Fixes eben gut
aufeinander abgestimmt sind.
Durch den "Müll" im Projekt ist es aber kaum wartbar.
Ich mache es im Moment so das ich die benötigten Fixes ausserhalb manage, und dann den Projekten nur die funktionierenden Kombinationen einspiele.


4. Weil ich gerne die ganzen Features und Fixes global steuern und konfigurieren möchte.
Also in der Art:
Projekt braucht FMX.ListView, Projekt braucht MapView, etc. dann nur die nötigen Fixes reinbauen.
Falls eben möglich benutze ich dafür solche Defines, um Features einfach und gut verständlich ein/ausschalten kann:

Delphi-Quellcode:

{$DEFINE _X_HAS_FEATURE_NOTIFICATION_LOCAL }
{$DEFINE ___HAS_FEATURE_NOTIFICATION_REMOTE }
{$DEFINE _X_HAS_FEATURE_TTS_SPEAK}
{$DEFINE _X_HAS_FEATURE_MEDIA_AUDIO_PLAY }
{$DEFINE ___HAS_FEATURE_MEDIA_AUDIO_RECORD }
{$DEFINE ___HAS_FEATURE_WIFI }
{$DEFINE ___HAS_FEATURE_WIFI_NETWORK_INFO }  // Allow the retrieval see S4.Core.Net.Ssid.iOS

Dadurch können sich meine Module voll-automatisch richtig konfigirieren,
nur eben der "Müll" in der .DPR bleibt reine Handarbeit.
Die Gefahr ist, das man was vergisst, und dann gibt es nicht immer eine klare Fehlermeldung.
Die App crasht vielleicht weil irgend ein Fix vergessen wurde, oder veraltet ist.

5. Weil Fixes auch ständig upgedatet werden müssen, muss ich dann zig Kopien, in zig. Projekten updaten.
Ich habe mir dafür ein Kopier-System gebaut, so dass ich aus einem Fixes-Master die aktuellen Fixes in jedes Projekt updaten kann.

6. In Erweiterung zu 5.) verwaltet das dann auch verschiedene Ide-Versionen, also
Rx10.3.3, Rx.10.4.0, etc., so das jede IDE die zu ihr passenden Fixes bekommt.

Mir fallen bei längerem Nachsinnen womöglich noch mehr Gründe ein,
aber das hier reicht schon mehr als aus um mir Bauchschmerzen zu machen.


@Rolf Frei
Danke für den Vorschlag, genau das möchte ich ja machen.
Leider kommen damit z.B. Ide/Debugger nicht immer klar, wie unten beschrieben,
auch wenn Compiler/Linker etwas Lauffähiges produzieren.

Ich hatte schon oft in Sourcen gedebuggt und gesucht, nur um dann nach Stunden festzustellen das die IDE mal wieder das falsche File geladen hatte.
Deshalb kann ich die Files eben nicht in Unterverzeichnisse zusammenfassen, sondern es muss wohl Alles zusammen bei .DPR und .DPROJ im Verzeichnis liegen.
Nur dann habe ich die Gewähr das Compiler/Linker/Ide/Debugger IMMER das richtige File öffen/nutzen.