AnsiString an ein char Array anhängen

muss blos aufpassen das du den zweiten String vor dem abzuschliessendem \0 anhängst
vieleicht sind das dann nicht 16 Zeichen, hab nicht gezählt

hermes

void __fastcall TForm1::Button1Click(TObject *Sender) 
{ 
char* adr;          /* !!Muss ein Pointer vom DatenTyp char sein!! */ 
adr = strcat(test+16, a.c_str);   /* Fehlermeldung can't convert char* to fastcall*(_closure)..... auf, diese Funktion muss etwas mit
einen Funktionszeiger am Hut haben.
google 
char *  strcat ( char * dest, const char * src ); 
Append string.
Appends src string to dest string. The terminating null character in dest is overwritten by the first character of src. The resulting string includes a null-character at end. Müsste eigentlich passen, nur das die Funktion ein Zeiger auf einen String zurückgibt*/ 

    Application->MessageBox(adr,"xxxxxx",MB_OK); 
}

Funktioniert nicht

KlausB

Hallo

wo ist denn da das "new" und das "delete"

desweiteren ist das sehr gefaehrlich den char* auf 30 Zeichen festzulegen

was passiert denn wenn du mehr als 30 Zeichen da reinschreibst

MfG
Klaus

Warum so kompliziert?

String test="1234567890";
Application->MessageBox(test.c_str()+5,"www",MB_OK|MB_ICONEXCLAMATION|MB_APPLMODAL);

junix

streicht bitte auch strcpy aus euren Köpfen! strncpy ist Trumpf!

Warum?

Wir sicn hier im VCL Forum da könne wir StrLCopy nutzen

junix

Christian211 schrieb:

Warum?

Quizfrage: Was passiert hier?

test = new char[2];
        strcpy(test, "File not Found  ");

Der Einwand mit dem VCL Forum ist zwar nicht unrichtig, aber hier wurde bereits strcpy verwendet...Macht in diesem Fall jetzt auch beschränkt sinn, hier die VCL Kapselungen von AnsiC-Funktionen zu benutzen. Anders siehts mit komplexen KLassen wie z.B. std::string aus.

Das "Warum" bezog sich nicht auf das für und wider von strcpy. Die Problematik ist mir bewusst.

Es bezog sich daraufm warum nicht StrLCopy benutzt wird.

Macht in diesem Fall jetzt auch beschränkt sinn, hier die VCL Kapselungen von AnsiC-Funktionen zu benutzen

Kann ich nicht nachvollziehen. Für strncpy und weitere sind Headerdateien einzubinden für die entsprechende VCL Funktion nicht.

junix

...und die Anzahl einzubindender Header war nochmal ein Indiz wofür...?

Das die Funktion von der VCL gekapselt ist war nochmal ein Indiz wofür...?

Es war hier von mir ein Vorschlag, dass ev. auch die Funktionen der VCL Beachtung finden.

junix

Christian211 schrieb:

Das die Funktion von der VCL gekapselt ist war nochmal ein Indiz wofür...?

Keine Ahnung. Worauf willst du hinaus?

Weitere Quizfrage: ist strcpy Teil der VCL?

Das du auf meine vorherige Frage bzgl. Headerfiles nicht eingegangen bist, werte ich als Einsicht, das dein Argument nichtig war. Korrekt?

werte ich als Einsicht, das dein Argument nichtig war. Korrekt?

Nein,
- als Entwickler ist man schreibfaul
- als Anfänger weiss man nicht, dass man eine Header einbinden muss
- als Anfänger weiss man of nicht den Namen der Header zum einbinden (die F1 Taste klemmt ja öfters, und einige Compiler werden offenbar ohne Hilfe ausgeliefert)

Keine Ahnung. Worauf willst du hinaus?

Was in Gottes Namen hat die Kapselung einer Funktion damit zu tun, ob man sie benutzen sollte oder nicht? Die gnaze VCL kapselt die Win 32 API. Diese Funktionen sind bloß wenig bekannt. Schließlich war hier, bezogen auf die Ausgangsfrage, überhaupt die Nutzung des Typ char unnötig, nur um ab einer bestimmten Stelle etwas mitteles einer Messagebox auszugeben.

Weitere Quizfrage: ist strcpy Teil der VCL?

Wenn du hier Moderator bist, solltest du das eigentlich Wissen.

Braunstein

Hallo,

@Christian211
Wenn du ein wenig nachdenkst, wirst du darauf kommen, dass sowohl strcpy als auch strncpy Teil der VCL sind und du deshalb keine zusätzlichen Header einbinden musst.
Überlegung:
StrLCopy ist Teil der VCL
StrLCopy kapselt strcpy
also muss die string.h (wo strcpy drin ist) in die VCL eingebunden werden
also ist strcpy Teil der VCL

[edit]
Kommando zurück.
strcpy ist zwar Teil der VCL (das stimmt), StrLCopy kapselt diese Funktion aber nicht. Ich hab mal den Quellcode von StrLCopy angeschaut und der ist reinstes Assembler. Die Wahrheit liegt also mehr in der Mitte.
[\edit]

Ciao

junix

Christian211 schrieb:

werte ich als Einsicht, das dein Argument nichtig war. Korrekt?

