MultilineEditBox zeilenweise behandeln

Eldarion

thx das werde ich einbauen

Eldarion

int nLineCount = (int)SendMessage(hDialog, EM_GETLINECOUNT, 0, 0);
	string s;
	bool gerade = true;
	char  szBuffer [1024];
	for(int i=0; i<nLineCount; i++)
	{
		// Aktuelle Zeilenlänge auslesen
		int nLineLength = (int)SendMessage(hDialog, EM_LINELENGTH,
		(WPARAM)SendMessage(hDialog, EM_LINEINDEX, (WPARAM)i, 0), 0);

		// Zeile in Buffer einlesen
		// Achtung: Kopierte Zeile beinhaltet keine Nullterminierung
		SendMessage(hDialog, EM_GETLINE, (WPARAM)i, (LPARAM)szBuffer);
		szBuffer[nLineLength] = '\0';
		s = String(szBuffer);
		DialogOUs.insert(pair<int, string>(activeDialog, s));		
	}

so, in meiner map stehen jetzt aber nur irgendwelche kryptischen zeichen, was mach ich falsch?

und noch eine frage, wie kann ich denn zeilenweise scrheiben, gibts da auch so etwas wie setline?

Analog Bit

Um welches Fensterhandle handelt es sich bei hDialog?
Um das HWND des Dialogs?
Hier muss natürlich das Fensterhandle des Edit Controls angegeben werden!

Um Text an vorhandenen anzuhängen hier ein kleines Beispiel:
(Dies ist kein kompletter Code. Es wird der Text aus einem zweiten Edit Control ausgelesen ein Zeilenumbruch angehängt und an den vorhandenen Text im Multiline Edit Control angehängt. Wenn der Cursor vorher nicht in einer neuen Zeile steht, wird der Text an das letzte Zeichen angehängt. Bei Bedarf also vorher noch ein Zeilenumbruch zufügen)

TCHAR sztemp[1024];
int nlength;
// Text aus zweitem Edit Control auslesen
GetWindowText(GetDlgItem(hDialog, IDC_EDIT_TEXTTOCOPY), sztemp, 1024);
// Zeilenumbruch anhängen
lstrcat(sztemp,"\r\n");
nlength = GetWindowTextLength(hwndEdit);
// Text im Multiline Edit Control selektieren
SendMessage(hwndEdit, EM_SETSEL, (WPARAM)nlength, (LPARAM)nlength);
// Text ersetzen
SendMessage(hwndEdit, EM_REPLACESEL, (WPARAM)FALSE, (LPARAM)sztemp);
// Text im Multiline Edit Control deselektieren
SendMessage(hwndEdit, EM_SETSEL, (WPARAM)-1, (LPARAM)0);

HINWEIS:
hDialog: Fensterhandle des Dialogs
hwndEdit: Fensterhandle des Multiline Edit Controls
zu den einzelnen Messages siehe MSDN

Eldarion

sry, Dialog war hier vllt missverstanden mit Resourcendialog, es geht aber um etwas ganz anderes. und das hDialog ist das editfeld. ist dann noch iwas falsch?

Analog Bit

Was genau funktioniert denn nicht?
Hast du die Anwendung mal schrittweise debugged?

Eldarion

das problem entsteht wie gesagt wenn ich die messagebox auslese und in meine multimap schreibe.

ich habe in die editbox reingeschrieben: "Hier gibt es ein Problem!" nacher in der map steht: "ÌÌÌÌÌÌÌÌÌÌÌ.." (mal sinnvoll gekürzt :D)
ich hoffe das problem ist klar..

Analog Bit

messagebox??? oder meinst du ein Edit Control

Ich gehe mal davon aus, dass du die Anwendung nocht nicht zeilenweise debugged hast. Z.B. einen Breakpoint bei

DialogOUs.insert(pair<int, string>(activeDialog, s));

gesetzt hast, um zu sehen, was in den Variablen s, bzw. szBuffer steht.

Weiterhin denke ich mal, dass es sich bei

s = String(szBuffer);

um einen Schreibfehler handelt, sollte wahrscheinlich string(szBuffer) heißen.

Welchen Zeichensatz hast du bei deiner Anwendung eingestellt (Multi-Byte / Unicode)?
Um was genau handelt es sich bei DialogOUs und activeDialog? Ein bischen mehr Code wäre hilfreich.

Eldarion

DialogOUs ist eine <int, string> map. ja das mit String war ein schreibfehler, ich hatte den source etwas abgeändert und noch net wieder compilt sry.
ActiveDialog ist eine int variable die mir anzeigt welcher Dialog grade bearbeitet wird.
und da ich die komplette Map am ende des progs in eine txt schreibe, und das einwandfrei funktioniert wenn ich der map konstante strings zuweise bin ich mir sicher das das ganze schon in s steht. trotzdem hab ich nochmal debuggt, und diese kryptische zeichenfolge steht schon in szBuffer.

