Klotzkopp

int nHoheTiefeBreite[200][200][500]; Hier ist keine Speicherklasse angegeben (auto, static, extern, register), also gilt der Default: auto. Auto-Variablen werden auf dem Stack angelegt.

Schreibs doch mal mit kleinem x - C ist da sehr empfindlich

Du solltest Deine Quellen prüfen, denn zumindest das ist schlichtweg falsch. Aber das hat nichts mehr mit dem Thema des Threads zu tun.

Woher stammt eigentlich das Gerücht, dass XP Home so viel schlechter sei als XP Prof? Der Vergleich mit Windows ME ist lächerlich. Die wirklich relevanten Unterschiede zwischen XP Home und XP Professional sind: - Man kann sich mit XP Home nicht an einer Domäne anmelden. - Der Webserver bei XP Home ist eine abgespeckte Version des IIS (auf dem z.B. ASP .net nicht ohne weiteres funktioniert). - Die Verwaltung der Benutzerrechte ist nicht so komplex (es gibt nur Administrator und "eingeschränkt" ). Aber um den Thread wieder auf sein Thema zurückzubringen, hab ich mich mal schlau gemacht: XP Home erstellt bei der Installation ein Adminstratorkonto, zunächst noch ohne Passwort. Allerdings kann man sich nur im abgesicherten Modus als Administrator anmelden (dazu beim Start F8 drücken), und man kann auch nur dort dem Administratorkonto ein Passwort zuweisen.

Genau das vermute ich auch. Das sind immerhin über 19 MByte.

Das gilt für XP Professional. Hier geht es um XP Home.

Kleine Anmerkung: Von Microsoft gibt es das kostenlose Platform SDK (Software Development Kit). Darin (genauer gesagt im Core SDK) gibt es eine psapi.h und psapi.lib. Damit erspart man sich das Laden der DLL zur Laufzeit.

http://www.intel.com/support/netport/vintage/

@Gnut: In diesem Fall sollte es dies tun: #include <iostream> using namespace std; @Moon-Dog: Was genau meinst Du mit ersetzen? Willst Du nur die Bildschirmausgabe ändern, oder die Datei? Dein Programm hat einen logischen Fehler: Wenn die Datei das gesuchte Wort gerade an einem Tausenderübergang enthält, dann findet Dein Programm das Wort nicht. Du hast Jehova gesagt, zieh Dich warm an .

Wenn ich mich richtig erinnere, ist es in VB möglich, Arrays von Steuerelementen anzulegen, so dass man mit einer Schleife auf die Steuerelemente zugreifen kann. Abgesehen davon, dass ich es für schlechtes GUI-Design halte, wenn man so viele gleichartige Steuerelemente hat, dass eine Schleife zur Verarbeitung notwendig ist , gibt es so etwas nicht für VC++. VC++ vergibt ja zunächst einmal nur diese IDC_-Symbole für Steuerelemente. Diese Resource-IDs sind nichts weiter als #defines, die Zahlenwerte repräsentieren. Die #defines stehen übrigens in der Datei resource.h. Leider kann man sich nicht darauf verlassen, dass die Zahlenwerte dieser Resource-IDs aufeinanderfolgende Werte haben. Man kann die Werte zwar dementsprechend anpassen, aber der dabei produzierte Code ist sehr schwer zu warten. Eine Möglichkeit wäre, mit einem Array von Zeigern auf die Steuerlementklassen der MFC zu arbeiten, und über diese Zeiger auf die Steuerelemente zuzugreifen: CButton* paButtons[8]; paButton[0] = (CButton*) GetDlgItem( IDC_BUTTON_1 ); paButton[1] = (CButton*) GetDlgItem( IDC_BUTTON_2 ); paButton[2] = (CButton*) GetDlgItem( IDC_BUTTON_3 ); ...[/CODE] Eine andere wäre, eine Hilfsfunktion zu schreiben, die aus dem "Index" die Resource-ID ermittelt: [CODE]UINT ResIdVomIndex( int nIndex ) { switch( nIndex ) { case 0: return IDC_BUTTON_1; case 1: return IDC_BUTTON_2 // ... }Wirklich schön ist das aber alles nicht...

Windows schottet derart hardwarenahe Ereignisse durch Abstraktionsschichten vom Benutzer bzw. Programmierer ab. Selbst wenn man dieses Ereigniss abfangen könnte, würde kein Callback-Automatismus bereitgestellt werden. wasweißichs Tipp mit dem zweiten Thread dürfte die einfachste Lösung sein.

