Klotzkopp

Ich glaube, dass VARIANT als Rückgabetyp nicht funktioniert. Mit einem VARIANT-Referenzparameter funktioniert es: Private Declare Function VarTest Lib "test_dll.dll" _ (ByRef v As Variant) As Long -------------------------------------------------- signed long _stdcall VarTest( VARIANT* pv ) { _variant_t v( "Huhu" ); VariantCopy( pv, &v ); return 0; }[/CODE] Es liegt vermutlich daran, dass VARIANT keinen funktionsfähigen Copykonstruktor besitzt.

#include <fstream> using namespace std;

Damit ist nicht viel anzufangen. Was ist varOutPut (Typ), und woher kommt er (lokale Variable, Wertparameter, Referenzparameter,...)? Allgemeine funktioniert so eine Zuweisung nur, wenn varOutPut vom Typ _variant_t ist. Wenn Du mit "rohen" VARIANTs umgehst, musst du die zugehörigen Funktionen (VariantInit, VariantCopy, VariantClear usw.) verwenden: VariantCopy( &varOutput, &adoField->Value );

VARIANT ist eigentlich genau richtig. Um was für einen Wert handelt es sich denn, und wie schreibst du ihn in den VARIANT rein? Das ist nämlich nicht ganz trivial.

http://www.konsumterror.de/werbesongs/s.shtml Unter "Shell".

Eigentlich nicht. Meistens reicht ein GUI-Thread pro Prozess aus, weil der eigentlich sowieso die meiste Zeit wartet. Aber du kannst ja genausogut zwei neue Threads starten. Ein Thread wird dadurch zum GUI-Thread, indem du aus diesem Thread ein Fenster erzeugst. Das darf halt nicht der sein, der die ganze Arbeit macht.

--> Verschoben: C++: Compiler, IDEs, APIs, weil Standard-C/C++ keine Threads kennt. (Ich gehe im folgenden davon aus, dass du von Windows redest) Der GUI-Thread ist der, der das Fenster erstellt, denn für diesen Thread richtet Windows die Messagequeue ein. Wenn also dein ProgressWnd im Hintergrund Arbeit verrichten soll, musst du das Fenster aus dem ursprünglichen Threadkontext erstellen, und dann erst den Arbeitsthread starten. Einen zweiten GUI-Thread solltest du dann nicht mehr benötigen.

Aus der MSDN Library, unter CListCtrl::GetFirstSelectedItemPosition: POSITION pos = pList->GetFirstSelectedItemPosition(); if (pos == NULL) TRACE0("No items were selected!\n"); else { while (pos) { int nItem = pList->GetNextSelectedItem(pos); TRACE1("Item %d was selected!\n", nItem); // you could do your own processing on nItem here } } [/CODE]

Steht in dem Fehlerprotokoll etwas brauchbares drin? Gibt es eventuell ein Rechteproblem?

Wie äußert sich der Absturz denn? Bekommst du eine Fehlermeldung? Wenn ja, welche?

Könntest du einen Link auf diese Beschreibung posten? In meiner MSDN Library steht was anderes.

Man kann das auch mit stringstreams machen: #include <sstream> using namespace std; int main() { double d = 47.11; ostringstream oss; oss << d; string s = oss.str(); }[/CODE]

Du könntest es noch mal drüber installieren.

Ich habe das grad mal getestet: Ein CString::Format-Aufruf oder eine Zuweisung reicht definitiv nicht. Wenn das unter Windows 2000 funktioniert, dann machst du noch irgendetwas anderes. Das wollte ich auch nicht sagen. Aber ich weiß aus eigener Erfahrung, wie es ist, wenn man sich irgendeiner Sache, den eigenen Code betreffend, "sicher" ist. Versuchs mal mit: GetDlgItem( RESOURCE_ID_DES_EDITCTRL )->SetWindowText( m_strGesamtauslastung ); nach dem Format-Aufruf.

Darf ich nochmal fragen, woran du das merkst, wenn nichts angezeigt wird? Hast du das auf dem Win98-System mit dem Debugger geprüft? So, wie du das Programm beschreibst, dürfte es eigentlich auch unter Windows 2000 nicht funktionieren. Eine Zuweisung an eine CString-Variable bewirkt nichts, solange nicht danach UpdateData( FALSE ) aufgerufen wird. Erst dann wird nämlich der Inhalt des CString-Objekts in das Steuerelement übertragen. Vielleicht hilft es, wenn du den relevanten Teil des Codes zeigst.

Heißt das "nein", dass du bei CreateThread im letzten Parameter nicht NULL angibst? Ich habe die Erfahrung gemacht, dass man sich bei solchen Problemen nicht zu schnell auf die eigene Diagnose versteifen, sondern bei den Symptomen bleiben sollte. Bist du sicher (sprich: hast du es mit einem Debugger geprüft), dass auf dem Win98-System dein Thread überhaupt gestartet wird?

Welches ServicePack hast du installiert?

Benutzt du zufällig CreateThread und gibst beim letzen Parameter NULL an?

Auf keinen Fall, das ist eine ganz andere Datei. Die Versionnummer sollte in den Dateieigenschaften stehen. Wenn du aber nur eine MFC42.DLL hast, dann hat wohl irgendein Programm eine alte Version installiert. Um welches Betriebssystem handelt es sich, und welche Version der MFC42.DLL hast du?

Du hast möglicherweise mehr als eine MFC42.DLL auf dem Rechner, mit unterschiedlichen Versionen. Such mal nach Dateien mit diesem Namen, und benenne alle, bis auf die mit der höchsten Versionnummer, in MFC42.BAK oder etwas ähnliches um.

--> Verschoben: Delphi/VB/VBS/AS 400/C#/.net/Sonstige

Gerade wenn es für dich so eilig ist, solltest du einen Threadtitel wählen, der dein Problem genauer beschreibt. Ich habe das mal für dich nachgeholt.

Dieser Quellcode funktioniert völlig unabhängig vom Inhalt des Arrays. Wenn du Probleme mit Leerzeichen hast, liegt der Grund dafür an anderer Stelle. Da müsstest du schon den Rest deines Codes zeigen.

Es gibt popen (bzw. _popen unter Windows), damit geht das. Das ist allerdings kein Standard-C/C++. Hier gibt es einen Thread, der sich damit beschäftigt.

char Test[100]; // schreiben ofstream schreiben( "test.txt", ios::binary ); schreiben.write( Test, sizeof( Test ) ); schreiben.close(); // lesen ifstream lesen( "test.txt", ios::binary ); lesen.read( Test, sizeof( Test ) ); lesen.close();[/CODE]