Wenn der Builder spinnt ...



  • Wir haben in der Firma hierzu die letzten Monaten mal ein bisschen gesammelt - weil hin und wieder hat er ja nen Schuss der Builder.

    Ich hoffe das spart dem einen oder anderen hier und da mal ein Stündchen im Kampf mit IDE und Debugger und unseren Krankenkassen die Behandlung schwerer Nervenleiden.

    Vielleicht ein Beitrag für die FAQ

    ---------------------------------------------------------------

    BCB Vers. 5

    Fataler Linker Fehler Expected Filename:

    Dieser Fehler (bei dem einem nicht verraten wird, welcher Filename
    nun denn erwartet wird), resultiert daraus, dass der C-Builder nicht
    mit Pfaden wie C:\abc\a-b, oder C\xyz (also Leerzeichen, Kommata,
    Bindestrichen
    etc.)
    zurechtkommt. Selbst wenn man alle Module, die sich in solchen
    Verzeichnissen
    befindet, verschiebt und neu einbindet, kann es noch zu Problemen kommen,
    weil
    im Projektfile auch eine History der Pfade gespeichert wird -> Projekt neu
    aufbauen.
    Auch noch andere seltsame Verhaltensweisen ergeben sich aus solchen Pfaden:
    z.B. wird ein geänderter Code zwar compiliert, beim Debuggen merkt man aber
    dass er nicht ausgeführt wird.

    Wenn man den C++Builder an einem solchen Pfad installiert (also z.B.
    d:\c++\Builder), geht natürlich auch nix.

    ---------------------------------------------------------------

    BCB Vers. 5

    Zu beachten beim Erstellen neuer Konsolen-Anwendungen:

    Soll die VCL verwendet werden, dann das die Häkchen so setzen, dass das
    grau hinterlegte "Threads verwenden" auch angeklickt ist. Sonst kommt es
    zu Problemen mit stringstreams.

    ---------------------------------------------------------------

    BCB Vers. 5

    "Diese Anwendung ist für diese Funktion nicht lizensiert"

    Dieser Fehler tritt auf, wenn man in einem Konsolenprojekt bestimmte
    VCL-Funktionalitäten (z.B. die BDE) benutzen will und beim Erstellen
    des Projekts das Häcken bei 'VCL verwenden' nicht aktiviert hatte

    ---------------------------------------------------------------

    BCB Vers. 5

    Das Debuggen einer DLL funktioniert nicht: Er bleibt nicht bei den
    Break-Points
    stehen oder verhält sich sonst irgendwie seltsam.
    1. möglicher Grund: Im Verzeichnis des exe-Clients liegt eine andere
    Version der DLL

    2. möglicher Grund: Werden mehrere exe-Clients verwendet? Den Wechsel eines
    Clients (insbesondere einmal Win-Anwendung, einmal Konsolen-Anwendung)
    verkraftet
    der Debugger anscheinend nicht -> Builder neu starten.

    ---------------------------------------------------------------

    BCB Vers. 5

    Wenn der CBuilder beim Debuggen spinnt und das auch durch Neustarts etc.
    nicht wegzukriegen ist, is es mal den Versuch Wert, alle Projektdateien bis
    auf bpr und bpf zu löschen (oder vorsichtshalber umzubenennen).
    Vor allem die dsk Datei ist ein heißer Kandidat (hier wird gespeichert, wo
    die Breakpoints sind, welche Dateien offen waren. .res, .tds kann auch
    (normalerweise problemlos löschen).
    Sie werden normalerweise automatisch wieder generiert.

    ---------------------------------------------------------------

    BCB Vers. 5

    Problem: Beim Debuggen tritt Fehler EAccessViolation in Adresse ... bei
    Modul comp32p.dll auf.

    Lösung: Überwachungsfenster schliessen und Ausdrücke löschen.



  • Danke, eine schöne Zusammenstellung, auch wenn ein guter Teil davon bereits in der FAQ steht oder aber schon recht häufig hier diskutiert wurde.

    Mal sehen, wie wir den Beitrag mit möglichst wenig Redundanz in die FAQ eingliedern.



  • Redundanz dürfte wohl weniger das Problem sein doch wohl eher, daß der recht gute FAQ Page viel zu wenig Beachtung geschenkt wird :D:D:D
    Schönen guten Abend 😉



  • Ergänzung:

    Wenn das Debuggen einer DLL nicht klappt, prüfen, dass die tds Datei der DLL auch (im richtigen Verzeichnis) vorhanden ist.


Anmelden zum Antworten