Beispielprogramm startet nicht, die zweite

[Delbor]

Hi zusammen

Dieses Problem hatte ich auch schon hier - allerdings mit dem Unterschied: es gibt diesmal weder eine Exe noch DCUs, die gelöscht werden könnten. Doch erstmal gleich eine Ansicht der Mainform:
Anhang 49718
Ja, das Beispiel ist schon uralt, dürfte - oder sollte - mir aber Fragen beantworten, die entstanden, als ich mich durch den Wald von Infos kämpfte und plötzlich die Bäume nicht mehr sah. Wie damals zeigt mir Delphi die selbe Unit an und will sie erst speichern, bzw. motzt, weil da (unter Programme) nicht gespeichert werden kann.
Wie man dem jpeg entnehmen kann, werden schon Teile der uses-Liste angemeckert, bevor überhaupt versucht wird, zu kompilieren. Diese Liste mit den Namespaces zu ergänzen, bringt rein gar nichts.

Was kann ich tun, um das Progrämmchen doch noch zum laufen zu bringen?

Gruss
Delbor

[Luckie]

Erstmal das Demoprojekt mit seinen Dateien an einen Ort kopieren, wo du auch Schreibrechte hast. Dann die Namespaces ergänzen. Und dann gucken, was es noch für Fehler gibt. Eventuell Unicode, könnte ich mir vorstellen.

[Delbor]

Hi Luckie

Danke für deine Antwort!

Zitat:

Zitat von Luckie (Beitrag 1410633)

Erstmal das Demoprojekt mit seinen Dateien an einen Ort kopieren, wo du auch Schreibrechte hast. Dann die Namespaces ergänzen. Und dann gucken, was es noch für Fehler gibt. Eventuell Unicode, könnte ich mir vorstellen.

Da befindet es sich bereits - auf meiner Developer-Partition. Aber Unicode ist ein gutes Stichwort. Zumindest bringt mich das auf das Stichwort 'Speicheradressen' - aber dadurch möglicherweise auch wieder auf eine falsche Fährte, da Speicheradressen wohl in der EXE oder den DCUs stehen. Und dieses Beispiel hat zur Zeit weder das eine noch das andere - zumindest nicht auf der aktuellen Maschine.

Die Uses-Liste mit den Namespaces zu ergänzen, hat übrigens nichts geändert.

Ich seh da allerdings noch eine andere Möglichkeit: unter Übernahme des enthaltenen Quellcodes die Anwendung völlig neu erstellen.

Was mich allerdings irritiert: ich habe dieses Problem vor allem mit älteren Beispielprogrammen. Eigenentwicklungen, die zuletzt unter einem der XE-Delphis und anschliessend mit Delphi Tokio kompiliert wurden, laufen dann auch nicht mehr unbedingt auf älteren Delphis. Das aber ist doch eine etwas andere Liga (Weiterentwickelte Fremdkontrolls zB.).

Gruss
Delbor

[KodeZwerg]

Hui... Baujahr 1997, da war Delphi noch sehr jung. Da wirst Du dutzende Fehler schon alleine wegen falscher/fehlender Parameter/Typen von Methoden bekommen, die Ursprüngliche Api ist absolut nicht kompatibel zu Deinem Delphi Tokyo/CE.
Soll nicht heissen das es nicht machbar wäre, nur enorm aufwändig.
Ich würde an Deiner Stelle mir aktuellere Beispiele besorgen die, was auch immer Du versuchst zu Lernen, das vermitteln was Du benötigst.

edit
Andererseits könnte es auch das perfekte Lernprojekt sein, da Du gezwungen wirst überall Hand anzulegen.

[jaenicke]

Zitat:

Zitat von KodeZwerg (Beitrag 1410705)

Hui... Baujahr 1997, da war Delphi noch sehr jung. Da wirst Du dutzende Fehler schon alleine wegen falscher/fehlender Parameter/Typen von Methoden bekommen, die Ursprüngliche Api ist absolut nicht kompatibel zu Deinem Delphi Tokyo/CE.

Wenn alles sauber programmiert ist (PChar, PAnsiChar, PWideChar usw.), nicht. Delphi ist schon ganz gut abwärtskompatibel.