ich benutze unicode, sollte ich lieber auf multi-byte umsteigen?

edit: multi-byte hat dasselbe problem.

Analog Bit

Erst mal kann das nur in die Hose gehen, wenn du hier Unicode verwendest.

szBuffer ist bei dir ein CHAR Array und dieses wird in folgender Zeile mit WCHAR Daten gefüllt

SendMessage(hDialog, EM_GETLINE, (WPARAM)i, (LPARAM)szBuffer);

Wenn, dann

WCHAR szBuffer [1024];

Damit wird allerdings auch die ganze Geschichte mit string inkompatibel.
Dann müsstest du entweder den Datentyp wstring verwenden, oder den Puffer erst mit WideCharToMultiByte in ein CHAR Array schreiben.

Nichts desto trotz, sagtest du, dass du auch bei Einstellung Multi-Byte in der Variablen s (auch bei szBuffer?) nur 'wirre' Zeichen erhältst.
Hast du in der Funktion auch mal das Handle auf das EditControl überprüft (HWND des richtigen Controls, HWND auch gültig)?

Bei EM_GETLINE muss das erste Element des "Empfangspuffers" mit der Länge der zu erwarteten Zeichenfolge initialisiert werden.
Sonst klappt es nicht.

Analog Bit

Hups, übersehen
Bei mir funktioniert es auch ohne

Aber noch kleine Korrektur - es muss nicht das erste Element sein, sondern das erste WORD. Bei CHAR also zwei Elemente (sonst wäre ja auch nur eine Größe von 256 Zeichen möglich)

Stimmt. Laut MSDN ist das zwar ein WORD, aber ich nehme lieber ein int und caste "abenteuerlich" :

int *iptr;
 iptr = (int *) &szBuffer[0];
*iptr = nLineLength;

Vielleicht sollte Eldarion mal die lange Zeile da oben rausnehmen. Ist ja fürchterlich dieses Gescrolle !

Analog Bit

merker schrieb:

Vielleicht sollte Eldarion mal die lange Zeile da oben rausnehmen. Ist ja fürchterlich dieses Gescrolle !

Kann ich nur zustimmen

Alternative zum "abenteuerlichen" Cast - mit dem vohandenen int:
Tun wir doch einfach so, als kopieren wir eine Zeichenkette

lstrcpy(szBuffer, (LPCTSTR)&nLineLength);

Eldarion

so, es geht jetzt. super großes thx an euch.

@Eldarion :
Vielen Dank für das Rausnehmen der Zeile. Nun passt der Thread wieder in meinen Browser.

@Analog Bit :
Gute Idee mit lstrcpy (). Allerdings gibt es ein Problem, falls die Zeichenkette zufällig 0x0100 Zeichen lang ist.

Analog Bit

merker schrieb:

Allerdings gibt es ein Problem, falls die Zeichenkette zufällig 0x0100 Zeichen lang ist.

Ist bei Verwendung von Multi-Byte natürlich korrekt, wenn das Low-Byte des Words 0 ist, funktioniert das nicht - bei Wide-Char allerdings kein Problem.

Allerdings ist deine Lösung mit den int auch nicht ganz das 'saubere', wenn dynamische Allocierung von szBuffer verwendet wird.

LPTSTR szBuffer = (LPTSTR)LocalAlloc(LPTR, (nLineLength + 1) * sizeof(TCHAR));

Man weis ja nie, ob sich im Speicher hinter dem angelegten Puffer noch benötigte Daten befinden.
Denke mal eine sauber Lösung wäre folgende:

if(nLineLength)
{
  *((LPWORD)szBuffer) = (WORD)nLineLength;
  SendMessage(hwe, EM_GETLINE, (WPARAM)i, (LPARAM)szBuffer);
}
*(szBuffer + nLineLength) = '\0';

Einwände?

Schön übersichtlich die Lösung. Aber da könnte der Kompiler Ärger machen :
Ein "lvalue" (hier : szBuffer) soll/kann/darf nicht gecastet werden.

Analog Bit

Dieser Cast ist erlaubt.
Der Zeiger auf die Adresse in die geschrieben werden soll, wird letztendlich das lvalue, nicht das Resultat aus dem Pointercast.
'Aufgelöst' würde das so aussehen:

LPDWORD lpdw = (LPWORD)szBuffer;
*(lpdw) = (WORD)nLineLength;

Nicht erlaubt wäre dieser Cast:

((WORD)*szBuffer) = (WORD)nLineLength;