aldebaran Knowhow
Borland C++Builder Trouble Shooting
Der Borland C++Builder ist ein mächtiges Entwicklerwerkzeug - ohne Frage - allerdings eines mit gewissen Tücken, die Softwareentwickler/innen das Arbeiten schon einmal versalzen können. Die hier beschriebenen Probleme und Lösungen bleiben in der Borland-Dokumentation und anderen Referenzen leider unerwähnt - trotz einfacher Lösungsstrategien.
"Access Violation" oder "Bad stack", wenn eine Member Funktion in einer Package (.bpl Datei) aufgerufen wird. Im Debugger sieht man, dass die Variable "this" bei Funktionsaufruf plötzlich nicht mehr korrekt gesetzt ist.
Builder Version: 6.
Einstellungen: CodeGuard aktiviert.
Umstände: Die exakten Umstände unter denen dieser Fehler auftritt, sind leider nicht bekannt.
Die Lösung: In der Version 6 des Borland C++Builder ist der CodeGuard fehlerhaft implementiert. Wird das Tool nicht zwingend benötigt, kann es zur Lösung des Problems einfach abgeschaltet werden.
Die Direktive #include findet die angegebene Datei nicht mehr.
Builder Version: 6.
Umstände: Dieser Fehler tritt plötzlich auf, die Pfadangabe ist korrekt und nicht verändert worden.
Einstellungen: In den Projekt-Optionen ist die Benutzung von und der Cache für precompilierten Header Dateien eingeschaltet.
Die Lösung: Der Borland C++Builder hat die Kontrolle über die vorkompilierten Header verloren, diese müssen daher neu kompiliert werden. Dazu müssen die alten Kompilate gelöscht werden. Da es keine "clear cache"-Funktion gibt, muss dies manuell geschehen. Konkret sind alle "vcl60.*"-Dateien im Verzeichnis CBuilder6\Lib\ (vcl60.csm und vcl60.#??) zu löschen. Durch ein anschließendes Make oder Build des Projektes werden diese Dateien wieder erzeugt.
Linker-Fehlermeldung: "unresolved external ..."
Builder Version: 6.
Dieser Linker-Fehler kann verschiedene Ursachen haben (hier in der Reihenfolge der Wahrscheinlichkeit):
- Eine Unit oder Bibliothek fehlt im Projekt.
- Es gibt ein Problem mit verschiedenen Aufruf-Konventionen, besonders dann, wenn externe Bibliotheken verwendet werden. In Header Dateien von externen Bibliotheken sollte daher immer die Aufruf-Konvention bei Funktionen angegeben werden (in der VCL steht deshalb überall "__fastcall"). Konkret gibt es besonders dann diese Probleme, wenn in einer Funktions-Deklaration keine Aufrufkonvention angegeben ist, die Deklaration aber in zwei Projekten benutzt wird (z.B. Bibliothek und Applikation), die verschiedene standardmäßige Aufruf-Konventionen verwenden. Unter Projekt-Optionen/Compiler Erweitert (Advanced Compiler) lässt sich die Standard-Aufrufkonvention für ein Projekt festlegen.
- Es kommt jedoch vor, dass der Fehler unerklärlicherweise auftritt, obwohl die Unit definitiv im Projekt eingebunden und die Aufrufkonvention richtig ist. Die Länge des Dateipfades scheint eine Rolle zu spielen. In diesem Fall hilft es, das Projektverzeichnis umzubenennen, z.B. ein Zeichen hinzuzufügen. Ein Löschen von Zwischenprodukten (.obj Dateien, il*) bringt hier nichts.
Linker-Fehlermeldung: "unresolved external ..."
Builder Version: 6.
Wenn diese Fehlermeldung erscheint, obwohl die angegebene LIB-Datei nicht mehr Teil des Projektes ist, dann ist evtl. der Verweis auf diese Datei nicht korrekt gelöscht worden. Die Lösung: Beenden Sie den Borland C++Builder, und öffnen Sie mit einem einfachen Text-Editor die Projektdatei (Endung auf *.bpr), löschen Sie nun manuell alle Referenzen auf die entsprechende Datei. Starten Sie erst danach den C++ Builder wieder. Die Fehlermeldung sollte dann nicht mehr erscheinen.