Du darfst trotzdem ein Betreff wählen, das das Problem zumindest ansatzweise beschreibt. Erhöht die Wahrscheinlichkeit kompetenter Antworten ungemein . Ich hol das mal für Dich nach...

Sowohl gugelhupfs als auch mein Code erzeugen bei mir (MSVC 6 SP5, XP Home SP1) das gewünschte Verhalten. Bist Du sicher, dass Du neu kompilierst bzw. das richtige Programm ausführst?

Wie schon gesagt, EnumProcesses. Ist aber nicht im Kernel, sondern in psapi.dll. Dafür gibts sogar .lib und .h, also brauchst Du nicht mal LoadLibrary .

Das ist wieder mal das Problem "cin und numerische Datentypen". Dadurch, dass Du cin eine numerische Variable übergibst, verbleiben die Zeichen, die cin nicht in Zahlen packen kann, für immer im Eingabepuffer. Du musst diese Zeichen zuerst entfernen: while(bElementSizeCorrect == false) { cout << "Input size (kB): "; cin >> nElementSize; if((nElementSize > 1) && (nElementSize < 64000)) { bElementSizeCorrect = true; }else{ cout << "Wrong Input (0-64000 kB)!" << endl; [COLOR=darkred][B]cin.clear(); cin.ignore( 2000, '\n' );[/B][/COLOR] } }[/CODE]2000 ist dabei ein willkürlicher Wert. Es geht nur darum, alle erfolgten Eingaben bis zum nächsten Linefeed zu verwerfen.

Da wird nichts gelöscht, sondern der Prozess wird als Dienst gekennzeichnet. Dienste werden im Taskmanager nicht aufgeführt. Bei der Verwendung dieses Codes ist übrigens Vorsicht angebracht. Ein als Dienst registrierter Prozess wird nicht beendet, wenn der Benutzer sich abmeldet.

Dann musst Du Dich mit EnumProcesses und den anderen psapi-Funktionen begnügen. Die gibt es auch für NT4.

Genau kenne ich mich mit Qt auch nicht aus, was ich Dir hier sage, habe ich mir zusammengegoogelt . Jedenfalls scheint moc eine cpp-Datei zu generieren, die Du dann wohl mitkompilieren musst: moc -o abx_moc.cpp abc.h Hier habe ich einige Infos dazu gefunden: http://vrlab.epfl.ch/~bhbn/qt_presentation/presentation.html#SECTION00041000000000000000

Hast Du den moc über die Form1-Headerdatei laufen lassen? Wovon ist Form1 abgeleitet?

moc hast Du wahrscheinlich ausgeführt, oder? Gib mal ein Codebeispiel für einen connect-Aufruf, und die dazugehörigen Klassendeklarationen.

Der Ansatz mit CFile ist ja schon mal nicht schlecht. Aber ist das, was Du oben angegeben hast, der aktuelle Code? Da interpretierst Du nämlich den CFile*, der als Cookie reinkommt, als CString*. Das wird nicht funktionieren. Wo und wann schließt Du das CFile-Objekt? Wirft Write vielleicht eine Exception?

Hallo und willkommen auf dem Board Erstmal schieb ich Dich dahin, wo Du OnTopic bist, denn mit Standard-C/C++ hat CRichEditCtrl und der Rest der MFC nicht mehr viel zu tun Aber zum Thema: Hast Du mal geprüft, ob in den Daten, die in Deiner Callback-Funktion aufschlagen, Nullbytes auftauchen? Die dürften Dir die Behandlung mit Strings erschweren.

Es gibt zwei sogenannte Dateizeiger, einen zum Lesen und einen zum Schreiben. Durch diese beiden wird festgelegt, an welcher Stelle der Datei der nächste Lese- bzw. Schreibzugriff erfolgt. tellg liefert die aktuelle Position des Lese-Dateizeigers (g für get, p für put), und da wir den vorher mit seekg auf das Dateiende gesetzt haben...

Es gibt meines Wissen keine Funktion, um bei fstream die Dateigrößte direkt zu ermitteln. Aber Du kannst den get-Dateizeiger ans Ende setzen, und Dir die Position geben lassen: Lotto2.seekg( 0, ios::end ); long size = Lotto2.tellg(); Danach aber nicht vergessen, den Dateizeiger wieder auf den Anfang zu setzen: Lotto2.seekg( 0 );

Bestenfalls die gleiche Hardware , aber eigentlich nicht einmal das, weil Microsoft AFAIK die Mac-Adresse der Netzwerkkarte für den Hardware-Hash verwendet. Und die sollte ja bei jeder Netzwerkkarte eine andere sein.