Alle Beiträge von Klotzkopp
-
Probleme mit CRecordset::GetFieldValue
Wie ist denn der genaue Wortlaut der Exception? Gibt es vielleicht im Trace-Fenster genauere Informationen, wenn du das Programm im Debugger ausführst?
-
Probleme mit CRecordset::GetFieldValue
In der MSDN steht, dass GetFieldValue zwei Arten von Ausnahmen werfen kann: CDBException* und CMemoryException*. Ich tippe auf ersteres. Fang die Ausnahme auf, dann kannst du weitere Informationen rausholen: try { // Dein Aufruf } catch( CDBException* pEx ) { CString strMsg; strMsg.Format( "%d\n%s\n%s", pEx->m_nRetCode, pEx->m_strError, pEx->m_strStateNativeOrigin ); MessageBox( strMsg ); }[/CODE]
-
Shell Werbung
http://www.konsumterror.de/werbesongs/a.shtml Unter "Axe"
-
Probleme mit CRecordset::GetFieldValue
Du übergibst einen Zeiger, die Funktion erwartet aber eine Referenz. Mach das & weg.
-
Treiberprogrammierung unter XP
Für die Treiberprogrammierung unter Windows brauchst du das DDK. Darin enthalten ist eine umfangreiche Dokumentation und jede Menge Beispiele. Zum Debuggen brauchst du einen kernelfähigen Debugger, z.B. WinDbg (kostenlos) oder SoftIce (nicht kostenlos). Das DDK kann man aber AFAIK nicht herunterladen, sondern sich nur (gegen Erstattung der Versandkosten) zuschicken lassen.
-
Kommunizieren über die COM-Ports unter DOS in C
Während ich deinen Thread ins richtige Forum verschiebe (Standard-C/C++ weiß nicht von seriellen Schnittstellen), könntest du verraten, welchen Compiler du benutzt. Wir können dir umso besser weiterhelfen, je mehr Informationen du lieferst, z.B. was du genau versucht hast, und was genau nicht funktioniert hat (Fehlermeldungen etc.):
-
MFC: CEvent und Threads
Wenn dein Dialog weiterhin Nachrichten bearbeiten soll, während du auf das Ende des Workerthread wartest, dann geht das so nicht. Du befindest dich ja gerade in der Behandlungsfunktion für eine Nachricht (die Click-Nachricht deines Cancel-Buttons). Da musst du erst wieder raus, bevor du weitere Nachrichten empfangen kannst. Der Workerthread könnte z.B. eine besondere Nachricht an den Dialog senden, wenn er fertig ist. Für diese Nachricht legst du dann im Dialog eine Behandlungsfunktion an. Wie das geht, steht in diesem Beitrag (nur die drei fettgedruckten Zeilen sind für dich interessant).
-
Outlook Express Spamm
Die Regeln stehen in der Registry: HKCU\Identities\{GUID}\Software\Microsoft\Outlook Express\5.0\Rules\ Einfacher ist es allerdings mit dem Outlook Express Backup Wizard. Hier gibt's auch eine kostenlose Testversion.
-
common dialogs
Hast du zufällig WIN32_LEAN_AND_MEAN definiert? Dann includiert windows.h nämlich commdlg.h nicht, das musst du dann selbst machen.
-
Timer in struct ?
Falsches Forum. Bitte beim nächsten Mal darauf achten. --> Verschoben: C++: Compiler, IDEs, APIs
-
MFC: CEvent und Threads
Du kannst z.B. direkt mit WaitForSingleObject auf das Threadhandle warten, du kannst aber auch in einer Schleife wiederholt GetExitCodeThread aufrufen. Damit die Schleife nicht den Prozessor blockiert, solltest du ein Sleep einbauen. Das bewirkt, dass der aktuelle Thread seine Zeitscheibe vorzeitig aufgibt und der nächste an die Reihe kommt.
-
Debugmeldung bei Laufzeitfehler deaktivieren (war: Nerviger Fehler!)
Hat nichts mit den Einstellungen des VS zu tun, sondern mit denen des IE. Bitte die Suchfunktion benutzen: Link Beim nächsten Mal bitte einen aussagekräftigeren Threadtitel wählen.
-
DatenTyp Variant für DLL
Hast du das mit dem Referenzparameter mal ausprobiert? Bei mir hat das mit Zahlen und Strings funktioniert. Und dein SQL-Statement sollte ja eigentlich für das Feld "Anzahl" eine Zahl liefern.
-
Neure Dll Version benötigt
Es gibt ein Winsock2-Update für Windows 95: http://www.microsoft.com/windows95/downloads/contents/WUAdminTools/S_WUNetworkingTools/W95Sockets2/Default.asp
-
Variablen in/aus .txt - datei speichern/lesen...
Das war sowieso Quatsch. Du meintest ja (wenn ich es jetzt richtig verstehe) Guybrush Threepwoods Hinweis auf fopen usw. Dann brauchst du #include <stdio.h> P.S.: Der genaue Wortlaut der Fehlermeldung ist immer besser als "das kennt er nicht"
-
Variablen in/aus .txt - datei speichern/lesen...
Nein, using ist ausschließlich C++, in C gibt's so etwas nicht. Es gibt using-Direktiven und using-Deklarationen. Das Beispiel hier ist eine using-Direktive. Alle Klassen der C++-Standardbibliothek befinden sich in einem namespace mit dem Namen std. Wenn man sie benutzen will, muss man also schreiben: std::string s( "huhu" ); std::cout << s << std::endl;[/CODE] (ohne Koenig-Lookup müsste man sogar den Namespace vor den operator<< setzen) Durch die using-Direktive werden aber die Inhalte des bezeichneten namespace in den globalen namespace gehoben, d.h. man kann ohne std:: darauf zugreifen. using-Deklarationen verwenden man in Klassendeklarationen, um den Zugriff auf überladene Methoden von Basisklassen zu ermöglichen.
-
DatenTyp Variant für DLL
Du sollst sie eben nicht als VARIANT definieren. Das ist ja der Trick bei der Sache. Der VARIANT wird nicht über den Rückgabewert, sondern über einen Referenzparameter an VB zurückgegeben. Um das zu demonstrieren, habe ich das Beispiel doch geschrieben. _variant_t ist eine Wrapperklasse für VARIANT, damit kann VB nichts anfangen. Aber was meinst du jetzt mit "Probleme"? Bekommst du eine Fehlermeldung?
-
DatenTyp Variant für DLL
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.
-
Variablen in/aus .txt - datei speichern/lesen...
#include <fstream> using namespace std;
-
DatenTyp Variant für DLL
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 );
-
DatenTyp Variant für DLL
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.
-
Shell Werbung
http://www.konsumterror.de/werbesongs/s.shtml Unter "Shell".
-
zweiter gui thread
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.
-
zweiter gui thread
--> 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.
-
Mehrfachauswahl im ListCtrl
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]