Klotzkopp

Ich vermute, dass es das nicht ist. Ich weiß nicht, ob ClearCommError für den Fall, dass gar kein Fehler aufgetreten ist, überhaupt etwas sinnvolles tut. Dazu kommt, dass du den DCB gar nicht auf Abbruch im Fehlerfall eingestellt hast. Welche Funktion schlägt denn genau fehl, und was liefert GetLastError? Und warum pollst du überhaupt? Auf Multitaskingbetriebssystemen ist Polling meist die schlechtere Wahl. Warte doch einfach mit ReadFile, und klemm deinen eigenen Puffer dahinter.

Ohne an den Eigenschaften etwas zu ändern? Welchen Effekt soll das haben?

Eine Antwort auf diese Frage bekommst du eher im passenden Forum. Ein aussagekräftigerer Threadtitel hätte auch geholfen. Verschoben -> Skript- und Webserverprogrammierung

Was heißt denn für dich "am besten"? Und welche Abhängigkeit soll die Variable beschreiben? Dauer, Frequenz, Lautstärke?

Na, das allein hat sicher nicht den gewünschten Effekt

Hat jemand die natürlichen Zahlen umdefiniert, und ich hab's nicht gemerkt? :floet:

itoa ist nicht portabel, weil es nicht Bestandteil des Standards ist.

So eine Frage bringt dich nicht weiter. Stell die eigentliche Frage. Wenn jemand mit Ja antwortet, wirst du es sowieso tun müssen. Und mit Nein kann niemand antworten, weil hier niemand für alle sprechen kann

Das sollte nur davon abhängen, wo du speicherst. Statt OpenText AppendText benutzen.

:confused: Nein, die bekommst du mit RegEnumKey.

RegEnumValue

Die Frage ist doch, warum das Programm überhaupt die Formatierungen annimmt, wenn es nur unformatierten Text verarbeiten soll. Wie sehen diese Formatangaben denn aus? RTF? Zeig mal ein Beispiel.

Wie und wohin wird denn "eingegeben"?

http://forum.fachinformatiker.de/basic/97915-fragen-fernando.html

Mit ShellExecute geht das meines Wissens nicht. Dazu brauchst du CreateProcess.

Gar nicht. Steht auch in der MSDN Library. Da steht übrigens auch, dass du SEE_MASK_NOCLOSEPROCESS benutzen musst, damit du überhaupt ein Handle bekommst. Da steht doch: Size of the structure, in bytes. Also sizeof(SHELLEXECUTEINFO).

Solltest du nicht inzwischen in der Lage sein, so ein grundlegendes Problem mit Hilfe der Doku und der Fehlermeldung selbst zu lösen :confused: ShellExecuteEx will einen Zeiger auf eine SHELLEXECUTEINFO-Struktur. Das steht in der MSDN Library, und die Fehlermeldung sagt es auch nochmal. Du musst aber auch alle relevanten Member der Struktur mit Werten füllen. fMask, cbSize und lpVerb sind das mindeste. Alles, was du nicht brauchst, solltest du mit 0 initialisieren. Am besten setzt du gleich beim Anlegen alles auf 0: SHELLEXECUTEINFO App = {0};

Wenn du ShellExecuteEx benutzt, kommst du an ein Prozesshandle, auf das du mit WaitForSingleObject warten kannst.

Laut Standard sollte das eigentlich erlaubt sein, vermutlich eine Eigenart des CE-Compilers. Wenn du in einer namenlosen struct/class Member hast, die einen Standardkonstruktor haben (wie z.B. std::string), dann ist dieser Compiler offenbar nicht in der Lage, einen Kontruktor für diese struct/class zu erstellen, vermutlich, weil der dann (genau wie die struct) keinen Namen hätte. Gib dem struct-Typ einen Namen, dann sollte es gehen.

Nein, ich kenne das Ding gar nicht. Ich habe es mit Google gefunden, und es sah vielversprechend aus.

Schau mal hier rein: Downloads - WakeupOnStandBy

