Klotzkopp

Ich glaub ich hab's: Du erstellst ein zweites Bitmap-Objekt, in der gewünschten Größe und Farbtiefe. Dann erstellst du daraus ein Graphics-Objekt und malst die Quellbitmap in dieses Graphics-Objekt: int neuebreite = 500, neuehoehe = 500; Bitmap source( L"Datei.gif" ); Bitmap target( neuebreite, neuehoehe, PixelFormat32bppRGB ); Graphics g( &target ); g.DrawImage( &source, 0, 0, neuebreite, neuehoehe );[/CODE] Dann kannst du target speichern.

War ja auch nur ein Hinweis, kein Vorwurf

Du bist im falschen Forum: FAQ --> Verschoben nach C++: Compiler, IDEs, APIs.

Dieses Forum ist kein Programmierservice und auch keine Source-Suchmaschine. Wenn du versuchst, das Programm selbst zu schreiben, und auf Probleme stößt, helfen wir dir gern weiter.

Ja, entweder sie einigen sich (AVEN an Tagen mit ungeraden Datum, Chief an den anderen), oder sie löschen ihre Beiträge gegenseitig.

Ein Schreibfehler. Hab's geändert. Wenn es das ist, was du mit "Variable wechseln" meintest, ja. Aber die Funktion kann auch unvollständige Strings verarbeiten.

Ich hatte mal so was ähnliches: currentmsg ist ein std::string, msgqueue ist ein std::queue<std::string>. Beide müssen außerhalb der Funktion deklariert sein (z.B. als Instanzvariablen einer Klasse). Die Parameter der Funktion sind der Puffer, den recv gefüllt hat, und die Anzahl der empfangenen Bytes. void ProcessData(char *buffer, int size) { for( int i=0; i<size; ++i ) { if( buffer[i] == '\0' ) { msgqueue.push( currentmsg ); currentmsg = ""; continue; } currentmsg += buffer[i]; } }[/CODE] Die Queue kannst du dann z.B. mit einem anderen Thread abarbeiten. Dann solltest du aber die Zugriffe auf die Queue synchronisieren.

Soweit ich weiß, gibt es da keine Funktion. Entweder suchst du nach dem Nullzeichen weiter, falls noch nicht alle empfangenen Bytes verarbeitet wurden, oder du nimmst ein anderes Trennzeichen. Oder du entwickest ein eigenes "Protokoll", mit einem Header, in dem steht, wie lang der nachfolgende String ist. Dann brauchst du gar kein Trennzeichen mehr.

Prüf doch mal, ob die Anzahl der empfangenen Zeichen zur Anzahl der ausgegebenen Zeichen passt.

Indem du mehrfach send aufrufst? Ehrlich gesagt, ich verstehe nicht ganz, wo das Problem liegt. Kannst du das ein wenig ausführlicher erklären?

Was hast du gegen ++p? ANSI-C ist das auf jeden Fall. p ist ein Zeiger auf char, der am Anfang der Schleife auf das erste Element von cEingabe gesetzt wird. Der mittlere Ausdruck in der for-Klammer ist die Abbruchbedingung. Die Schleife endet, wenn dieser Ausdruck Null (oder false) wird. *p bedeutet hier einfach das Zeichen, auf das p gerade zeigt. Hier wird ausgenutzt, dass das Stringende durch ein Nullzeichen gekennzeichnet ist. Am Ende des Strings wird *p also Null, und die Schleife wird beendet.

Ich weiß nicht, ob es in ANSI-C eine Konvertierungsfunktion gibt. Du könntest aber natürlich auch die ASCII-Codes in deinen String eintragen: const char* ungueltig = "\x84\x94\x81\x8e\x99\x9a\xe1;:-=\\/"; Oder dreh das ganze um und prüfe mit einem String, der alle gültigen Zeichen enthält.

Ich vermute mal, dass dein Quellcode in ANSI codiert ist (hängt vom Editor ab), und die Eingabe in ASCII erfolgt. Und da ist der Code für 'ä' leider nicht derselbe. Du kannst das ausprobieren, indem du mal den String mit den ungültigen Zeichen ausgeben lässt.

