//nMaxChars ist die maximale Länge des Textes von hWnd
template <class myType>
BOOL AddWindowText(HWND hWnd,myType text,  const int nMaxChars, bool breakLine=1)
{
	stringstream strBuffer;
	char* cstrBuffer=new char[nMaxChars+1]; //GetWindowText fügt eine 0 am Ende hinzu
	int charsRead=0;

	charsRead=GetWindowText(hWnd, cstrBuffer,nMaxChars+1);

	strBuffer<<cstrBuffer;
	strBuffer<<text;
	if(breakLine)
		strBuffer<<"\r\n";
	string str=strBuffer.str();

	if(str.size()>nMaxChars)
	str=str.substr(str.size()-nMaxChars-1, nMaxChars+1);

	delete [] cstrBuffer;

	return SetWindowText(hWnd, str.c_str());
}

Also wenn der String nicht gekürzt wird dann wird auch jeder Zeilenumbruch richtig angezeigt, aber irgendwie kommt es vor dass einige einfach verschwinden wenn der Anfang vom Text entfernt werden soll, ich kann grade nichts genaueres erkennen.
Kann da jemand einen Fehler erkennen? Vermutlich eher mehrere Fehler.

template <class myType>
BOOL AddWindowText( HWND hWnd,
                    myType text,
                    std::size_t nMaxChars,
                    bool breakLine = true )
{
    std::string Buffer( nMaxChars + 1 );

    std::size_t charsRead = GetWindowText(hWnd, &Buffer[0], Buffer.length());

    string str = Buffer + text;

    if( breakLine ) // Editiert. Ein if-Statement scheint hier einfach sinnvoller. 
        str += "\r\n";

    if( str.size() > nMaxChars )
        str.erase( 0, str.size() - nMaxChars );

    return SetWindowText(hWnd, str.c_str());
}

~(Natürlich ungetestet)~

if( str.size() > nMaxChars )
        str.erase( 0, str.size() - nMaxChars );

    return SetWindowText(hWnd, str.c_str());
}

Och nö.

return SetWindowText(hWnd, str.size()>nMaxChars ? &*str.end() - nMaxChars : str.c_str());

~(Selbstverständlich natürlich ungetestet)~

str.erase( 0, str.size() - nMaxChars );

das Problem mit den Zeilenumbrüchen gelöst, auch wenn ich den Grund nicht erkenne.

&*str.end() - nMaxChars

erzeugt UB (str.end() ist nicht dereferenzierbar). MSVC haut einem im Debug-Modus dafür einen assert um die Ohren.

str.c_str() + str.size() - nMaxChars

wär jetzt mein Ansatz. Geht sogar in C++03.

Och nö.

Autsch, hast Recht, das bearbeiten des Strings ist völlig überflüssig. Da habe ich wieder zu genau hingeschaut....

//nMaxChars ist die maximale Länge des Textes von hWnd
template <class myType>
BOOL AddWindowText(HWND hWnd,myType text,  const int nMaxChars, bool breakLine=true)
{
    char* buf=new char[nMaxChars+1]; //GetWindowText fügt eine 0 am Ende hinzu

    GetWindowText(hWnd, buf, nMaxChars+1);
    strncat(buf, text, strlen(buf)<nMaxChars?nMaxChars-strlen(buf):0);
    if( breakLine )
      strncat(buf, "\r\n", strlen(buf)<nMaxChars-1?2:0);

    BOOL r = SetWindowText(hWnd, buf);
    delete [] buf;
    return r;
}

Hier würde sich ein Start/End Iteratorenpaar besser machen.
Edit²: Weil unten schon steht, dass er ja irgendwie jeden Typen ausgeben lassen können will, muss man doch per Referenz o.ä. übergeben.

Ich benutz einen stringstream um jeden Datentyp zu einem String umzuwandeln.

Edit: Habe ich übersehen... das ist was anderes. Das geht dann tatsächlich nicht ohne Stringstream, wenn diese Datentypen möglicherweise nur den operator<< überladen.

Set/GetWindowText ist eindeutig WinAPI, und die arbeiten ausschließlich mit char/TCHAR.

Ja, aber das geht trotzdem mit C++-Strings. Da braucht man nicht RAII zu vernachlässigen.

Ich werfe mal eine neue Version in den Ring:

template <class myType>
BOOL AddWindowText( HWND hWnd,
                    myType const& text,
                    std::size_t nMaxChars,
                    bool breakLine = true )
{
    std::string Buffer( nMaxChars + 1 );

    GetWindowText(hWnd, &Buffer[0], Buffer.length());

    std::ostringstream stream( Buffer );
    stream << text;

    if( breakLine )
        stream << "\r\n";

    std::string rval = stream.str();
    char const* begin = rval.c_str():

    if( rval.length() > nMaxChars )
		begin += rval.length() - nMaxChars - 1;

    return SetWindowText(hWnd, begin);
}

Außerdem würde ich gern den << Operator für HWND überladen, aber es geht nicht.

HWND operator<<(HWND hWnd, const char* text)
{
	AddWindowText(hWnd, text);
	return hWnd;
}

