Klotzkopp

In C# hat die Klasse System.Threading.Thread zwei statische Sleep-Methoden. Also z.B. System.Threading.Thread.Sleep( 500 );

Die MFC beinhalten AFAIK keine Clipboard-Unterstützung. Hier steht alles: http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/dataexchange/clipboard.asp

Drum: Dahin verschoben, wo es hingehört.

Laut MSDN können pTo und pFrom mehrere nullterminierte Namen enthalten. Das Ende muss daher mit zwei Nullzeichen markiert werden. Mit strcpy geht das grundsätzlich nicht, weil es beim ersten Nullzeichen aufhört zu kopieren. Hier sollte es aber ausreichen, wenn du dein Array mit Nullen initialisierst: char test[100] = {0}; Das hier: Op.pTo="c:\\test2.bmp"; müsste eigentlich so aussehen: Op.pTo="c:\\test2.bmp\0";

Du kannst ein EventLog mit der Funktion ClearEventLog löschen. Das dafür benötigte Handle bekommst du von OpenEventLog. Du musst dein Programm mit Advapi32.lib linken, damit du die Funktionen nutzen kannst. P.S.: --> Verschoben nach: C++: Compiler, IDEs, APIs

#define bewirkt ähnlich wie #include eine Textersetzung, allerdings nicht an der Stelle, an der die Präprozessordirektive selbst steht, sondern an jeder Stelle im folgenden Code, an der das definierte Symbol gefunden wird. Beispiel #define COMPILETIMECONSTANT 25 // ... viel später if( q == COMPILETIMECONSTANT ) { Hier wird, bevor der Compiler den Quellcode überhaupt zu Gesicht bekommt, der Text COMPILETIMECONSTANT durch 25 ersetzt. Man kann bei #defines auch noch Parameter angeben, das sieht dann aus wie das Makro hier. Die Direktiven #if #elif #else #endif bieten die Möglichkeit der bedingten Kompilierung. Der Ausdruck nach #if wird geprüft, und falls er logisch wahr (also von Null verschieden) ist, wird der nachfolgende Codeblock in die Kompilierung einbezogen, ansonsten nicht. Mit #elif kann man eine weitere Bedingung prüfen, mit #else die "restlichen" Fälle abdecken. #endif schließt einen solchen bedingten Kompilierungsblock ab. #ifdef SYMBOL ist eine Kurzschreibweise für #if defined SYMBOL, und ist wahr, wenn irgendwo vorher im Code ein #define SYMBOL stand. #ifndef SYMBOL ist kurz für if !defined SYMBOL, hier ist es genau andersrum. Eine häufige Anwendung für diese Direktiven sind die sogenannten #include-Guards. Es kann kommt schon mal vor, dass Headerdateien andere Headerdateien per #include einbinden müssen. Um nun zu verhindern, dass derselbe Header-code mehrfach eingebunden wird (was bei gegenseitigen #includes zu Endlosschleifen führen kann), verwendet man für jede Headerdatei ein eindeutiges Symbol. Falls dieses Symbol am Anfang der Headerdatei noch nicht definiert ist, wird es definiert, und der Code der Datei normal behandelt. Falls es bereits definiert ist, wird der gesamte Code bis zum abschließenden #endif ignoriert: #ifndef MY_HEADER_FILE_INCLUDED #define MY_HEADER_FILE_INCLUDED // ... viele Deklarationen #endif Die durchgängige Großschreibung der definierten Symbole ist nicht zwingend, sondern nur üblich, um sie besser erkennen zu können. Man darf übrigens keine Symbole selbst definieren, die mit einem Unterstrich beginnen oder zwei Unterstriche hintereinander enthalten. Solche Namen sind für die interne Nutzung durch den Compiler reserviert.

Du kannst über die Nachricht WM_DEVICECHANGE mitbekommen, wenn sich der Zustand des Laufwerks ändert (wahrscheinlich aber nur, wenn ein lesbarer Datenträger drin liegt). Das schließt aber keine Änderungen ein, die passiert sind, bevor dein Programm gestartet wurde, d.h. du kannst damit nicht herausfinden, ob das CD-Laufwerk leer oder offen ist.

GetMenuState liefert nicht nur die Information, ob der Menüeintrag "gecheckt" ist oder nicht, sondern eine Vielzahl von Daten. Du musst die für dich relevanten Information erst herausfiltern, bevor du auf Gleichheit prüfst: if( ( menu.GetMenuState( ID_ITEM, MF_BYPOSITION ) & ( MF_CHECKED | MF_UNCHECKED ) ) == MF_UNCHECKED ) Das & bedeutet, dass du aus dem Rückgabewert von GetMenuState alles ausblendest, was nicht MF_CHECKED oder MF_UNCHECKED ist. Da MF_UNCHECKED 0 ist, geht auch folgendes: if( !( menu.GetMenuState( ID_ITEM, MF_BYPOSITION ) & MF_CHECKED ) ) Aber die erste Version ist "sauberer", zumal MS zumindest theoretisch die Werte der Konstanten ändern könnte.

Man kann die DDKs nicht runterladen. Entweder man bekommt sie im Rahmen einer MSDN Subscription, oder man lässt sich die CD gegen Erstattung der Frachtkosten zuschicken. Ältere DDKs sind nur über eine MSDN Subscription erhältlich.