Das break bedeutet nur, dass die Schleife vorzeitig verlassen wird - es macht ja keinen Sinn, nach weiteren ungültigen Zeichen zu suchen. Das Programm läuft danach normal weiter. Du musst also nach der Schleife prüfen, was weiter geschehen soll. Das kann man machen, indem man das Auftreten des Fehlerfalls in einer bool-Variablen ablegt: bool nameInOrdnung = true; for( char* p = cName; *p; ++p ) { if( strchr( ungueltig, *p ) ) { printf("\nDer Name darf keine Umlaute enthalten!"); nameInOrdnung = false; break; } } if( nameInOrdnung ) { // weitere Verarbeitung...[/CODE]

Ich hab's gerade mal ausprobiert: Ein Datenbankprojekt ist ein Projekt, mit dem eine Datenbank über die ODBC-Schnittstelle verwaltet werden kann. Visual Studio kann dann als Frontend benutzt werden (z.B. wenn man keinen Enterprise Manager / Query Analyzer verwendet). Mit dem Datenbank-Assistenten scheint man eine neue SQL-Server-Datenbank anlegen zu können. Das funktioniert aber bei mir irgendwie nicht.

Es ist wahrscheinlich einfacher, wenn du alle ungültigen Zeichen in einen String packst, und danach jedes Zeichen im Eingabestring daraufhin untersuchst, ob es im String der ungültigen Zeichen auftaucht: const char* ungueltig = "äöüÄÖÜß;:-=\\/"; for( char* p = cEingabe; *p; ++p ) { if( strchr( ungueltig, *p ) ) { // ungültiges Zeichen gefunden // Fehlermeldung etc break; } } [/CODE]

Noch ein Tipp zur Sicherheit: gets ist böse. Du kannst nie vor einem Pufferüberlauf sicher sein. Nimm fgets, da kannst du eine Obergrenze angeben.

@nic_power: IIRC lässt scanf den int unverändert, wenn es keine Zahlen zum Umwandeln findet. Kannst du ein Beispiel bringen, das abstürzt?

Dieser Code allein sollte noch keinen Absturz verursachen. Ich denke, es liegt eher daran, was du danach mit den Daten machst.

Stimmt, weiß auch nicht, wie ich darauf gekommen bin. Ich hatte irgendwie in Erinnerung, dass recv blockt, bis der Puffer voll ist. War wohl nun ein Traum...

Ja.

Es gibt keine 1-zu-1-Beziehung zwischen send und recv, das sind reine Byteströme. Dein recv wird AFAIK erst dann zurückkommen, wenn die 501 Bytes voll sind. Natürlich können dann mehrere Strings drinstehen. Und der letzte String im Puffer ist mit ziemlicher Sicherheit nicht vollständig.

Ja. Weil l und r die Positionen von zwei Zahlen sind, die vertauscht werden müssen. Wieso sie das sind, ergibt sich aus den beiden while-Schleifen davor. l und r laufen aufeinander zu. Dabei bleibt l stehen, wenn der Wert an der Position l nicht kleiner als das Vergleichselement ist, und r bleibt stehen, wenn der Wert an der Position r nicht größer als das Vergleichselement ist. Daher gilt nach den while-Schleifen: A[l] >= Vergleichswert >= A[r]. Darum wird getauscht. Naja, nachdem sich l und r begegnet sind, sind wir ja noch nicht fertig. Wir wissen nur, alles was links von l steht, ist kleiner als der Vergleichswert, und alles was rechts von r steht, ist größer als der Vergleichswert. Also werden beide Unterbereiche nochmal sortiert. Das geht üblicherweise solange, bis die Bereiche so klein geworden sind, dass die Sortierung trivial wird (2 Werte oder weniger).

Die Frage ist: was machst du nach dem recv? Berücksichtigst du, dass mehr als ein nullterminierter String in dem Puffer stehen kann?

Dann machst du selbst beim Empfangen oder Senden etwas falsch. Die eingebaute Fehlerkorrektur bei TCP sorgt dafür, dass nichts verloren geht und die Reihenfolge stimmt. Da es relativ schwierig ist, beim Senden etwas falsch zu machen , tippe ich mal darauf, dass beim Emfang was nicht stimmt.