Da kommt nur die Meldung dass ein Operator der kein Member ist einen Klassen- oder Enumerationstyp erfordert. Geht der Operator also nur als Klassenmember?

Set/GetWindowText ist eindeutig WinAPI, und die arbeiten ausschließlich mit char/TCHAR.

Och, ein std::vector<char/TCHAR> tut es auch, vector<...>.data() gibt es schon in VS 2010.

Das Problem: Ist das Window dann owner des Textes?

Wieso muss ich ein int zu long double casten beim übergeben und wieso hat to_string bei mir nur 3 varianten die alle kein int nehmen,

1.) Es gibt auch eine Ueberladung fuer (in)signed Long Long.
2.) Du benutzt wahrscheinlich VS 2010.

Außerdem würde ich gern den << Operator für HWND überladen, aber es geht nicht.

1.) Tolle Fehlerbeschreibung
2.) HWND ist wahrscheinlich ein void*, diese ueberladung gibt es wahrscheinlich schon.

Ein anderes kleines Problem ist die to_string Funktion. Wieso muss ich ein int zu long double casten beim übergeben und wieso hat to_string bei mir nur 3 varianten die alle kein int nehmen, wie es hier zu sehen ist: http://www.cplusplus.com/reference/string/to_string/?kw=to_string

Das leigt daran, dass vor VS2012 mit to_string nur eben die Standard Floatingpoint Zahlen eingebaut waren. to_string ist eigentlich C++11 und war damals im begrenzten Umfang eine kleine Erweiterung von VS2010 (und ich weis nicht welchen Versionen vorher), mit VS2012 wird to_string dann voll unterstützt.

struct foo{};
...
func(foo(a, b, c, d, e, f, g));

?

func({a, b, c, d});

Reg dich ab.
Set/GetWindowText ist eindeutig WinAPI, und die arbeiten ausschließlich mit char/TCHAR.

Das ist kein Grund, mit new[] / delete[] zu arbeiten. Kannst auch genauso gut

vector<char> puffer(999);
eine_C_Funktion(&puffer[0],999);

schreiben. Dann kann es dir gar nicht passieren, delete[] zu "vergessen". Auch wenn du delete[] dort stehen hast, kann ja zwischendurch irgendwo eine Ausnahme fliegen und dann hättest du ein Speicherleck, weil die Ausführung gar nicht erst zum delete[] kommt.

Ab C++11 ist das auch bei std::string erlaubt, weil garantiert ist, dass die Elemente hintereinander im Speicher stehen. Allerdings muss man sich, wenn man das so in String schreiben lässt, selbst um die Nullterminierung kümmern. Die will man typischerweise nicht mit drin haben und auch den Rest dahinter nicht. Also:

string s (999);
eine_C_Funktion(s.data(),999); // ab C++11
s.erase(find(s.begin(),s.end(),'\0'),s.end());

(ungetestet)

Merken: new[] und delete[] brauchen wir so gut wie nie mehr.

Merken: new[] und delete[] brauchen wir so gut wie nie mehr.

so gut?
Ich meine, wir brauchen seit C++11/14* nicht mal new zu schreiben, vorausgesetzt wir arbeiten brav mit Smart-Pointern.

Auch wenn du delete[] dort stehen hast, kann ja zwischendurch irgendwo eine Ausnahme fliegen und dann hättest du ein Speicherleck, weil die Ausführung gar nicht erst zum delete[] kommt.

Wieso erklärst du ihm das? Das weiß er (so hoffe ich) selbst.

HWND ist wahrscheinlich ein void*, diese ueberladung gibt es wahrscheinlich schon.

Beides richtig. HWND ist ein HANDLE , was wiederum ein PVOID ist. Und der Ausgabeoperator für void* ist schon überladen (in ostream selbst).

Die will man typischerweise nicht mit drin haben und auch den Rest dahinter nicht.

Bei vielen solchen Funktionen ist von vornherein klar, dass '\0' das letzte Zeichen im String ist - daher reicht da meistens auch ein pop_back().
Und wieso benutzt du nicht die find() -Funktion aus std::string ?

• make_unique

HWND ist wahrscheinlich ein void*, diese ueberladung gibt es wahrscheinlich schon.

Beides richtig. HWND ist ein HANDLE , was wiederum ein PVOID ist. Und der Ausgabeoperator für void* ist schon überladen (in ostream selbst).

Er redet nicht vom Ausgabeoperator, Sone.

Sone schrieb:

HWND ist wahrscheinlich ein void*, diese ueberladung gibt es wahrscheinlich schon.

Beides richtig. HWND ist ein HANDLE , was wiederum ein PVOID ist. Und der Ausgabeoperator für void* ist schon überladen (in ostream selbst).

Er redet nicht vom Ausgabeoperator, Sone.

Ich weiß ja nicht, wie du das siehst, aber wenn ich lese

Knivil schrieb:

Außerdem würde ich gern den << Operator für HWND überladen, aber es geht nicht.

[...]
2.) HWND ist wahrscheinlich ein void*, diese ueberladung gibt es wahrscheinlich schon.

Dann folgere ich daraus, dass er sich auf das Zitat bezieht...
Edit: Ah, er will gar nicht den operator<< für ostream überladen... :kopf->tisch: