Dll Klassen Problem bei Release Version

Johannes251298

hustbaer schrieb:

Oder das Programm einfach crashen lassen.
Dabei kommt dann eh der "Scheisse, Fehler!" Dialog. Normalerweise läuft dieser Dialog noch im gecrashten Prozess, d.h. man kann sich auch erst zu dem Zeitpunkt mit dem Debugger draufhängen und sehen was schief gelaufen ist.

Wenn man Visual-Studio installiert hat sollte eigentlich auch ein "Scheisse, Fehler!" Dialog kommen, wo ein "mit Visual Studio Version X debuggen" Button drinnen ist. Der dann automatisch VS startet und den gecrashten Prozess attached.

Es kommt ja garkein Fehler oder Runtime-Error, nichts! Er bleibt nur bei der initialisierung der Klassen stehen und nach ungefähr 1er sekunde schliest sicht das Program.

Seltsam. Im Falle eines Fehlers muesste da immer irgendwas kommen. Es sei denn, du faengst ihn ab und beendest dich selbst.
Kannst du mal etwas relevanten Code zeigen. Also beispielhaft eine Klasse und wie du sie erstellst. Besser noch ein minimales kompilierbares Beispiel, dass den Fehler reproduziert.

Martin Richter

Breakpoints setzen.
Bist Du sicher dass DLL und EXE auch beides als Release/Debug compiliert sind.
Oder könnte es sein, dass Du Release EXE mit Debug DLL betreiben willst (oder vice versa).

Johannes251298

Also, es sind beide mit Release ausgewählt und Multithreaded MT erstellt worden, DLL und Programm.

Und das mit dem Beispiel einer Klasse wird auch schwierig da nehmlich die meisten 1000 bis 3000 Zeilen haben.

Aber so sind sind sie alle ungefähr aufgebaut:

class CONTROLSDLL_API Controls::CButtonEx 
{
public:
	// ...
private:
	// ...
};

Und anwenden mach ich immer so:

#include <Controls.h>
#pragma comment(lib, "Controls.lib")
using namespace Controls;

CButtonEx *Button1 = new CButtonEx;

Vielen Dank für eure Hilfe!
Johannes

C und Ex sind ja schon geil, aber die Kombination von C und Ex topt alles!

hustbaer

Johannes251298 schrieb:

hustbaer schrieb:

Oder das Programm einfach crashen lassen.
Dabei kommt dann eh der "Scheisse, Fehler!" Dialog. Normalerweise läuft dieser Dialog noch im gecrashten Prozess, d.h. man kann sich auch erst zu dem Zeitpunkt mit dem Debugger draufhängen und sehen was schief gelaufen ist.

Wenn man Visual-Studio installiert hat sollte eigentlich auch ein "Scheisse, Fehler!" Dialog kommen, wo ein "mit Visual Studio Version X debuggen" Button drinnen ist. Der dann automatisch VS startet und den gecrashten Prozess attached.

Es kommt ja garkein Fehler oder Runtime-Error, nichts! Er bleibt nur bei der initialisierung der Klassen stehen und nach ungefähr 1er sekunde schliest sicht das Program.

Dann knall irgendwo ganz am Anfang ne MessageBox rein, oder einen DebugBreak Aufruf.

Johannes251298

Das mit den MessageBoxen habe ich schon probiert, aber ich glaube das ich einfach nur eine bestimmte Anzahl von den Klassen initialisieren kann, weil wenn es nur eine oder zwei sind geht's.

Leider brauche ich aber mehr als nur eine oder zwei.

EDIT: Gerade eben habe ich gemerckt das das Problem nur bei der CButtonEx Klasse ist, sobald eine CButtonEx initialisiert wird, Crash. Was kann zu solchen Problemen führen? Damit ich weis wo nach ich suchen muss, die hat nehmlich 1500 Zeilen!!! Um da nen Fehler zu finden...

Johannes251298

Problem behoben!
Es waren nur ein paar typedefs die ich in der DLL auserhalb des namespace Controls hatte und im include header für's Programm waren sie im namespace drin.

hustbaer

WTF???

Hast du die öffentlichen Deklarationen/Definitionen etwa doppelt vorliegen (1x im öffentlichen Include-File und 1x extra irgendwo in einem privaten Include-File)? Sowas macht man einfach nicht.
Inkludiere einfach das öffentlichen Include-File auch wenn du die DLL selbst baust, dann kann sowas gar nicht mehr vorkommen.

Johannes251298

hustbaer schrieb:

WTF???

Hast du die öffentlichen Deklarationen/Definitionen etwa doppelt vorliegen (1x im öffentlichen Include-File und 1x extra irgendwo in einem privaten Include-File)? Sowas macht man einfach nicht.
Inkludiere einfach das öffentlichen Include-File auch wenn du die DLL selbst baust, dann kann sowas gar nicht mehr vorkommen.

Und wie bringe ich dan das CONTROLSDLL_API da rein damit er die Klasse exportiert oder importiert???

hustbaer

#ifdef BUILDING_CONTROLSDLL
#define CONTROLSDLL_API __declspec(dllexport)
#else
#define CONTROLSDLL_API __declspec(dllimport)
#endif

Im DLL Projekt definierst du dann einfach über die Projekteigenschaften das Makro BUILDING_CONTROLSDLL . Tadaa.

Zweite Möglichkeit (geht genau so, ist aber glaub ich weniger verbreitet):
Stdafx.h der Controls.dll :

#define CONTROLSDLL_API __declspec(dllexport)

Öffentliches Header File der Controls.dll :

#ifndef CONTROLSDLL_API
#define CONTROLSDLL_API __declspec(dllimport)
#endif

Wenn das Projekt mehr als nur Windows unterstützt dann brauchst du ggf. weitere #if/#ifdef , aber auch das lässt sich machen.

ps: das ist keine Rocket-Science, da kann man auch selbst draufkommen. Oder es sich von einem der Millionen Open-Source Projekte abgucken, die auch alle irgendwie dieses Problem lösen. Ein wenig Selbständigkeit könnte nicht schaden.

Johannes251298

Vielen Dank !!! Klappt alles perfekt.