4. Fehler beim Beenden der Anwendung, nur bei aktiver XP-Theme

Fehler beim Beenden der Anwendung, nur bei aktiver XP-Theme

  • N

    Sch..., ertappt. Hatte vergessen die Header-Datei für den Im- Export zu includieren.

    #ifndef _TESTINC
#define _TESTINC

#ifdef __DLL__
	#define __EXPORT_TYPE __declspec(dllexport)
#else
	#define __EXPORT_TYPE __declspec(dllimport)
#endif
//-----------------------------------------------------------------------------
__EXPORT_TYPE void showBPLform(void);
//-----------------------------------------------------------------------------

#endif

    Allerdings konnte ich die BPL-Datei dann nicht linken. Es kamen 74 Linkerfehler mit nicht auflösbaren externen Symbolen. Alle haben mit der VCL zu tun. Ohne die Header-Datei kompiliert und linkt die BPL, allerdings exportiert diese dann meine Beispielfunktion ja nicht. 😕 😕 😕

    0
  • A

    Netzschleicher schrieb:

    Allerdings konnte ich die BPL-Datei dann nicht linken. Es kamen 74 Linkerfehler mit nicht auflösbaren externen Symbolen.

    Ah, richtig - wenn dein Package die VCL benutzt, mußt du "vcl.bpi" zu den erforderlichen Packages hinzufügen. Desgleichen für weitere Komponenten, die du referenzierst - etwa für die Ribbon-Controls bräuchtest du noch "vclribbons.bpi".

    Einfach Rechtsklick im Projektmanager auf "Erfordert", dann .bpi-Datei auswählen. Findest du unter $(BDS)\release .

    0
  • N

    Ah, verstehe. Bis jetzt findet sich bei "Erfordert" lediglich die rtl.bpi.
    Hab jetzt die vcl.bpi hinzugefügt und neu kompiliert. Jetzt läuft das Programm.
    Supi.
    Werd ich mir speichern, als referenz, wenn ich die Packages mal brauche.
    Danke sehr. 🙂 🙂 🙂

    0
  • N

    Und wieder ich. 😕

    Nachdem mir audacia mit dem Code

    void setIsLibrary (void) {
    System::IsLibrary = true;
}
#pragma exit setIsLibrary 31

    sehr geholfen hat mein Problem mit der AccessViolation beim Beenden meiner Anwendung unter aktiver XP-Theme zu beheben, taucht dieses nun wieder auf.

    Ich habe in meiner Anwendung im Hauptmodul zwei Abfragen, mit denen ich prüfe ob die DLLs auch wirklich zu meiner Anwendung gehören, und eine die Abfrägt ob das Datamodul initialisiert ist. Beide Abfragen werfen jeweils mit

    throw Exception( <Fehlermeldung> )

    eine Exception um das Programm dann zu beenden. Diese Abfragen finden im Konstruktor des Hauptfensters statt. Nun wäre ich wieder für einen Tipp dankbar, um den Fehler auch bei einer Exception zu beheben.

    Oder gibt es noch eine bessere Möglichkeit ausser einer solchen Exception das Programm vorzeitig aus dem Konstruktor heraus zu beenden?

    Vielen Dank in Voraus, Netzschleicher

    0
  • A

    In meiner Beispielanwendung habe ich jetzt einfach mal im Konstruktor eine Exception geworfen. Das verursacht unter XP nach wie vor keine AV. Bitte zeig mal genau, was du gemacht hast. (Du kannst auch gerne wieder ein Projekt hochladen.)

    0
  • N

    Hallo audacia,

    folgende Konstellation:

    im Konstruktor des Hauptfensters ist folgende Abfrage:

    __fastcall Tfrmmain::Tfrmmain(TComponent* Owner) : TForm(Owner) {

...

// Pruefen der Resourcen DLL
CheckDllID(resID(), "res.dll", 55631002);  // ID-Nummer der Resource-DLL

...

}

    weiter unten dann in der Source-Datei des Hauptfensters:

    void Tfrmmain::CheckDllID(int dllfunc, AnsiString DllName, int DllID) {
	if (DllID != dllfunc) {
		throw Exception ("DLL: " + DllName + " ist keine gültige Programm-DLL");
	}
}

    und genau da kracht es dann mit folgender Fehlermeldung:

    Exception-Klasse EAccessViolation mit Meldung 'Zugriffsverletzung bei Adresse 5B0F1531 in Modul 'uxtheme.dll'. Lesen von Adresse 00000014'. Prozess TPO.exe (2100)

    der Debugger bleibt in der Datei 'Forms.hpp' bei folgender Zeile stehen:

    /* TCustomForm.Destroy */ inline __fastcall virtual ~TForm(void) { }

    Unter Win2000, Win7 und WinXP mit klassischem Theme ist wiederum alles in Ordnung.

    0
  • A

    Das ist äquivalent zu meinem Programm, und ich habe dein Problem nicht.

    Bindest du die DLL wieder statisch ein?

    0
  • N

    Ja, die DLL wird weiterhin statisch eingebunden.
    In der DLL-Datei in welcher auch der

    int WINAPI DllEntryPoint

    steht, habe ich den kleinen Workaround von Dir für das schon gelöste Problem untergebracht.

    0
  • A

    Dann bitte ich um ein vollständiges Beispielprojekt, da ich es so nicht reproduzieren kann.

    0
  • N

    Oh mann ist das Peinlich. 😞 😞 😞

    Da hab ich mir selbst ein Bein gestellt. Aber ich bin jetzt dadurch drauf gekommen, als Du gesagt hast, das der Fehler bei Dir nicht auftritt. Hab dann selbst mal schnell ein kleines Projekt gemacht, und siehe da... kein Fehler.

    Ich hatte Dir doch geschrieben das der Debugger in der 'Forms.hpp' stehenbleibt. Das hab ich mir dann mal genauer angeschaut, nachdem ja in meinem kleinen Projekt auch kein Fehler auftrat.

    Ich musste dann feststellen, das in meiner Anwendung der Abbruch nur kommt wenn der Splashscreen eingeschaltet ist. Und das war mein Fehler, der Splashscreen war noch aktiv als ich die Exception geworfen habe. Hab jetzt in der Funktion in welcher der Throw steht noch der evtl. aktiven Splashscreen gelöscht, und nun ist wieder alles im Butter. 🙂

    Danke Dir trotzdem für Deine Mühe. War ein absolut dämlicher Fehler von mir.

    Grüße Netzschleicher

    0
Anmelden zum Antworten