Schau dir mal CMenu::GetMenuState an.

Genau damit habe ich es gemacht. Was findest du denn nicht?

Alle MFC-Anwendungstypen (Dialog, SDI, MDI) sind bei VC7 unter dem Projekttyp "MFC Application" zusammengefasst. In dem nachfolgenden Wizard kannst du unter "Application Type" auswählen, welchen Typ du erstellen willst.

Achtung, die Ausführungsreihenfolge der Initialisierungen hängt von der Reihenfolge in der Klassendeklaration ab, nicht von der Reihenfolge in der Initialisierungsliste.

Schau es dir nochmal genau an. Bei "runter" wird das Element zurückgeben, das zuletzt "drauf"getan wurde. Wie nennst du denn etwas, von dem du immer das Element zuerst runterholen musst, das du als letztes draufgepackt hast? Ein Tipp: Das andere Ding, bei dem du das Element zuerst rausliest, das auch zuerst reingekommen ist, nennt sich "Schlange" (Kasse, nicht Reptil) oder "Queue" Nachtrag: Mift[tm], nic_power hat's verraten

Das ist so nicht ganz richt. Das Schlüsselwort inline ist nur eine Empfehlung für den Compiler, und nicht zwingend. Die meisten modernen Compiler wissen besser als der Programmierer, wo das Inlinen sich lohnt, und wo nicht. IMHO sollte man inline nur dann verwenden, wenn durch Profiling nachgewiesen wurde, dass es etwas bringt. Manche Compiler bieten aber auch Möglichkeiten, das Inlinen zu erzwingen, z.B. mit __forceinline bei MSVC++.

if( wert ) tut's auch schon.

Vorschlag: #include <stdio.h> int main() { int dez,i = 98; char buf[100]; buf[99] = '\0'; printf("\nBitte geben Sie eine Zahl ein:"); scanf("%d",&dez); while( dez ) { buf[i--] = (dez & 1) ? '1' : '0'; dez >>= 1; } printf("%s\n", buf + i + 1 ); }[/CODE]

http://fachinformatiker-world.de/forums/showthread.php?s=&threadid=26288

Für den User macht das keinen Unterschied. Die beiden Ansätze erfordern grundverschiedene Vorgehensweisen auf der Seite des Entwicklers, und der zweite (Excel fernsteuern) läuft verständlicherweise nur unter Windows, mit installiertem Excel. Dann ist es Quatsch, dafür Excel-Dateien anzulegen, das ist viel zu aufwendig. Das würde ich wirklich nur dann machen, wenn die Dateien auch ohne dein Programm, eben mit Excel, gelesen werden können sollen. Ansonsten kannst du dir da was eigenes basteln, das ist erheblich einfacher. Wie das genau gehen kann, hängt von den Daten ab, die du speichern willst.

Willst du selbst mit xls-Dateien hantieren, oder willst du Excel so fernsteuern, dass es das selbst tut?

Ich hab mein XP jetzt bestimmt schon ein Dutzend mal über das Internet aktiviert (bin ein notorischer OS-Zerschießer). Bisher war kein Griff zum Telefon notwendig.

Du kannst UpdateData nicht aus einem anderen Threadkontext als dem GUI-Thread des Dialogs aufrufen. Falls es möglich ist, solltest du auf UpdateData komplett verzichten, zumindest im Zusammenhang mit Value-Variablen (Steuerlement-Variablen sind unkritisch). Die Funktion macht praktisch immer mehr als nötig, und sie erschwert die Kontrolle über die Variablen, die die Dialoginhalte speichern. In diesem konkreten Fall könntest du den UpdateData-Aufruf durch einen oder mehrere "konventionelle" Aufrufe ersetzen. Wenn es zum Beispiel darum geht, den Inhalt eines Eingabefeldes zu setzen, kannst du das z.B. so machen: GetDlgItem( IDC_WASAUCHIMMER )->SetWindowText( "Neuer Text" ); Das geht auch aus einem anderen Thread heraus.

Genau so. int(*addfuncpointer)(int,int) = reinterpret_cast<int(*)(int,int)>( GetProcAddress( ... ) ); int x = addfuncpointer( 42, 42 );[/CODE]Ein typedef macht die ganze Sache besser lesbar.

DLLs haben nichts mit Standard-C/C++ zu tun, darum verschiebe ich dich mal dahin, wo du OnTopic bist. Aber zum Thema: Und das ist auch richtig so. DllMain wird aufgerufen, wenn sich ein Prozess mit der DLL verbindet, wenn der Prozess einen neuen Thread startet, wenn ein solcher Thread beendet wird, und wenn der Prozess sich von der DLL wieder trennt. Um diese Fälle zu unterscheiden, dient der zweite Parameter (bei dir ul_reason_for_call). Wenn deine DLL auf diese Ereignisse nicht reagieren muss, kannst du DllMain auch ganz weglassen. GetProcAddress ruft die angegebene Funktion nicht auf, sondern liefert dir einen (untypisierten) Funktionszeiger. Wenn du den Rückgabewert nicht benutzt (wie in deinem Beispiel), macht dieser Aufruf nichts. Übrigens muss es "int main" heißen.

--> Verschoben: C++: Compiler, IDEs, APIs