4. Sprung C-Builder3 zu C-Builder XE

Sprung C-Builder3 zu C-Builder XE

  • A

    Das ist eigenartig. Kannst du verifizieren, daß Unit1.h nicht dieselben Include-Guards wie Unit2.h hat?

    Außerdem könntest du mal mit dem Präprozessor schauen, ob vielleicht ein Makro in die Quere kommt. Du kannst dazu im Projektmanager auf Unit2.cpp rechtsklicken und "Vorverarbeiten" wählen und die entstehende Datei analysieren. Du kannst sie auch zippen und irgendwo hochladen, dann schaue ich sie mir an.

    0
  • A

    Hallo audacia,

    Holla - Da habe ich eine Warnung übersehen, die zu Beginn kommt und gleich weggeschoben wird:
    [BCC32 Warnung] W8123 Pfad 'c:\programme\embarcadero\rad studio\8.0\include\vcl' nicht gefunden - Pfad in Option '-I' ingoriert
    Kann hier das Problem liegen?

    Es ist ein ganz kleines Projekt, daher habe ich wenig "Umfeld", das mir hier querschießen kann. In einem weiteren kleinen Projekt tritt der gleiche Fehler auf, sobald ich eine Struktur in einer zweiten Unit verwenden möchte.

    Das Vorverarbeiten der Unit2 hat keine Fehler ergeben- nur die o.g.Warnung. Hochladen kann ich es gerne - wo am besten? ('tschuldigung - habe ich noch nie gemacht)
    Ich kann es auch gerne per Email senden.

    Danke für Deine Hilfe! Als BCB3-Junkie sitzt man vor dem XE wie Alice im Wunderland...

    0

  • antiriad schrieb:

    Hallo audacia,

    Holla - Da habe ich eine Warnung übersehen, die zu Beginn kommt und gleich weggeschoben wird:
    [BCC32 Warnung] W8123 Pfad 'c:\programme\embarcadero\rad studio\8.0\include\vcl' nicht gefunden - Pfad in Option '-I' ingoriert
    Kann hier das Problem liegen?

    ...

    Ja, könnte hatte da auch mal ein Problem mit, das er nicht übersetzt hat, wenn der Pfad nicht gefunden wurde, auch wenn der eigentlich nicht nötig ist.

    Kontrolliere am besten erst mal, dass alle Pfade auch wirklich existieren, und wirf alle Pfade raus, die nicht benötigt werden.

    Es kann auch sein, das es in einen Suchpfad eine Datei Unit1.h gibt, die XE dann statt deiner gewünschten einbindet, dadurch passieren dann die merkwürdigsten Dinge, u.a. auch sowas "unerklärliches" wie bei dir.

    0
  • A

    antiriad schrieb:

    Holla - Da habe ich eine Warnung übersehen, die zu Beginn kommt und gleich weggeschoben wird:
    [BCC32 Warnung] W8123 Pfad 'c:\programme\embarcadero\rad studio\8.0\include\vcl' nicht gefunden - Pfad in Option '-I' ingoriert
    Kann hier das Problem liegen?

    Nein, eher nicht. Das Problem wird wohl beim Projekt-Upgrade entstanden sein. Du kannst in den Projektoptionen die Einstellung für die Include-Pfade öffnen und dort auf "Ungültige Pfade löschen" klicken.

    Burkhi schrieb:

    Kontrolliere am besten erst mal, dass alle Pfade auch wirklich existieren, und wirf alle Pfade raus, die nicht benötigt werden.

    Es kann auch sein, das es in einen Suchpfad eine Datei Unit1.h gibt, die XE dann statt deiner gewünschten einbindet, dadurch passieren dann die merkwürdigsten Dinge, u.a. auch sowas "unerklärliches" wie bei dir.

    Das sind gute Hinweise. Du kannst auch in der IDE mal dem Include-Statement folgen (in Unit2.h den Cursor auf den Dateinamen in #include "Unit1.h" setzen und Strg+Enter drücken) und schauen, ob du in der richtigen Datei landest.

    Welche Dateien tatsächlich eingebunden werden, kannst du übrigens auch in der vorverarbeiteten Datei lesen, weil diese absolute Pfade enthält.

    antiriad schrieb:

    Das Vorverarbeiten der Unit2 hat keine Fehler ergeben- nur die o.g.Warnung. Hochladen kann ich es gerne - wo am besten? ('tschuldigung - habe ich noch nie gemacht)

    Am besten mit sowas wie Dropbox, auch wenn das eine Anmeldung erfordert. Es gibt auch anmeldungsfreie Filehosting-Anbieter; die sind meistens sehr lästig (Werbung, Wartezeiten beim Herunterladen), aber besser als nichts.

    Vergiß aber nicht, die .i-Datei vorher in ein (ZIP-)Archiv zu packen, das lohnt sich (~4 MB statt ~80 MB).

    0

  • audacia schrieb:

    ...Das sind gute Hinweise.

    Ja, ich hatte dadurch sogar schon den Fall, dass der Code nicht zum Debuggten passte. Dann stand z.B. direkt im Code

    i=0;

    Der Debugger zeigte für i aber einen ganz anderen Inhalt an. Das kam dadurch, das es die entsprechende cpp mehrfach gab und diese im suchpfad erhalten war.

    Auch unerklärliche Sprünge z.B. mitten in eine andere Funktion lassen sich damit meist erklären.

    Eine saubere Verwaltung der Projekt Verzeichnisse ist das A und O. 😉

    0
  • A

    Hallo audacia, Hallo Burkhi,

    audacia schrieb:

    Das sind gute Hinweise. Du kannst auch in der IDE mal dem Include-Statement folgen (in Unit2.h den Cursor auf den Dateinamen in #include "Unit1.h" setzen und Strg+Enter drücken) und schauen, ob du in der richtigen Datei landest.

    Da komme ich in das Hauptverzeichnis des kl. Programms, wo auch die Unit1.h ist - also sollte das passen.

    Die Unit2.i habe ich gepackt und in das neue Dropbox-Konto gegeben. Der Link dazu lautet: https://dl.dropbox.com/u/79522148/Unit2.zip

    Vielen Dank für die Mühe.

    0
  • A

    Die Verwendung derselben Header-Guards kann man damit als Ursache ausschließen, ebenso ein störendes Makro. Die Datei Unit1.h, die der Compiler einbindet, enthält die Definition der Struktur einfach nicht. Leider gibt der Präprozessor entgegen meiner Annahme nur absolute Pfade aus, wenn die Datei nicht im Projektverzeichnis liegt.

    Vermutlich hat Burkhi also recht: der Compiler findet die falsche Datei. Du kannst das erproben, indem du die beiden Units einfach mal in der IDE anders (sinnvoller und eindeutig) benennst. Wenn der Compiler dann die Datei nicht findet, sind deine Pfade falsch konfiguriert, und wenn es dann plötzlich klappt, kannst du dich mal auf die Suche machen nach weiteren Unit1.h-Dateien, die im Suchpfad liegen könnten.

    0
  • A

    Hallo audacia,

    daß er die falsche Datei findet, kann ich mir nicht vorstellen. Dazu habe ich testweise einen Button und ein Edit-Feld eingefügt, das auf der Unit2.i zu finden war.
    Die Strukturdefinition war nach der Deklaration von TForm1 unter Public in Unit1, wenn ich sie direkt hinter public: setze, ist sie plötzlich auch in der Unit2.i erkennbar:

    Unit1.h:

    //---------------------------------------------------------------------------
#ifndef Unit1H
#define Unit1H
//---------------------------------------------------------------------------
#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
//---------------------------------------------------------------------------
class TForm1 : public TForm
{
__published:	// Komponenten, die von der IDE verwaltet werden
    TButton *Button1;
    TEdit *Edit1;
	void __fastcall Button1Click(TObject *Sender);
private:	// Benutzerdeklarationen
public:		// Benutzerdeklarationen
	struct STATUS
	{
		int Status;
		int Datum;
	};
	__fastcall TForm1(TComponent* Owner);
};
//---------------------------------------------------------------------------
extern PACKAGE TForm1 *Form1;
//---------------------------------------------------------------------------
#endif

    Auszug aus Unit2.i:

    /* Unit1.h 10: */class TForm1 : public TForm
/* Unit1.h 11: */{
/* Unit1.h 12: */__published:	
/* Unit1.h 13: */TButton *Button1;
/* Unit1.h 14: */TEdit *Edit1;
/* Unit1.h 15: */void __fastcall Button1Click(TObject *Sender);
/* Unit1.h 16: */private:	
/* Unit1.h 17: */public:		
/* Unit1.h 18: */struct STATUS
/* Unit1.h 19: */{
/* Unit1.h 20: */int Status;
/* Unit1.h 21: */int Datum;
/* Unit1.h 22: */};
/* Unit1.h 23: */__fastcall TForm1(TComponent* Owner);
/* Unit1.h 24: */};
/* Unit1.h 25: */
/* Unit1.h 26: */extern __declspec(package) TForm1 *Form1;
/* Unit1.h 27: */
/* Unit1.h 28: */
/* Unit1.h 29: */
/* Unit1.h 30: */
/* Unit2.h 11: */
/* Unit2.h 12: */class TForm2 : public TForm
/* Unit2.h 13: */{
/* Unit2.h 14: */__published:	
/* Unit2.h 15: */private:	
/* Unit2.h 16: */public:		
/* Unit2.h 17: */__fastcall TForm2(TComponent* Owner);
/* Unit2.h 18: */STATUS *Status1,Status2,Status3;
/* Unit2.h 19: */
/* Unit2.h 20: */};
/* Unit2.h 21: */
/* Unit2.h 22: */extern __declspec(package) TForm2 *Form2;
/* Unit2.h 23: */
/* Unit2.h 24: */
/* Unit2.h 25: */
/* Unit2.h 26: */
/* Unit2.cpp 7: */
/* Unit2.cpp 8: */#pragma package (smart_init)
/* Unit2.cpp 9: */#pragma resource "*.dfm"
/* Unit2.cpp 10: */TForm2 *Form2;
/* Unit2.cpp 11: */
/* Unit2.cpp 12: */__fastcall TForm2::TForm2(TComponent* Owner)
/* Unit2.cpp 13: */: TForm(Owner)
/* Unit2.cpp 14: */{
/* Unit2.cpp 15: */}

    Nun habe ich's - dachte ich - aber nein, der Fehler ist immer noch da.
    Ich verstehe die schöne neue Welt nicht...

    0
  • A

    antiriad schrieb:

    daß er die falsche Datei findet, kann ich mir nicht vorstellen. Dazu habe ich testweise einen Button und ein Edit-Feld eingefügt, das auf der Unit2.i zu finden war.
    Die Strukturdefinition war nach der Deklaration von TForm1 unter Public in Unit1

    Was, wo war die Strukturdefinition? In der Klassendefinition von TForm1 verschachtelt?

    Zeig mal dein ursprüngliches Unit1.h.

    antiriad schrieb:

    wenn ich sie direkt hinter public: setze, ist sie plötzlich auch in der Unit2.i erkennbar:

    Und dann ist sie natürlich nicht mehr im globalen Namespace, und du mußt TForm1::STATUS statt STATUS schreiben, wenn du sie verwendest.

    0
  • A

    Hallo audacia,

    Volltreffer - das war eine Eigenheit des BCB3, und ich habe es wie selbstverständlich weitergemacht.
    Im globalen Namespace hatte ich im BCB3 (vor über 10 Jahren!) Probleme, und eine in die Formularklasse eingebundenene Struktur konnte wie eine globale angesprochen werden. Ich habe den Wald vor lauter Bäumen nicht gesehen, und suche tagelang ein Phantom.

    Vielen Dank für die Hilfe! Das hätte ich verbohrt in BCB3 nie gefunden.

    ... aber nun bin ich erstmal fix und fertig.

    Gruß

    0
Anmelden zum Antworten