Unterschied "Erzeugen" und "Compilieren" - Einstellungen

[himitsu]

Jupp, {$IFDEF DEBUG} war in diesem Fall einfach falsch.
Ob eine Konsole existiert verbunden ist, hängt ja nicht davon ab.

Bei {$APPTYPE CONSOLE} wird im PE-Header vom Compiler Linker ein Flag gesetzt, welches Windows veranlasst vom Start der Anwendung dafür zu sorgen und sie zu verbinden.


GetConsoleWindow solltest du besser vergessen, denn das gilt eigentlich nur für die alte CMD, aber nicht für das neue Terminal (die neue/alte Consolen-Streaming-API)

Stattdessen einfach erst AttachConsole versuchen und wenn das nicht geht, dann AllocConsole.
Nicht zwangsweise immer eine neue Console, sondern, wenn aus einer Konsole gestartet wurde, dann damit verbinden.

[Uwe Raabe]

Es gibt auch noch in den Projektoptionen unter Building - Delphi Compiler - Linker einen Eintrag Generate console application. Das sollte allerdings den gleichen Effekt haben wie die APPTYPE-Zeile.

[haentschman]

Moin...

Kann es sein, daß wir uns eigentlichen Thema Unterschied "Erzeugen" und "Compilieren" verabschieden?
Die Frage ist nicht die Konsole, sondern warum mit Einbindung anderer Units der Fehler 105 NUR mit Erzeugen auftritt. Das Grundgrippe der Konsole ist nicht händisch erstellt, sondern über Datei-Neu in der IDE erledigt.

Zitat:

Jupp, {$IFDEF DEBUG} war in diesem Fall einfach falsch.

Wieso, wenn es mit "Kompilieren" genau das erledigt was tun soll? ...nämlich den passenden Text ausgeben? (mit Kompilieren)

Schuldgefühle, weil ich nichts vernüftiges gelernt habe , habe ich schon alleine...da müßt ihr nicht noch den Finger in die Wunde legen.

[Uwe Raabe]

Zitat von haentschman:

Kann es sein, daß wir uns eigentlichen Thema Unterschied "Erzeugen" und "Compilieren" verabschieden?
Die Frage ist nicht die Konsole, sondern warum mit Einbindung anderer Units der Fehler 105 NUR mit Erzeugen auftritt.

Aktuell treten wir da etwas auf der Stelle. Um das Problem weiter einzukreisen, müsste man es lokal nachstellen können. Generell gibt es keinen Unterschied zwischen Erzeugen und Compilieren (wenn noch keine DCUs vorhanden sind). Weiteres Compilieren kann schon zu unterschiedlichen Ergebnissen kommen, meist verursacht durch zyklische Abhängigkeiten zwischen Units.

Da das Problem ja erst mit dem Einbinden dieser Units auftritt, kann man die Ursache wohl auch nur in diesen Units finden.

[Kas Ob.]

Between the "begin" of the project (dpr file), which is Entry Point, the execution point when the application get control, and the very next line/code there is hidden InitExe function, it will initialize the app, duh, but also will initialize the Units, this is what i suspect is your problem.

The symptoms, is most likely coming form uninitialized variable, where sometimes it is zeroed and it will work fine and later there is different values, leading to heap corruption, by heap corruption i mean the faulty code had written oven many global and most likely (because you are lucky in this case) it overwritten the pipes, otherwise it will be hidden there and very hard to fix.

suggestion:
1) build a small unit with initialization clause.
2) put it as first in the dpr file.
3) make it do Write/Writeln , see if there is an output, if there then you know for sure that there is an abuse in initialization clauses in you other units.
4) Double check your class constructors, if they are expecting some sort of singleton and they are wrong.

On side note, your exception report, showing 5 threads other than the main, what are they ? where did they come from ?

[jaenicke]