Konkret sehe ich in dem Screenshot aber nur die Fehler von Error Insight, das zwar in 10.2 mittlerweile recht brauchbar ist, aber trotzdem noch manchen falschen Fehler anzeigt, insbesondere bei alten Projekten. Kommt denn auch beim Kompilieren ein Fehler?

[Luckie]

Zitat:

Zitat von Delbor (Beitrag 1410703)

Die Uses-Liste mit den Namespaces zu ergänzen, hat übrigens nichts geändert.

Tokyo braucht sie aber. Und es wird ein Fehler von vielen sein.

[Delbor]

Hi KodeZwerg

Ich hab mir mal den Code des Beispiels durchgesehen, ohne es zu starten und gesehen, dass es mir meine derzeitige Frage nicht beantwortet und auch nicht einen wesentlichen Tip gibt, um zur Antwort zu gelangen. Somit ist das Beispiel vorerst AdActa gelegt.

Die aktuelle Frage wurde jedoch nicht durch ein Beispielprogramm, sondern durch ein 'kluges Buch' beantwortet: "COM/DCOM mit Delphi von Andreas Kosch. Interessant dabei: das Buch ist mit Geburtsdatum...ähh Copyright 2000 nicht wesentlich Jünger als das hier genannnte Beispielprogramm.

Das Lernziel ist folgendes: Ich habe die Typbibliothek des PDFCreators importert und will nun mein Testprogramm dazu bringen, mit der Typbibliothek zu arbeiten.

Zitat:

Zitat von jaenicke (Beitrag 1410715)

Zitat:

Zitat von KodeZwerg (Beitrag 1410705)

Hui... Baujahr 1997, da war Delphi noch sehr jung. Da wirst Du dutzende Fehler schon alleine wegen falscher/fehlender Parameter/Typen von Methoden bekommen, die Ursprüngliche Api ist absolut nicht kompatibel zu Deinem Delphi Tokyo/CE.

Wenn alles sauber programmiert ist (PChar, PAnsiChar, PWideChar usw.), nicht. Delphi ist schon ganz gut abwärtskompatibel.

Konkret sehe ich in dem Screenshot aber nur die Fehler von Error Insight, das zwar in 10.2 mittlerweile recht brauchbar ist, aber trotzdem noch manchen falschen Fehler anzeigt, insbesondere bei alten Projekten. Kommt denn auch beim Kompilieren ein Fehler?

Der liegt darin, dass Delphi erstmal eine Unit (Const.pas?) in C:\Programme\Embarcadero\..\..\Source speichern will, aber natürlich nicht kann.

Gruss
Delbor

[DeddyH]

Hast Du ein FMX-Projekt angelegt? Mir fällt auf, dass im Screenshot nur diejenigen Units bemängelt werden, die zur VCL gehören, die der RTL hingegen nicht.

[Delbor]

Hi DeddyH

Nein, das ist kein FMX-Projekt - das müsste schon von der Oberfläche her auffallen, wenn das Outfit des Formulardesigners noch das selbe ist.

Gruss
Delbor

[Delbor]

Hi zusammen

Das Programm läuft seit 2 Tagen. Die uses-Liste der Mainform, von mir um den einen oder anderen Namespace ergänzt:

Delphi-Quellcode:

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils,
  Classes, Graphics, Controls, Forms, Dialogs,
  Menus, StdCtrls, ExtCtrls;

Weshalb das Programm läuft? Ich hatte als Ausgabe-Pfad für Units einen Ordner 'DCP&DCU' im Verzeichnis des Beispielprogrammes angeggeben - eh voila...

Tja, das Problem scheint doch wieder mal vor dem Bildschirm zu sitzen - oder doch nicht nur? Vielleicht sollte der 'Ausgabepfad für Units' doch einfach allgemeinverständlicher 'DCU-Pfad heissen? Units können irgendwo gespeichert werden, auch die *pas.
Oder, falls sich die Pfadbezeichnungen ändern, solllten sie in der Hilfe und auf dem Dialog in der selben Reihenfolge erscheinen...

Gruss
Delbor