Replace
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo zusammen
Ich habe so was noch niemals gehabt, ich möchte einen Text suchen und diesen ersetzen.
Ich habe das Programm als lokales Programm gespeichert, als ich es nach erfolgreichen Tests dem Kundenpaket zugeordnet habe, funktioniert die Wertübergabe nicht mehr.
Die Variable replace soll die Variable Find ersetzen.
Kann mir da jemand helfen? Irgendwelche Einstellungen?
Danke zum voraus
Gruss
Ich habe so was noch niemals gehabt, ich möchte einen Text suchen und diesen ersetzen.
Ich habe das Programm als lokales Programm gespeichert, als ich es nach erfolgreichen Tests dem Kundenpaket zugeordnet habe, funktioniert die Wertübergabe nicht mehr.
Die Variable replace soll die Variable Find ersetzen.
Kann mir da jemand helfen? Irgendwelche Einstellungen?
Danke zum voraus
Code: Alles auswählen.
IF REPLACE NE space.
REPLACE FIND LENGTH len_find
WITH <replace> INTO xtlines-tdline.
string_replaced = 'X'.
MODIFY xtlines.
PERFORM ausgabe.
ELSE.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Der Code von dir ersetzt den Text "FIND(len_find)" im Text "XTLINES-TDLINE" mit dem Text aus "<replace>".
Die Abfrage des IFs bezieht sich aber auf die Variable "REPLACE" und nicht auf "<replace>". Daher wird der Code nur durchlaufen wenn in "REPLACE" etwas steht, was aber zwangsläufig NICHT in "<replace>" stehen muss. Wenn das Feldsymbol "<replace>" nicht zugeordnet ist gibt es sogar einen wunderschönen Kurzdump.
Achtung: Die Angabe von "FIND" mit "LENGTH len_find" berücksichtigt nur die ersten "len_find" Zeichen des Textes "FIND".
Kleine Anmerkung am Rande:
Bitte verwende für die Variablennamen NICHT dieselben Namen wie die ABAP-Schlüsselwörter. Das ist zwar erlaubt aber höchst verwirrend. Auch wenn ich hier jetzt in ein Wespennest stechen sollte (@Ralf), wäre es fast besser du nutzt die ungarische Notation als du benutzt solche Variablennamen. Dann sieht man wenigstens auf einen Blick was was ist.
EDIT:
Bei deinem Beispiel handelt es sich außerdem um die alte, obsolete(!) Schreibweise. Besser du gewöhnst dir gleich die neue Variante an:(Selbst da ich alles groß geschrieben habe, kann man es dank der Variablennotation noch sehr gut lesen)
Die Abfrage des IFs bezieht sich aber auf die Variable "REPLACE" und nicht auf "<replace>". Daher wird der Code nur durchlaufen wenn in "REPLACE" etwas steht, was aber zwangsläufig NICHT in "<replace>" stehen muss. Wenn das Feldsymbol "<replace>" nicht zugeordnet ist gibt es sogar einen wunderschönen Kurzdump.
Achtung: Die Angabe von "FIND" mit "LENGTH len_find" berücksichtigt nur die ersten "len_find" Zeichen des Textes "FIND".
Kleine Anmerkung am Rande:
Bitte verwende für die Variablennamen NICHT dieselben Namen wie die ABAP-Schlüsselwörter. Das ist zwar erlaubt aber höchst verwirrend. Auch wenn ich hier jetzt in ein Wespennest stechen sollte (@Ralf), wäre es fast besser du nutzt die ungarische Notation als du benutzt solche Variablennamen. Dann sieht man wenigstens auf einen Blick was was ist.
EDIT:
Bei deinem Beispiel handelt es sich außerdem um die alte, obsolete(!) Schreibweise. Besser du gewöhnst dir gleich die neue Variante an:
Code: Alles auswählen.
REPLACE LD_FIND IN XTLINES-TDLINE WITH LD_REPLACE.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
An der Stelle möchte ich für Ralf Partei ergreifen. Man darf nicht zwei verschiedene Sachen durcheinanderwerfen. Der Schönheitsfehler in christofs Code bestand in der Tat darin, dass er "FIND" als Variablennamen verwendet hat, obgleich es sich dabei auch um einen ABAP-Befehl handelt. Erschwerend kam hinzu, dass er diese Variable dann im Kontext eines diesem Befehl inhatlich eng verwandten Befehls, nämlich REPLACE, verwendet hat, so dass unübersichtlich wurde, was da gesucht oder ersetzt werden soll.
mindestens ebenso gut gehen, wenn nicht sogar noch besser. Der entscheidende Unterschied, der die Lesbarkeit heraufsetzt, ist also nicht Ungarn, sondern sprechende Feldnamen.
Das würde bei(Selbst da ich alles groß geschrieben habe, kann man es dank der Variablennotation noch sehr gut lesen)Code: Alles auswählen.
REPLACE LD_FIND IN XTLINES-TDLINE WITH LD_REPLACE.
Code: Alles auswählen.
REPLACE ZU_ERSETZENDE_ZEICHEN IN MATERIALNAME WITH ERSETZUNGSTEXT.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Schon klar, aber du verwendest für dein Beispiel deutsche Variablennamen. Mit den englischen ist es wieder weniger gut lesbar.
Den Vorteil den ich hier in der ungarischen Notation sehe ist, ohne sie jetzt schönreden zu wollen, dass mit der Darstellung XX_XXX... (Zwei Zeichen, Unterstrich, Weitere Zeichen) sofort erkennbar ist: Das ist jetzt eine Variable.
(Um ehrlich zu sein, hab ich diesen Umstand auch erst heute bei diesem Beispiel so richtig bemerkt)
Natürlich ist das eher nur in den "alten" ABAP-Befehlen sinnvoll, wo man einen sprechenden "Satz" ausformuliert um einen Befehl auszuführen:
"Ersetze 'bla' in 'blablabla' mit 'hi'.
Bei den neuen OO-Varianten (Kettensätze mit -> usw.) ist die UN dann aber schnell mal hinderlich:
lr_receipt->get_positions( )->get_position( id_material = lr_material->get_id( ) )->get_price( id_currency = lr_currency->get_id( ) ).
vs.
receipt->get_positions( )->get_position( material = material->get_id( ) )->get_price( currency = currency->get_id( ) ).
Warum ich die UN auch erwähnt hab ist, dass sich die meisten Entwickler etwas darunter vorstellen können und von den ganzen Diskussionen die hier immer wieder stattfinden kann man dann über die möglichen Alternativen nachlesen. Ich sagte ursprünglich ja auch es wäre "fast besser die UN einzusetzen".
Den Vorteil den ich hier in der ungarischen Notation sehe ist, ohne sie jetzt schönreden zu wollen, dass mit der Darstellung XX_XXX... (Zwei Zeichen, Unterstrich, Weitere Zeichen) sofort erkennbar ist: Das ist jetzt eine Variable.
(Um ehrlich zu sein, hab ich diesen Umstand auch erst heute bei diesem Beispiel so richtig bemerkt)
Natürlich ist das eher nur in den "alten" ABAP-Befehlen sinnvoll, wo man einen sprechenden "Satz" ausformuliert um einen Befehl auszuführen:
"Ersetze 'bla' in 'blablabla' mit 'hi'.
Bei den neuen OO-Varianten (Kettensätze mit -> usw.) ist die UN dann aber schnell mal hinderlich:
lr_receipt->get_positions( )->get_position( id_material = lr_material->get_id( ) )->get_price( id_currency = lr_currency->get_id( ) ).
vs.
receipt->get_positions( )->get_position( material = material->get_id( ) )->get_price( currency = currency->get_id( ) ).
Warum ich die UN auch erwähnt hab ist, dass sich die meisten Entwickler etwas darunter vorstellen können und von den ganzen Diskussionen die hier immer wieder stattfinden kann man dann über die möglichen Alternativen nachlesen. Ich sagte ursprünglich ja auch es wäre "fast besser die UN einzusetzen".
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Im Englischen wird man sich an der Stelle vielleicht etwas mehr Gedanken machen müssen, wie man seine Variablen benennt. Mein Beispiel hat ja auch sehr beispielhaften Charakter gehabt; normalerweise werden Variablen nicht so drastisch auf ihren Einsatzzweck in einem einzigen Befehl benamt sein.Schon klar, aber du verwendest für dein Beispiel deutsche Variablennamen. Mit den englischen ist es wieder weniger gut lesbar.
Aber
Code: Alles auswählen.
REPLACE UNDESIRED_CHARS IN MATERIAL_NAME WITH REPLACEMENT_CHARS.Diese Eigenschaft braucht man eigentlich gar nicht mehr im Variablennamen festzuhalten, da sowohl SE38 als auch Eclipse - und sogar das CODE-Tag hier im Forum - Befehle und Variablennamen unterschiedlich einfärben. IMHO wäre es veraltetes Denken, trotzdem auch im Namen noch eine Unterscheidbarkeit verankern zu wollen.Den Vorteil den ich hier in der ungarischen Notation sehe ist, ohne sie jetzt schönreden zu wollen, dass mit der Darstellung XX_XXX... (Zwei Zeichen, Unterstrich, Weitere Zeichen) sofort erkennbar ist: Das ist jetzt eine Variable.
Man könnte sogar darüber nachdenken, die Farbkodierung noch auszubauen, so dass man einer Variablen an ihrer Textfarbe ansieht, ob sie lokal, global, Import- oder Exportvariable ist. Das wäre in meinen Augen ein sehr eleganter Ersatz zur hässlichen und sperrigen ungarischen Notation, bei dem optisch die gleiche Information zur Verfügung steht, ohne dass der Code so scheußlich aussieht. Die ganzen Unterstriche machen die UN in meinen Augen auch wieder schlecht lesbar.
Obendrein wäre für die richtige Einfärbung dann der Editor verantwortlich. Damit hätte das ganze eine höhere Zuverlässigkeit, als wenn Programmierer etwas aus Gewohnheit schreiben, ohne sich Gedanken darüber zu machen, ob es inhaltlich überhaupt stimmt. Ich habe schon öfters GV_ und LV_ falsch angewendet gesehen, also etwa LV_ bei Feldern, die technisch ganz klar globale Variablen waren. Da merkt man dann, dass der Programmierer aus Routine vor alle seine Felder LV_ schreibt, denn mit globalen Feldern arbeitet man ja heutzutage nicht mehr (auch wenn er es im Einzelfall doch tut, sei es, weil sein Report so kurz ist, dass man das Fehlen von Unterroutinen vertreten kann, sei es, weil er mit Dynprofeldern hantiert). Damit mutiert LV_ dann endgültig zu totem Ballast, ähnlich wie das "www." vor URLs.
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Das ist leider nicht vergleichbar, da "www.url" und "url" inhaltlich nicht das selbe ist, auch wenn fast immer beim Weglassen von "www." auf die zugehörige Subdomain umgeleitet wird.DeathAndPain hat geschrieben: Damit mutiert LV_ dann endgültig zu totem Ballast, ähnlich wie das "www." vor URLs.
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Ich meinte das so, dass es ein historisch bedingter, unnötiger Ballast ist, dass die meisten Homepages überhaupt das "www." im Namen haben und einige wenige sogar darauf bestehen. Es enthält ja keinerlei Nutzinformation. Das Protokoll steht vorne im http://, und die gewünschte Domain steht hinter dem "www.". Klar macht es technisch einen Unterschied, genau wie LV_VARIABLE und VARIABLE technisch auch nicht dieselben Felder bezeichnen, aber inhaltlich ist der Vorbau halt ein leerer Wasserkopf, der nur Tipparbeit macht, wenn man nicht über einen Link kommt.
Homepages guter Administratoren machen es andersherum: Die leiten auf die Domain ohne www. um, wenn Du www. mit angibst. Dann sehen zumindest aufmerksame User, wo sie landen und dass sie sich unnötig Tipparbeit gemacht haben.auch wenn fast immer beim Weglassen von "www." auf die zugehörige Subdomain umgeleitet wird
Seite 1 von 1
Vergleichbare Themen
12
Antw.
Antw.
9963
Views
Views
3
Antw.
Antw.
2923
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1152
vor 2 Tagen von DeathAndPain 4 / 1152
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1152
vor 2 Tagen von DeathAndPain 4 / 1152