Hi all,

habe die Komponenten TPipeServer, TPipeClient, TPipeConsole
aus der Unit Pipes von Russel Libby unter Delphi 10.4 benutzt.
In der Unit gibt es auch noch einen Hinweis auf die Herkunft: See blog article at http://francois-piette.blogspot.be

Diese Unit lässt sich unter 11.2 nach folgender Änderung, auch im Implementation, kompilieren.

markieren

Delphi-Quellcode:

    // TFastMemStream class
    TFastMemStream = class(TMemoryStream)
    protected //- declarations
// function Realloc(var NewCapacity : Longint) : Pointer; override;
        function Realloc(var NewCapacity : NativeInt) : Pointer; override;
    end;

Beim Installieren in die IDE bekomme ich folgende Meldung:

Zitat:

Registration procedure, Pipesreg.Register in Package D:\......\PipesDesignTime.bpl raised exception
EAccessViolation: Access violation at address 608C0294 in module rtl280.bpl. Read of address FFFFFFD0

Wenn ich aber einen der Typen/Klassen z.B. TPipeServer in einem Testformular zur Laufzeit instanziere, dann läuft es problemlos.

markieren

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  PipeServer : TPipeServer;

begin

  PipeServer:= TPipeServer.Create(self);
  PipeServer.Active:= True;
end;

Und jetzt ist das Problem, wie kann ich die Stelle wo der Fehler auftritt lokalisieren?
Und hängt es mit demr Änderung von LongInt nach NativInt zusammen? In einem 64Bitsystem haben die ja unterschiedliche Bereiche.
Ich habe das originale Zipfile mal mit hochgeladen. Weis aber nichtmehr wo ich das gefunden habe.

Vieleicht hat ja jemand einen Tipp. Danke!
Charly

Ja, Integer und NativeInt sind per se in Win32 eigentlich identisch gleich.
Früher war auch das eine mal ein Alias für das Andere und somit "identisch",
aber seit 'ner Weile sind diese beiden Typen nicht mehr komapatibel.
z.B. siehe https://quality.embarcadero.com/browse/RSP-39686

Zitat:

wie kann ich die Stelle wo der Fehler auftritt lokalisieren?

mit dem Debugger?

Mit einer weiteren IDE kann man eine andere IDE debuggen, am Besten wenn du dabei auch das Projekt für dieses Package geladen hast.
Start > Prozess laden
oder Mit Prozess verbinden

Zitat:

Beim Installieren in die IDE bekomme ich folgende Meldung

Bei dir knallt es also im Code der Registrierung und nicht nicht im Laufzeit-Code der Komponente.

Hi All,

das Ganze wird noch viel Mysteriöser!
Ich habe eine kleine TestKlasse in der klasse erzeugt und wollte dann nur diese installieren.
Idde war, so durch Weglassen evtl. den Übeltäter zu finden.

Aber jetzt sagt mir Delphi, daß es das Package nicht findet.
Habe dann meine System-Pfade kontrolliert und tatsächlich fehlte der Pfad zu dem Ordner, wo ich meine BPLs hinkompiliere.
Eingetragen und plötzlich kann ich das Package mit den Pipe-Komponenten problemlos installieren.

Die IDE treibt mich noch in den Wahnsinn! Sch...., Sch..., Sch....

Denn jetzt habe ich denselben Fehler bei meiner 10.4 Installation.

Werd mal etwas mit den Pfadeinträgen spielen.
Aber das Elend ist ja, daß ich nicht irgendwie nachfollziehen kann , was hinter den Kulissen passiert.

Das mit dem debuggen von der IDE aus eine IDE hat übrigens auch nicht funktioniert.

Charly

Hi all,

es scheint tatsächlich ein Problem mit den Pfaden zu sein. Dazu kommt allerdings, daß bei diesem Versuch die zu installierende Komponente bei 10.4 und 11.2 gleich hieß.
Nachdem ich die Komponenten in 10.4 und 11.2 unterschiedlich benannt habe, konnte ich sogar den Systempfad auf mein bpl-Verzeichnis wieder entfernen und compilierung und installation läuft trotzdem.

Na ja ?????

Wieso sagt embarcadero dann: der bpl-Ordner muss im Pfad stehen?


Charly

Hast du auch einen eigenen "versionsabhängigen" Ausgabepfad und Suchpfad für die DCP?

Die DCP heißt wie das Projekt, also z.B. auch ohne eventuelle Versionsnummer.

PS: man kann auch die Version/Compiler, Build, und Target als Variable in den Pfaden nutzen.

Zitat von charly52:

Wieso sagt embarcadero dann: der bpl-Ordner muss im Pfad stehen?

Muss er nur dann, wenn du Applikationen mit Runtime-Packages compilierst und die nötigen BPLs nicht mit zur Exe packst.

Aber es stimmt schon: Eigentlich gibt es keinen vernünftigen Grund dafür, denn beim Ausliefern müssen die BPLs ja auch irgendwie zum Kundenrechner und dad der in der Regel kein Delphi hat, braucht man eh eine andere Art der Bereitstellung. Dann kann man die auch gleich auf dem Entwicklungsrechner verwenden.