Klotzkopp

Du nimmst die Werte am Anfang, am Ende und in der Mitte, bringst sie in die richtige Reihenfolge (ggf. zwei Vertauschungen), und nimmst dann den mittleren der drei Werte als Pivot-Element.

Standard-C/C++ weiß nichts von Druckerports oder Dioden, drum: --> Thema verschoben.

Das Problem bei der Monte Carlo Methode ist, dass du keine Qualitätsaussage über deine Näherung angeben kannst. Da das aber wohl genau deine Aufgabe ist, versuchs doch mal mit dem der Methode von Archimedes (zu finden beim dritten Link in nic_powers Beitrag). Du berechnest die Umfänge der n-Ecke für immer größer werdende n. Durch die Differenz des Umfangs des äußeren und inneren n-Ecks kannst du die Genauigkeit deiner Näherung bestimmen. P.S.: Mein Mathelehrer sagte damals: "Archimedes trieb es bis 96"

Ein char ist nur ein einzelnes Zeichen, das wird dir nicht weiterhelfen. Verwendest du C oder C++? Wie liest du ein?

Wenn du die Eingabe gleich als Zahl einlesen lässt, ist es schwieriger, eine Fehleingabe überhaupt zu erkennen. Wenn du die Eingabe als Zeichenkette behandelst, kannst du jedes Zeichen darauf prüfen, ob es eine Ziffer ist, und entsprechend reagieren.

Mir ist kein solcher Fehler bekannt. Hast du die Möglichkeit, die Installation auf einem nativen Windows 98 SE-System zu testen?

Damit kann ich jetzt nicht viel anfangen. Wie äußert sich das? Auch hier: Wie äußert sich das? Fehlermeldung?

Soweit ich weiß, kannst du mit WM_CTLCOLORLISTBOX nur die gesamte Listbox färben, nicht einzelne Einträge. Du kannst auch nur die Farben setzen, die Listbox zeichnet sich immer noch selbst. Du wirst wohl den OwnerDraw-Style setzen und WM_DRAWITEM behandeln müssen.

*rotwerd* Nicht doch... Das TrackPopupMenu-Problem bei Trayicons ist angeblich ein Feature. Ich finde den KB-Artikel gerade nicht, aber hier steht etwas darüber, unter "NOTE on TrackPopupMenu": http://www.codeproject.com/shell/systemtray.asp

Setz mal ein PostMessage( WM_NULL ); hinter den Aufruf von TrackPopupMenu.

Wobei genau brauchst du Hilfe? Hast du schon einen Algorithmus ausgewählt? Meinst du mit "Näherungs 1" und "Näherungs 2" eine Ober- und Untergrenze oder zwei aufeinanderfolgende Werte einer Reihenentwicklung? Ein genereller Tip: Da der Genauigkeitsbereich der eingebauten Fließkommatypen kaum ausreichen wird, solltest du entweder eine Bibliothek für beliebig genau Zahlen verwenden (Stichwort: Arbitrary Precision), oder deine Näherung gleich als String speichern.

Das hier ist über Google - oder direkt bei CodeGuru - eigentlich leicht zu finden: http://www.codeguru.com/editctrl/ColorWeir.html

Die VK-Codes beziehen sich auf Tasten, nicht auf Zeichen. Man musste sich also für einen ASCII-Code entscheiden. Das ist VK_OEM_2, es kann also sein, dass ein anderer Tastaturtreiber einen anderen Wert für die #-Taste liefert. Kannst du nicht WM_CHAR abfangen? Da sollte im WPARAM der ASCII-Code drinstehen.

Es gibt keine #defines vür VK_A bis VK_Z. Stattdessen musst du 'A' bis 'Z' verwenden. Großbuchstaben :mod: 97 ist ein 'a' (Kleinbuchstabe -> anderer ASCII-Code).

Die VK_-#defines stehen in winuser.h. Da steht auch: /* VK_0 thru VK_9 are the same as ASCII '0' thru '9' (0x30 - 0x39) */ /* VK_A thru VK_Z are the same as ASCII 'A' thru 'Z' (0x41 - 0x5A) */

Weil IsDialogMessage die Nachricht nicht nur prüft, sondern gegebenenfalls auch verarbeitet: Because the IsDialogMessage function performs all necessary translating and dispatching of messages, a message processed by IsDialogMessage must not be passed to the TranslateMessage or DispatchMessage function.

Vielleicht hilft das: http://fachinformatiker-world.de/forums/showthread.php?s=&threadid=33624

@A-RAM: Dass das ganze nur funktionieren kann, wenn sizeof int == sizeof char, hat Crush ja schon geschrieben. Aber auch der Adressoperator vor szString ist in beiden Fällen falsch. Und wenn du statt int* (wieso eigentlich int*?) char* verwendest, sind auch die casts nicht mehr notwendig. @Crush: Die Klammern sind in diesem konkreten Fall nicht zwingend notwendig.

Da verwechselst du etwas. Die Reihenfolge der Funktionsargumente auf dem Stack (und selbst das ist ein Implementierungsdetail) hat mit der Reihenfolge, in der die Argumente ausgewertet werden, nichts zu tun. Da hat der Compiler völlig freie Hand. Das einzige, was sicher ist, ist, dass alle Argumente ausgewertet werden, bevor die Funktion aufgerufen wird.

lpCustColors Pointer to an array of 16 COLORREF values that contain red, green, blue (RGB) values for the custom color boxes in the dialog box. If the user modifies these colors, the system updates the array with the new RGB values. To preserve new custom colors between calls to the ChooseColor function, you should allocate static memory for the array. Da steht nicht, dass das NULL sein darf. Übrigens war meine Info falsch, den Array musst du immer mit angeben, nicht nur bei CC_FULLOPEN. lpCustColors, nicht lCustData

Wenn Du CC_FULLOPEN angibst, erwartet ChooseColor in cc.lpCustColors die Adresse eines Arrays von 16 COLORREFs.

Die gesuchte Funktion heißt "Replace".

Nicht nur das, denn hat nichts mit Standard-C++ zu tun, und mit C schon gar nichts. --> Thema verschoben. P.S.: GTs Lösung funktioniert trotzdem, wenn du vorher aus dem CString einen const char* machst. Da reicht eine einfache Zuweisung, weil CString dafür einen cast-Operator hat.

Ich habe den Eindruck, dass es hauptsächlich bei Weiterleitungsseiten auftaucht. @e@sy: Ist es hilfreich, wenn wir die jeweiligen Links, die zu den leeren Seiten führen, hier auflisten? Vielleich lässt sich da ein Muster erkennen. Bei mir ist es gerade jedenfalls passiert bei search.php?s=&action=getnew (XP Prof SP 1, IE6 SP 1)

Gar nichts. Timernachrichten sind für so etwas nicht geeignet. Das Problem rührt daher, dass deine Funktion als Reaktion auf eine Nachricht ausgeführt wird. Währenddessen laufen neue Nachrichten in der Messagequeue zur späteren Bearbeitung auf. Eine Eigenart der WM_TIMER-Nachricht ist aber, dass immer nur eine Nachricht pro Timer in deiner Queue steht. Wenn eine WM_TIMER für einen Timer reinkommt, für den schon eine Nachricht in der Queue steht, wird die neue (IIRC) Nachricht ignoriert. Außerdem werden Timernachrichten nur bearbeitet, wenn sonst gerade nichts zu tun ist. Verwende besser GetTickCount, einmal am Anfang und einmal am Ende, und rechne die Differenz aus.