EAccessViolation bei ListBox->Items->Add [gelöst]



  • @akari: Ich intepretiere deine Antwort mal so: Du hast mitgelesen und bist auch der Meinung, dass keine Fehler zu finden sind und es eigentlich so funktionieren müsste!?!

    Allgemein zu meiner Benutzung des BCB3: Ich suche mir nicht aus, mit welcher IDE ich hier arbeite. Ich habe zwar das BDS2006 zur Verfügung, kann aber darin keine Projekte erstellen, da es im Hause keinen InstallShield-Creator gibt, der mit BDS2006-Projekten klarkommt. Zu allem Übel sind die verantwortlichen Kollegen der Meinung, ein neuer InstallShield-Creator wäre zu teuer... Also muss ich die Projekte im Endeffekt im BCB3 machen. 😞



  • Hallo

    Kolumbus schrieb:

    @akari: Ich intepretiere deine Antwort mal so: Du hast mitgelesen und bist auch der Meinung, dass keine Fehler zu finden sind und es eigentlich so funktionieren müsste!?!

    Seit meinem letzten Post im altem Thread habe ich keine weiteren Ideen zu Fehlerursachen. Da es im BCB6 läuft schiebe ich die Ursache auf den BCB3.

    bis bald
    akari



  • Kolumbus schrieb:

    Ich habe jetzt nochmal ein neues Projekt erstellt[...]

    Das ist aber kein neues Projekt, weil Du ja Dateien, aus einem anderen Projekt
    hineinkopierst.
    Wenn Du ein neues Projekt erstellst, eine ListBox draufknallst und dann z.B.
    in einem Button-Ereignis einen Eintrag hinzufügst, funktioniert es dann?

    Gruß

    Alexander



  • Desweiteren gibt es ja noch andere (kostenfreie) Installer. z.Bsp. InnoSetup, der kann auch InstallShield-Scripte importieren. So das der Installshield ja kein Grund sein kann nicht zu wechseln.



  • Alexander Kempf schrieb:

    Kolumbus schrieb:

    Ich habe jetzt nochmal ein neues Projekt erstellt[...]

    Das ist aber kein neues Projekt, weil Du ja Dateien, aus einem anderen Projekt
    hineinkopierst.
    Wenn Du ein neues Projekt erstellst, eine ListBox draufknallst und dann z.B.
    in einem Button-Ereignis einen Eintrag hinzufügst, funktioniert es dann?

    Nein. AccessViolation bei ListBox->Items->Add("Test"); .

    Interessant ist: in allen Projekten, in denen Add nicht funktioniert, wird immer dieselbe Adresse angesprungen wird (siehe Bild 2 weiter oben)... Sieht da jemand einen Hinweis?

    Braunstein schrieb:

    Desweiteren gibt es ja noch andere (kostenfreie) Installer. z.Bsp. InnoSetup, der kann auch InstallShield-Scripte importieren. So das der Installshield ja kein Grund sein kann nicht zu wechseln.

    Ich kenn mich dahingehend garnicht aus - gibt es auch kostenfreie Installer, die kommerziell genutzt werden dürfen?



  • Hallo

    Das unter gleichen Umständen auch immer die gleichen Adressen verwendet werden ist üblichen.

    Innosetup ist auch kommerziell kostenfrei einsetzbar.

    bis bald
    akari



  • akari schrieb:

    Das unter gleichen Umständen auch immer die gleichen Adressen verwendet werden ist üblichen.

    Schade... wär ja auch zu schön, den Fehler greifen zu können.... 😞

    akari schrieb:

    Innosetup ist auch kommerziell kostenfrei einsetzbar.

    Danke für den Link! 🙂



  • Hm, schon mal getestet, ob der Rechner einfach einen Weg hat? Defekter RAM?



  • Hmm.. nö, wie mach ich das jetzt am Schnellsten?

    Edit: Ach Quatsch... kann ich mir ja sparen... im Ursprungsprojekt funktioniert ja ListBox-Items->Add noch!!!



  • Ich weigere mich immernoch zu glauben, dass etwas Grundlegendes mit dem BCB3 nicht stimmt (außer das er alt ist). Deswegen habe ich jetzt nochmal das Projekt geöffnet, wo ich das 1.Mal mit ListBoxen und ListBox->Items->Add gearbeitet habe.
    Dort habe ich auf dem Formular mit den vorhandenen ListBoxen eine neue ListBox und einen Button mit Klick-Methode hinzuzugefügt. In die Klick-Methode habe ich geschrieben:

    ListBox3->Items->Add("Eintrag " + IntToStr(EntryNr));
    EntryNr++;
    

    wobei EntryNr im Header unter private als int EntryNr; deklariert wurde. Im Konstruktor des Forms setzte ich EntryNr= 0;
    Wenn ich das Programm starte, das Formular anzeige und auf den Button klicke, wird "Eintrag 0" in die ListBox3 eingefügt (angezeigt). Beim nächsten Klick kommt "Eintrag 1" dazu usw.
    Es funktioniert also noch - aber warum nicht, wenn ich ein neues Projekt erstelle? 😕



  • Kannst du mir dein Projekt auch mal schicken. Ich würde das auch mal gerne ausprobieren. Allerdings mit dem BCB5.



  • Es funktioniert wieder!!! 😃 🙂 😃 🙂 😃 🙂 😃 🙂 😃 🙂

    Ich habe das alte Projekt (ListBox->Items->Add() funktionierte) und das neue Projekt (das letzte Testprojekt, nur mit Button und ListBox) gleichzeitig geöffnet (2x BCB3 offen) und mir Alles so hingeschoben, dass ich bequem die Projektoptionen von beiden Projekten vergleichen konnte. Dann habe ich alle Einstellungen vom alten Projekt, die sich zum Testprojekt unterschieden, für das Testprojekt übernommen.

    Folgende Einstellungen im Testprojekt waren unterschiedlich:
    (ich liste alle Unterschiedlichen auf, auch wenn ich von Einigen schon weiß, dass sie nicht verantwortlich für den Fehler sein dürften.)
    Ich schreibe hinter ***** die Einstellung im Testprojekt und hinter # die geänderte Einstellung (aus dem alten Projekt übernommen).

    /*
     Compiler-Optionen -> * Endgültige Version
                       -> # voll debuggen
    */
     erweiterte Compiler-Optionen -> Datenausrichtung -> * QuadWord
                                                      -> # DoubleWord
    
     erweiterte Compiler-Optionen -> Gleitkomma -> Schnell -> * Häkchen gesetzt
                                                           -> # Häkchen entfernt
    
     Pascal -> Syntaxoptionen -> Boolsche Ausdrücke vollständig -> * Häkchen gesetzt
                                                                -> # Häkchen entfernt
    
     Pascal -> Syntaxoptionen -> Zuweisbare typisierte Konstanten -> * Häkchen entfernt
                                                                  -> * Häkchen gesetzt
    /*
     Pascal -> Meldungen -> * Alle Meldungen
                         -> # keine Meldungen
    
     Linker -> dynam. RTL verwenden -> * Häkchen entfernt
                                    -> # Häkchen gesetzt
    
     Verzeichnisse / Bedingungen -> Bedingungen -> Definition: -> * leer
                                                               -> # _RTLDLL;USEPACKAGES
    
     Packages -> Laufzeit-Packages -> mit Laufzeit-Packages compilieren -> * Häkchen entfernt
                                                                        -> # Häkchen gesetzt
    */
    

    Ich mach jetzt Feierabend, schaue aber Zuhaus nochmal hier rein... Vielleicht kann ja spontan jemand sagen, an welcher Einstellung es lag und WARUM!?

    @ Braunstein: Danke für das Angebot. Erübrigt sich ja nun.

    Edit: ich kommentiere mal die Einstellungen aus, die ich für nicht relevant halte. Die Anderen teste ich jetzt und versuche herauszufinden, was sie beeinflussen.



  • Gut, es lag wohl an der Einstellung für die Datenausrichtung in den erweiterten Compiler-Optionen. Die Hilfe schreibt dazu:

    Die Optionen Datenausrichtung erlauben, auszuwählen wie der Compiler Daten im Speicher ausrichtet. Word-, Double-Word- und Quad-Word-Ausrichtung zwingen den Compiler Objekte von Integer-Größe (und größer) so auf die Speicheradressen auszurichten, daß die Startadressen immer ein Vielfaches von dem gewählten Typ sind. Es werden zusätzliche Bytes in Strukturen eingefügt, um sicherzustellen, daß Elemente korrekt ausgerichtet sind.

    Vorgabe = Double Word (32-Bit)

    Byte richtet auf 8-Bit-Grenzen aus.
    Word richtet auf 16-Bit-Grenzen aus.
    Double Word richtet auf 32-Bit-Grenzen aus.
    Quad Word richtet auf 64-Bit-Grenzen aus.

    Kann jemand erklären, warum es bei ListBox->Items->Add() zu der Zugriffsverletzung kommt, wenn die Datenausrichtung auf QuadWord gestellt ist?
    So ganz klar ist mir das nämlich nicht. Ich wäre der Meinung, dass diese Einstellung auf QuadWord lediglich dazu führt das für das Programm mehr Speicher gebraucht wird!?



  • Hast du mal versucht herauszubekommen an welcher Einstellung es wirklich liegt, indem du immer nur eine Einstellung änderts?



  • Ähmm ... ich weiß nicht warum es nicht ankam... für mich ist mein letzter Post eindeutig!

    Es lag an: erweiterte CompilerOptionen -> Datenausrichtung -> "Quad Word"

    Dieses habe ich jetzt auf "Double Word" gestellt!



  • Ich wusste nur jetzt nicht wie du das festgestellt hast. Es kam mir einfach so unwahrscheinlich vor, dass die Datenausrichtung einen Fehler verursacht. Bei den Runtime-libs oder den Packages-Einstellungen ist das eher schon mal möglich.
    Wenn du es aber so festgestellt hast, dann ist es ja ok und wir haben wieder was gelernt. 🙂



  • Auch für mich klang das eher nach einer Vermutung, als nach einer Feststellung.

    Und bitte nochmal für mich (absolut ungläubig wie ich bin): Wenn Du nur die Datenausrichtung auf QuadWord stellst, ist der Fehler wieder da?



  • Joe_M schrieb:

    Und bitte nochmal für mich (absolut ungläubig wie ich bin): Wenn Du nur die Datenausrichtung auf QuadWord stellst, ist der Fehler wieder da?

    Ja.

    Auch wenn ich nicht weiß weshalb. Es wär wirklich schön, wenn mal jemand eine Theorie dazu hat. Ich würde auch vorgeschlagene Tests machen, weil es mich interessiert was da schiefläuft.



  • Im BCB6 gibt es einen Bug bei den ADO-Komponenten, der ebenfalls mit der Byteausrichtung zusammenhängt. Der führt zwar nicht zu einer Zugriffsverletzung sondern zu einem Speicherleck, aber im Prinzip dürfte es das gleiche Problem sein. Jedenfalls ist die Komponente wohl mit 4-Byte-Ausrichtung kompiliert worden. Wenn jetzt der Header mit anderer Ausrichtung kompiliert wird, verändert sich die Größe der Struktur bzw. Klasse und fordert new unter zu wenig oder mehr Speicher als nötig. Der Rest ist mehr oder weniger undefiniert. Beheben kann man das entweder, indem man die Ausrichtung global in den Projektoptionen umstellt, oder nur im betreffenden Header für die Problemklasse.

    #pragma pack(push,4)
    class TProblemKlasse
    ...
    #pragma pack(pop)
    

    Warum das Problem nur bei bestimmten Komponenten auftritt entzieht sich meinem Verständnis.



  • Guten Morgen,

    @Morris Szylak: Ich hoffe deine Ausführungen richtig verstanden zu haben und habe jetzt Folgendes getestet:

    * Projekt->Optionen->erweiterte Compileroptionen->Datenausrichtung->"Quad Word" (64bit) wieder eingestellt
    * Header der Problemklasse modifiziert:

    //---------------------------------------------------------------------------
    #ifndef NewEACfgH
    #define NewEACfgH
    //---------------------------------------------------------------------------
    #include <Classes.hpp>
    #include <Controls.hpp>
    #include <StdCtrls.hpp>
    #include <Forms.hpp>
    #include <Menus.hpp>
    #include <ExtCtrls.hpp>
    //---------------------------------------------------------------------------
    #pragma pack(push,4)                        // <= eigene Datenausrichtung festgelegt (32bit - Double Word)
    class TFormNewEACfg : public TForm
    {
    __published:	// Komponenten, die von der IDE verwaltet werden
    	//...
    private:	// Benutzerdeklarationen
    	//...
    public:		// Benutzerdeklarationen
    	__fastcall TFormNewEACfg(TComponent* Owner);
    };
    #pragma pack(pop)                           // <= eigene Datenausrichtung zerstört
    //---------------------------------------------------------------------------
    extern PACKAGE TFormNewEACfg *FormNewEACfg;
    //---------------------------------------------------------------------------
    #endif
    

    Der Compiler nimmt das so hin. Die Zugriffsverletzung tritt jedoch immernoch auf. Habe ich etwas falsch gemacht, oder meintest du das so, wie ich es ausgeführt habe?


Anmelden zum Antworten