- als Entwickler ist man schreibfaul

Dann bist du auch einer der Entwickler die das Einsparpotential in der Zeit am falschen Ort zu finden glauben.

Christian211 schrieb:

- als Anfänger weiss man nicht, dass man eine Header einbinden muss

Dann lernt man als Anfänger was dazu. Es ist kein Argument, einfach einen Header der alle anderen Header includiert zu propagieren. Das ist absolut am Sinn vorbei und schafft unnötige Abhängigkeiten.

Christian211 schrieb:

- als Anfänger weiss man of nicht den Namen der Header zum einbinden (die F1 Taste klemmt ja öfters, und einige Compiler werden offenbar ohne Hilfe ausgeliefert)

Dann lernt der Anfänger hald, die Taste F1 zu reparieren und entsprechende Dokumentation zu besorgen, denn es wird nicht das letzte mal sein, das die Dokumentation benötigt werden wird.

Christian211 schrieb:

Keine Ahnung. Worauf willst du hinaus?

Was in Gottes Namen hat die Kapselung einer Funktion damit zu tun, ob man sie benutzen sollte oder nicht? Die gnaze VCL kapselt die Win 32 API. Diese Funktionen sind bloß wenig bekannt. Schließlich war hier, bezogen auf die Ausgangsfrage, überhaupt die Nutzung des Typ char unnötig, nur um ab einer bestimmten Stelle etwas mitteles einer Messagebox auszugeben.

Nur in sehr eingeschränktem Rahmen relevant. Denn so gesehen benötigst du nicht mal StrLCopy, denn AnsiString verfügt ja über die diversen Operatoren die die Verwendung von String-Cat oder String-Copy-Funktionen völlig unnötig machen.

Christian211 schrieb:

Weitere Quizfrage: ist strcpy Teil der VCL?

Wenn du hier Moderator bist, solltest du das eigentlich Wissen.

... Offensichtlich hast du nicht gesehen, was ich mit dieser Frage bezwecken wollte. Man msus hier, im VCL Forum nicht alles mit Gewalt auf die VCL umbiegen. Es wurde hier ein nicht glücklich gewähltes Ansi C Element verwendet. Also ist es nur angemessen, wenn ich ein besseres Element aufzeige, das ebenfalls aus der selben Bibliothek stammt wie das unglücklich gewählte. Damit entkräftet man auch gleich einige "aber"-Argumentationen.

Interssant jedenfalls, was so ein kleiner Hinweis auf eine VCL Funktion auslösen kann

Einsparpotential in der Zeit am falschen Ort zu finden glauben

Danke geht seit 26 Jahren sehr gut

@Braunstein
strncpy war hier auch nur ein Beispiel. Es gibt weitere Standardfunktioen, für die es entsprechende Funktionen in der VCL gibt und für die dann *.h rein muss

junix

Christian211 schrieb:

Einsparpotential in der Zeit am falschen Ort zu finden glauben

Danke geht seit 26 Jahren sehr gut

Stimmt... denn Tipparbeit ist ja auch bei der Softwarentwicklung der absolute Zeitfresser... egal. Ist ein anderes Thema.

Was mich viel eher interessieren würde, ist die Tatsache, was du eigentlich für ein Problem mit dem Includieren von headerfiles hast:

Christian211 schrieb:

Kann ich nicht nachvollziehen. Für strncpy und weitere sind Headerdateien einzubinden für die entsprechende VCL Funktion nicht.

Es ist doch genau der tiefere Sinn, das man nur headerfiles included die man auch benötigt. Oder gehörst du auch zu denen die ein Headerfile "includeAll.h" machen, wo schlussendlich eine Liste mit #include für jedes erdenkliche Headerfile steht, womöglihc noch einige using-Anweisungen, und dann das einfach in alle Module "includeall.h" includen?

hermes

KlausB schrieb:

wo ist denn da das "new" und das "delete"
desweiteren ist das sehr gefaehrlich den char* auf 30 Zeichen festzulegen
was passiert denn wenn du mehr als 30 Zeichen da reinschreibst

void __fastcall TForm1::Button1Click(TObject *Sender)
{
	char* Message;
	if(OpenDialog1->Execute())
     {
	     Message = new char[OpenDialog1->FileName.Length()+20];
          Message = "File->";
     	strcpy(Message+6,OpenDialog1->FileName.c_str());
     	Application->MessageBox(Message,"File",MB_OK);
	     delete Message;
     }

}

Gibt aber folgendes Problem, im Caption der MessageBox steht nicht File sondern
ein Rest von Message. Habe mir Message genauer angeschaut, ist aber alles
korrekt.

Wie wäre es mit

String Message;
if(OpenDialog1->Execute())
   {
   Message="File->"+OpenDialog1->FileName;
   Application->MessageBox(Message.c_str(),"File",MB_OK);
   }

Nein, ich includiere auch nur was nötig ist.

Was hast du gegen eine kleine harmlose VCL Funktion?

Richtig für strxxx ist keine Header einzubinden. Irrtum von mir.

hermes

Simmt, habe mal wieder nach dem Motto warum Einfach wenn es auch Umständlich
geht gehandelt.

Danke für die Hilfe...