Unmanaged DLL in C++/CLR - Parameter erhalten nicht nachvollziehbare Werte

[TobiasX2E]

Halli Hallo!

Mein Problem ist folgendes:

Ich habe eine unmanaged DLL auf welche ich mit einem C++/CLR Programm zugreife. Das Funktioniert soweit auch ganz gut, nur ein Struct bzw. eine Funktion in der DLL bereitet mir derzeit erhebliche Probleme.

Ich habe die DLL ganz normal über die Projekteinstellungen eingebunden, dazu habe ich auch die zugehörige Headerdatei inkludiert und in ein #pragma unmanaged gefasst.

Die DLL dient als API um Messungen im sog. BLF Dateiformat auszulesen. Das heisst ich kriege durch einen entsprechenden Funktionsaufruf immer die nächste Nachricht in Form eines Objektes. Dies Funktioniert soweit auch ganz gut...
Außerdem bietet mir die DLL einen Struct ( VBLStatisticsEx_t ) welcher einige allg. Informationen über die Messung enthält und ( vor allem wichtig für mich ) die gesamte Anzahl der Messwerte ( mObjectCount ) und die Anzahl der gelesenen Nachrichten ( mObjectsRead ).

Die Statistik Werte werden über die Funktion BLGetFileStatisticsEx ( HANDLE, &VBLStatisticsEx_t ) geschrieben ( siehe folgendes Codebeispiel )

VBLFileStatisticsEx_t Statistics;		      // Das Statistik Objekt wird erstellt
BLGetFileStatisticsEx( hFile, &Statistics);	// Die Werte werden in das Objekt geschrieben

Das Handle hFile stellt quasi die auszulesende Datei dar.

Mein Problem ist nun dass in das Objekt Statistics des öfteren ( aber nicht immer ) einfach nur Schrott , also vollkommen unplausible Werte, geschrieben werden.
Es macht dabei einen Unterschied ob das Objekt direkt vor dem Funktionsaufruf erstellt wurde oder ob noch ein paar Zeilen Code dazwischen sind. ( Definiere ich das Objekt direkt vor dem Funktionsaufruf funktioniert es meistens ).
Jedoch sollte das eigentlich ja keinen Unterschied machen?

Ich hoffe ich konnte mein Problem einigermaßen beschrieben, wenn nicht geh ich gerne an manchen Stellen ins Detail.
Grüße

Tobias

Dies geh

[theta]

Zeige mal ein Bsp. wo es geht und wo nicht.

[TobiasX2E]

Hey , danke erstmal für die schnelle Antwort
hier mal ein ausgedünntes Beispiel:

Die Funktion NextMsg() wird von einer Applikation ( in einer Schleife ) aufgerufen und soll immer die nächste Nachricht liefern. In der while Schleife befindet sich normal noch eine Switch/Case Anweisung welche die einzelnen Nachrichtentypen unterscheidet. Die while Schleife dient dafür dass der gefundene Nachrichtentyp nicht korrekt sein sollte, die nächste Nachricht gelesen wird ( BLPeekObject ) bis eine korrekte Nachricht gefunden wird ( auf wunsch kann ich auch den Original Quellcode posten )

// Diese Variante funktioniert NICHT
	unsigned int BLFReader::NextMsg()
	{
		unsigned int currentObj;						
		VBLObjectHeaderBase base;						// Wird für das Nachrichtenobjekt benötigt
		VBLFileStatisticsEx_t Statistics;				
		while(BLPeekObject(hFile, &base))				// Nachrichtentyp wird definiert
		{
			BLGetFileStatisticsEx( hFile, &Statistics);	
			// Hier ist normal noch eine Switch/Case Anweisung welche zwischen den einzelnen Nachrichtentypen
			// unterscheidet und diese dann ausliest.
			// Die Alternative ist BLSkipObject
			BLSkipObject(hFile,&base);						// Objekt wird übersprungen
		}
		return currentObj;
	}

// Diese Variante funktioniert 
	unsigned int BLFReader::NextMsg()
	{
		unsigned int currentObj;						
		VBLObjectHeaderBase base;						// Wird für das Nachrichtenobjekt benötigt
		VBLFileStatisticsEx_t Statistics;				
		while(BLPeekObject(hFile, &base))				// Nachrichtentyp wird definiert
		{
			VBLFileStatisticsEx_t Statistics;
			BLGetFileStatisticsEx( hFile, &Statistics);	
			// Hier ist normal noch eine Switch/Case Anweisung welche zwischen den einzelnen Nachrichtentypen
			// unterscheidet und diese dann ausliest.
			// Die Alternative ist BLSkipObject
			BLSkipObject(hFile,&base);						// Objekt wird übersprungen
		}
		return currentObj;
	}