Die Frage ist ja, was mit der Konsole passiert. Da das eine richtig eingestellte Konsolenanwendung ist, wird auch eine Konsole erzeugt. Die Frage ist nun, warum sie nicht da ist. Entweder die Erzeugung geht schief, z.B. weil ein Virenscanner da reingrätscht. Oder das Handle wird in einer der Units einfach wieder geschlossen. Es gibt sicher noch mehr Möglichkeiten...

Herausfinden kann man das z.B. mit dem API Monitor, wenn man dort die Aufrufe an die entsprechenden API-Funktionen überwacht. Oder natürlich auch im Debugger, wenn du dort Haltepunkte setzt oder schaust, was im initialization der Units oder in Klassenkonstruktoren darin passiert.

[haentschman]

Moin...

Zitat:

Generell gibt es keinen Unterschied zwischen Erzeugen und Compilieren (wenn noch keine DCUs vorhanden sind)...
Da das Problem ja erst mit dem Einbinden dieser Units auftritt, kann man die Ursache wohl auch nur in diesen Units finden.

...da gehe ich mit. Verstehen ist mein Problem...Compilieren-ok, Erzeugen-105. Ihr könnt mir glauben, ich habe einiges probiert. Ich brauche diese Units. Diese Units sind zugehörig zu einem anderen Projekt und werden im anderen (VCL) Projekt auch fehlerfrei erzeugt und werden gestartet!
Im Zweifel wird nur compiliert, nicht erzeugt!

Morgen setzte ich das Projekt komplett neu auf. Wenn das Problem weiter besteht, versuche ich das Projekt als "Demo" zusammenzustellen. Aber nur als PN auf Anfrage. (Vertrauen)



Nachtrag: In den Units des anderen Projektes wird u.a. auch z.B. VCL.Forms oder VCL.??? referenziert. Die IDE hatte sich beschwert, dass VCL referenziert ist und ob das Ok ist...Mit OK war es erst mal in Ordnung. Sollte das die Ursache sein? Werde ich morgen sehen...

[himitsu]

Wie gesagt, nach einmal Erzeugen, kann eigentlich beim nächsten Kompilieren gar nichts Anderes bei rauskommen.
Beim Build werden alle Units neu kompilert (da, wo die PAS im Suchpfad ist) und beim Compile werden alle Units ignoriert und direkt die DCU genommen (wo das Änderungsdatum vom PAS und DCU zusammen passen).

PS: Änderungen bei IFDEF werden beim Compile nicht beachtet, also wenn sich sonst nichts anderes an der PAS/DCU geändert hat.

[jaenicke]

Zitat von haentschman:

Nachtrag: In den Units des anderen Projektes wird u.a. auch z.B. VCL.Forms oder VCL.??? referenziert. Die IDE hatte sich beschwert, dass VCL referenziert ist und ob das Ok ist...Mit OK war es erst mal in Ordnung. Sollte das die Ursache sein? Werde ich morgen sehen...

Da geht es soweit ich weiß nur um die Namespaces. Sprich Vcl oder Fmx, damit du nicht immer Vcl.Dialogs statt Dialogs schreiben musst.

[himitsu]

Namespaces sind das im Delphi eigentlich nicht wirklich.

Die Units heißen wirklich Vcl.Forms.pas und Fmx.Forms.pas,
aber in den Projektoptionen gibt es "Default-Namespaces".

Wird eine Unit in Uses, z.B. Forms (Forms.pas) nicht gefunden, dann wird nacheinader die Default-Namespaces durchgegangen, und Dateien mit diesen Präfixen gesucht.


PS: Darum kann es z.B. auch Probleme geben, wenn man Fremd-Units nutzt, oder die DPROJ gelöscht hatte.
Wenn im Projekt ein Namespace fehlt, dann wird diese Datei nicht mehr gefunden,
weil z.B. eine neugenerierte .DPROJ andere Optionen (Defaultnamespaces) haben kann, als die alte DPROJ, welche aus einer Codevorlage (Neue VCL-Anwendung) erstellt wurde,
ebenso bei DPROJ aus anderen/alten Delphi-Versionen.