Klotzkopp

Du meinst, im Socket.Accept()? Jedenfalls sollte ein Close aus dem anderen Thread ausreichen, damit Accept zurückkommt.

Hat dein List Control den Report-Style? Dann musst du zuerst mit InsertColumn Spalten einfügen. Was gibt InsertItem denn zurück?

Sicher? Ich habe es bei MSVC 6 und 7 vor/neben dem Tree Control. Sehr wahrscheinlich an letzterem, weil in der Resourcedatei immer noch eine Listbox steht.

- GetFileVersionInfoSize - GetFileVersionInfo - VerQueryValue

Doch, man muss nur vorher auf den "Aufklapp"-Button klicken.

Warum?

@Tapeman: Erstellst du den Dialog bzw. die FormView, die die ComboBox enthält, mit dem Resourceneditor in MSVC? Dann musst du womöglich nur die Fensterhöhe vergrößern.

Ist der Parameter pScrollBar bei den Doppelaufrufen jeweils derselbe?

Passiert das auch, wenn du die ScrollWindow-Aufrufe auskommentierst? Wie sieht die MessageMap aus?

Werden vielleicht beide Funktionen aufgerufen, wenn du eine Scrollbar betätigst? P.S.: Du solltest bei HScroll die Breite und bei VScroll die Höhe des Bildes nehmen, nicht andersrum.

Die aktuelle Version des Dependency Walkers hat eine "Undecorate C++ Functions"-Funktion. Gibt's auch hier: http://www.dependencywalker.com/

mprz ist anscheinend eine CString-Membervariable, die mit dem Eingabefeld verknüpft ist. Das Problem ist hier nicht, dass mprz oder die Information im Eingabefeld nicht aktualisiert wird, sondern dass zwischen den Aktualisierungen das Fenster nicht neu gezeichnet wird. Das liegt daran, dass OnOK letztendlich aus derselben Nachrichtenschleife heraus aufgerufen wird, die auch für die Bearbeitung der "Neu Zeichnen"-Nachricht verantwortlich ist. Dadurch wird erst neu gezeichnet, wenn OnOK zurückkehrt. Da ist aber die Schleife schon durchgelaufen und der Dialog geschlossen. Es gibt Wege, ein Neuzeichnen unter Umgehung der Nachrichtenschleife zu erzwingen, allerdings sehe ich hier den Sinn nicht. Was soll es bringen, ein Eingabefeld im Dialog von 0 auf 100 % hochzuzählen, um dann anschließend den Dialog zu schließen? Willst du so tun, also würde da tatsächlich eine Verarbeitung stattfinden?

Du solltest AssertValid nicht direkt aufrufen, sondern das Makro ASSERT_VALID benutzen, das wird für Release-Builds nicht ausgewertet. Die Release-Version ist durch die fehlenden Debuginformationen und die Optmierungen praktisch immer kleiner als die Debug-Version. Ob etwas fehlt, lässt sich also nicht allein an der Größe festmachen. Wenn statische Bibliotheken fehlen würde, würde sich allerdings der Linker beschweren. Jetzt sprichst du vermutlich von den dynamischen Bibliotheken. Die MFC-Bibliotheken und die C-Runtime sollten zumindest für MSVC6 auf jedem halbwegs modernen Windows-System vorhanden sein. Die Abhängigkeiten deines Programms kannst du z.B. mit Depends prüfen, das beim Visual Studio dabei ist, aber auch kostenlos runtergeladen werden kann.

http://www.werbesongliste.de/e/

Ganz grob: Debug: - enthält Symbolinformationen zum Debuggen - nicht optimiert - Assertions aktiv - Runtime-Checks aktiv Release: - enthält keine Symbolinformationen - optimiert (Größe, Geschwindigkeit) - Assertions entfernt - Runtime-Checks deaktiviert Das ist aber alles eine Frage der Projekteinstellungen. Man kann auch eine optimierte Version mit Debuginformationen erstellen. Veröffentlichen solltest du nur Release-Versionen. Bei MFC bist du dazu sogar praktisch gezwungen, weil du die Debug-Versionen der MFC nicht weitergeben darfst.

In der Funktion fehlt der Faktor 4 aus der Formel.

0x0600? Du hast schon Longhorn? Zum eigentlichen Problem: Es ist nicht gut, wenn der Wert dieses #define nicht für das ganze Projekt gleich ist. Am besten setzt du den Wert in den Projekteinstellungen. Was der Wert bedeutet, kannst du hier nachlesen.

Aus commctrl.h: #if (_WIN32_WINNT >= 0x0501) #define PBS_MARQUEE 0x08

Wenn du 1/i rechnest, macht der Compiler eine Ganzzahldivision, weil Zähler und Nenner beide ganzzahlig sind (i ist ein int, das Stringliteral 1 auch). Dabei werden Nachkommastellen abgeschnitten. Damit kommt (für i > 1) immer Null raus. Wenn du eine Fließkommadivision willst, muss einer der Operanden ein Fließkommatyp sein. Das geht in deinem Fall am einfachsten, indem du statt 1 1.0 schreibst.

Hier gibt es im letzten Drittel ein Beispiel für eine Mehrfachauswahl. Das ist übrigens der erste Link, den man findet, wenn man "PAP Mehrfachauswahl" bei Google eingibt.

Es muss nicht daran liegen, aber es ist auf jeden Fall ein Fehler: Wenn du in einer Schleife von 0 bis Anzahl-1 durch deine Listbox gehst und immer einen Eintrag entfernst, vergisst du dabei, dass durch das Entfernen die darunter liegenden Einträge nach oben rutschen. Du bearbeitest also nur jeden zweiten Eintrag, und greifst noch dazu nach der Hälfte der Durchläufe mit ungültigen Indices auf die Listbox zu. Da du den Rückgabewert von GetText nicht abprüfst, bekommst du das nicht mal mit. Was dann im weiteren passiert, ist nicht vorauszusagen. Also: Entweder immer mit Index 0 zugreifen, oder von hinten anfangen.

Die Schleife wird ausgeführt, solange (nicht bis) die Bedingung wahr ist: for (x=0;x<=3;++x) for (y=0;y<=16;++y) [/CODE] @Nokinger: Wenn es egal ist, ob man Prä- oder Postinkrement verwendet, sollte man sich Präinkrement angwöhnen.

Welchen Wert gibt RegQueryValueEx bei diesem Code zurück? Doch, das stand doch in dem MSDN-Auszug oben. Wenn der Puffer nicht groß genug ist, schreibt RegQueryValueEx die benötigte Puffergröße in die Variable, auf die lpcbData zeigt. Das ist in deinem Fall EncLaenge. Also: Was steht nach dem Aufruf in EncLaenge?

Was liefert 0? Der Aufruf von RegQueryValueEx? Dann hat's doch geklappt. Du bist mit deinen Überlegungen auf dem Holzweg. Die Funktion kann die Größe des Puffers nicht aus dem Zeiger selbst entnehmen, sondern nur aus dem Wert, den du in EncLaenge übergibst. Wenn die Funktion mit ERROR_MORE_DATA zurückkommt, dann ist der Wert in EncLaenge zu klein. Wenn der wirklich 4 ist, dann ist auch der Puffer zu klein. Zeig doch bitte mal den aktuellen Code.

Thread geschlossen. Siehe CWs Link.