Klotzkopp

char* fill = "000000"; printf(" %s%s \n", pointer1, fill + strlen(pointer1));[/code] Du musst allerdings sicherstellen, dass der erste String niemals länger als 6 Zeichen wird.

DialogBox ist schon ganz richtig, wenn das Programm nicht weiterlaufen soll, bis der Benutzer etwas eingegeben hat. DialogBox hat einen Parameter für das Parent Window, dann gibst du den halt an. Du kannst natürlich alles so auf mehrere Quellcodedateien verteilen, wie du willst. Das hat mit WinAPI nichts zu tun, das ist in C und C++ ganz allgemein so. Statische Member müssen definiert werden -> C++-Grundlagen. Ganz ehrlich, wenn du in C++ nicht sattelfest bist (und den Eindruck machst du hier), solltest du dir eine einfachere Aufgabe suchen, als gerade einen OO-Wrapper um die WinAPI zu stricken.

Bitte beschreibe das beobachtete und das erwartete Verhalten, nicht deine Diagnose. Wenn das beim Filtern passiert, wird es wohl daran liegen, wie du filterst.

isalpha und isdigit aus <ctype.h>

Du solltest du darauf achten, dass der gekürtze Code dasselbe Fehlerverhalten zeigt. Dein Code lässt sich gar nicht erst compilieren, weil in WindowProc eine schließende geschweifte Klammer fehlt. Wenn ich diese und ein default-Label für die letzte Return-Anweisung ergänze, läuft das Programm so, wie es soll. Der Fehler steckt vermutlich in dem Code, den du weggelassen hast. Deine Einrückung ist übrigens abenteuerlich.

Es gibt ein paar einfache Regeln, um aus einem regulären Ausdruck einen nichtdeterministischen endlichen Automaten zu konstruieren, die finde ich nur grad nicht. Aus dem NEA kann man dann mit der üblichen Potenzmengenkonstruktion einen DEA machen, falls erforderlich.

Man muss wohl nicht mal den Pfad erzeugen: Phonon::MediaObject *music = Phonon::createPlayer(Phonon::MusicCategory, Phonon::MediaSource("/path/mysong.mp3")); music->play();[/code] Darum eine Wrapperfunktion drumherum zu basteln, sollte ja kein Problem darstellen.

Ich hab gerade mal ein wenig recherchiert. Ohne mich genauer einzulesen oder das auszuprobieren: Ich habe den Eindruck, dass mit Phonon die Wiedergabe einer Audiodatei ein Zweizeiler ist.

Du möchtest, dass der API-Anbieter für dein spezielles Detailproblem eine einfache Lösung entwickelt, testet und pflegt, weil du den Aufwand, es selbst zu tun, für zu hoch hältst? Siehst du, wo hier die Logik klemmt? Es gibt vermutlich tausende Detailprobleme wie deines. Da sollte es dich nicht wundern, wenn deines unter Umständen nicht so hoch auf der Prioriätenliste steht.

Nein. Einen weiteren Thread brauchst du, wenn während eines längeren Vorgangs dein GUI bedienbar bleiben soll. Threads sind auch nicht ganz einfach in der Handhabung. So dürfen neue Threads beispielsweise nicht so einfach auf Steuerelemente des GUI-Threads zugreifen. Benutz einen Timer. SetTimer function WM_TIMER message

FinalFantasy, du vermutest Scheuklappen bei anderen, hast aber selbst die größten Qt-Scheuklappen auf, die ich jemals gesehen habe. Mag sein, dass Qt alles kann, was du willst. Offensichtlich aber nicht so, wie du es willst. Du lobst dein Werkzeug als die Silberkugel für alle Probleme, beklagst dich aber gleichzeitig über dessen Unzulänglichkeiten. Einfache Lösungen für komplexe Probleme (und ja, die Wiedergabe einer Audiodatei ist ein komplexes Problem, kein einfaches) findest du in hochspezialisierten Frameworks, z.B. in Game Engines. Je allgemeiner und portabler ein Framework ist, je mehr Plattformen es unterstützt, desto eher findest du Lösungen, die eben nur auf dem kleinsten gemeinsamen Nenner aufbauen, und damit eben nicht so anwenderfreundlich sind, wie es dir vielleicht möglich erscheint.

Kommt drauf an, was gemacht werden soll. Bei einfachen Sachen würde ich zu einem Timer raten.

Gegenvorschlag: Jeder User möge bitte für sich entscheiden, ob er/sie den Thread für einen Troll hält oder nicht. Troll -> Nicht füttern Kein Troll -> Ernsthaft antworten. Eine Troll/kein Troll-Diskussion ist in keinem Fall hilfreich.

Beschreib doch mal grob, wie du das ohne Schleife machen würdest.

Ich vermute, die Aufgabe zielt darauf ab, dass du das Ans-Ende-Stellen und insbesondere das Vorrücken detailliert darstellst.

Es gibt kein "globales Senden". Windows schickt die Tastatur-Nachrichten immer nur an das Fenster, das den Fokus hat. Wenn so etwas wie DirectInput zum Einsatz kommt, das die Tastaturereignisse abgreift, bevor Windows sie verteilt, kommt es nicht dazu. Es gibt also keine "globalen" Tastaturereignisse, es kommt nur darauf an, auf welcher Ebene der Ereignisverarbeitung deine Simulation ansetzt. Die native-Funktion SendInput ist, soweit ich weiß, in der Lage, Tastatur- und Mausereignisse so zu erzeugen, dass sie auch von DirectX verarbeitet werden. SendInput function

Keine Ahnung, was du mit "global" meinst. SendKeys.Send Method Blockieren geht weit über Abhören und Simulieren hinaus. Wozu braucht man denn so etwas?

Nur scheinbar? Oder meinst du anscheinend? File Allocation Table

2 Clients können nicht dann kommunizieren, wenn die Subnetzmaske gleich ist, sondern wenn der Netz-Anteil der Adresse gleich ist. Die Subnetzmaske legt nur fest, welche Bits der Adress zum Netz-Teil gehören.

Subnetting hat das Ziel, dass Rechner in unterschiedlichen Subnetzen eben nicht kommunizieren können bzw. nur über einen Router. In deinem zweiten Beispiel können die Clients in Raum A frei mit denen in Raum B kommunizieren. Subnetting benutzt man, um das zu verhindern.

Hast du dir den Bespielcode, die Kommentare und den Text drumherum überhaupt mal genauer angesehen? Du musst den Texthintergrund und den Steuerelement-Hintergrund auf transparent setzen. Bisher setzt du nur den Texthintergrund, mit SetBkMode. Den Steuerelement-Hintergrund steuerst du über den Brush, den die Methode zurückgibt. Um es kurz zu machen: hbr = (HBRUSH)GetStockObject(HOLLOW_BRUSH); in den if-Block.

Dann hast du in OnCtlColor wohl einen weißen Brush zurückgegeben. Die Farbe legst du doch selbst fest.

CWnd::OnCtlColor

So macht man das nicht. Man setzt die Texthintergrundfarbe auf transparent und steuert die Hintergrundfarbe des Steuerlementes über den Rückgabewert der Methode, siehe Beispiel in der MSDN-Library.

Das sollte nicht sein. Wie hast du die Hintergrundfarbe denn geändert? Und nochmal die Frage: Sind diese ganzen grafischen Details wirklich Teil der Aufgabe, oder ist das nur Spielerei? Wenn du wirklich ein schickes GUI brauchst, solltest du das eher nicht mit MFC, sondern vielleicht mit WPF machen.