Eine Membervariable aus eine Methode heraus an eine freie Funktion zu übergeben, ist kontrolliert. Ich halte es im Gegenteil eher für ein Designproblem, wenn man private-Member und dazu jeweils einen public-Getter und Setter hat. Damit gibt nämlich das Interface der Klasse den internen Aufbau wieder, den man ja eigentlich kapseln wollte. Wenn dann noch die Settermethode nichts weiter tut, als den Member zuzuweisen, dann hätte man das sich auch sparen, und den Member public machen können. Und was das Zwischenobjekt angeht, das du ansprichst: Wenn du nichts weiter tust, als hinterher die Änderungen am Zwischenobjekt ungeprüft in dein eigentliches Objekt zu übernehmen, hast du auch nichts gewonnen, sondern nur zwei unnötige Kopieroperationen hinzugefügt. Leider sieht man diese Getter-"Lösung" sehr häufig. Ich vermute, das wird durch folgende Herangehensweise verursacht: - Problem: Ich brauche in Funktion Foo den Member X von Klasse A. - Member X ist private -> public Getter für X in A erzeugt. - Nächstes Problem: Ich brauche in Foo ein A, sonst bekomme ich kein X. Das führt dann zu dem häufigen Fehler, dass einfach in Foo ein neues A-Objekt erstellt wird, und dessen X geholt wird. Womöglich ist das passende A-Objekt Member einer anderen Klasse, also wird noch ein public Getter in der enthaltenen Klasse erstellt. Und so weiter. Wenn man statt dessen den benötigten Member einfach an Foo übergibt, statt ihn dort mühselig zu holen, ergibt das IMHO ein viel besseres Design, nicht zuletzt deswegen, weil es ohne zusätzliche Getter auskommt, die das Klasseninterface verschandeln und letztendlich das Interface von der Implementierung abhängig machen. Ein weitere Vorteil: Foo könnte theoretisch auch mit anderen X-Objekten arbeiten, die anderswo liegen. Foo ist nicht an X gebunden, und X auch nicht an seinen Member A. Um es kurz zu machen: Ich finde den Ansatz von Alex747 viel besser, als die leider so verbreiteten Getter und Setter für jeden Member. Ich habe schon Entwickler gesehen, für die das Anlegen dieser Methoden fast schon ein Reflex geworden ist: wann immer sie einen private Member anlegen, kommen diese Methoden gleich dazu. Daraus kann ich nur schließen, dass derjenige sich vorher nicht genügend Gedanken über das Interface der Klasse gemacht hat, denn das soll ja eigentlich den internen Aufbau abstrahieren, nicht wiedergeben.

Das ist Unsinn. Der Zugriff einer Funktion auf ihre Parameter hat nichts damit zu tun, ob die Eingangswerte der Funktionsparameter irgendwo Member sind. @Alex747: Das Problem rührt daher, dass CComboBox keinen Copykonstruktor hat. Der würde aber benötigt: Parameter die "by value" übergeben werden, werden für den Funktionaufruf kopiert. Selbst wenn CComboBox einen Copykonstruktor hätte, würde dir das also nicht helfen, weil du in der Funktion nur die Kopie verändern würdest, das Original bleibt, wie es ist. Die Lösung ist, den Parameter zu einer Referenz zu machen: void ElementAusgeben(CComboBox& cbox);

CScrollBar ist eine MFC-Klasse um ein ganz gewöhnliches Windows-Steuerelement. Kein ActiveX oder Plug-in. Was immer das Problem ist, es liegt nicht an CScrollBar.

Nein. *Bitte* genauer lesen. Wenn jemand das tut, ist es oft zu den üblichen Gerüchten nicht weit. Glaube mir, dass ich so etwas schon mehr als einmal gesehen habe. Mein Hinweis war, wie ich bereits geschrieben habe, eine reine Vorsichtsmaßnahme. Genau das hast du aber getan. Du hast ohne Argumente und in Unkenntnis der Projektanforderungen von den MFC abgeraten. Das hat aber nichts mehr mit dem Thema des Threads zu tun. Wenn diesbezüglich noch Klärungsbedarf besteht, bitte per PN