Zeichenkette nach komma holen

Re: Zeichenkette nach komma holen

Mein Lösungsansatz würde wohl beginnen mit "letztes Wort" im "2. Char Wert".

Ich mach jetzt mal eine ganz simple Lösung für "Frank, Meier, Berlin. " die 2. char Wert:

Es ist ein Krampf in diesem Fenster zu schreiben, bei jeder neuem Tastendruck springt das ganze Fenster auf und ab.... deshalb lass ich jetzt meine Text auch so stehen wie erst ist... egals, wie es aussieht.

Re: Zeichenkette nach komma holen

ralf.wenzel hat geschrieben:......taugt diese Lösung nicht viel. Stattdessen machen zwei Lösungen mehr Sinn:

Den Zusatz hättest Du Dir auch sparen können.

Ich gehe hier im Forum schon lange nicht mehr von irgendetwas aus. Zu fast jeder Frage müsste ich meisten immer erst noch Gegenfragen stellen. Das spare ich mir aber schon seit langem.

Ich bin ja froh, wenn ich die meisten Fragestellungen überhaupt noch verstehe und dort eine Sinn reinbekomme.

Re: Zeichenkette nach komma holen

Man könnte auch einfach einen regulären Ausdruck dafür verwenden.

REPORT.

PARAMETERS: p_input TYPE string OBLIGATORY LOWER CASE.

WRITE:/ p_input.
REPLACE REGEX '.*,([^,]*)$' IN p_input WITH '$1'.
WRITE:/ p_input.

Re: Zeichenkette nach komma holen

Der Satz ist so gemeint, dass du dir von meinen beiden Lösungen eine aussuchen kannst. Einfacher ist wahrscheinlich die erste mit SPLIT....INTO TABLE, weil du mit nur wenigen Befehlen an den gesuchten Ausdruck kommst. Das sieht dann so aus:

SPLIT lv_suchFeld AT ',' INTO TABLE lt_treffer.
LOOP AT lt_treffer ASSIGNING <treffer>.
ENDLOOP.
WRITE:/ <treffer>. "oder was auch immer du damit vorhast

Hierbei ist lv_suchfeld das Feld mit dem zu trennenden Ausdruck und ein zeichenartiges Feld, <treffer> type string und lt_treffer type table of string.

Die Variante mit dem Regulären Ausdruck ist eleganter, versteht aber nicht jeder (auch nicht jeder, der das mal warten muss), ich vermeide sowas in meinem Coding nach zahlreichen Beschwerden.

Re: Zeichenkette nach komma holen

Was bist du denn so unausgeglichen? Ich habe nicht gesagt, dass er es nicht verwenden soll, sondern lediglich angemerkt, dass es nicht jeder versteht. Der Alltag in SAP-Projekten ist, dass man da mit internen Entwicklern arbeitet, die einen Programmierstil haben, wie wir ihn noch gelernt haben. SELECT....ENDSELECT und dazwischen wird eine WRITE-Liste aufgebaut. Hatte ich gerade erst. Wenn du solchen Leuten mit OO oder Regex kommst, zeigen die dir nen Vogel. Ich lebe zu einem nicht geringen Anteil davon, Anwendungen zu entwickeln, die solche Internen mangels Kenntnissen in weitergehenden Programmierstilen nicht ausreichen. Ob das daran liegt, dass sie sich um eine Weiterbildung nicht bemühen oder daran, dass der Arbeitgeber sie nicht bewilligt, hängt vom Einzelfall ab und ist eigentlich auch nicht wichtig, denn ihren arbeitstechnischen Alltag kriegen sie ja hin.

Vergiss bitte nicht, dass viele Entwickler da draußen
• Vor Jahren ihre letzte Schulung hatten
• außer ABAP keine Programmiersprache kennen
• mit OO, Regex und anderen (aus ABAP-Sicht) neueren Techniken bisher nicht wirklich in Berührung kamen.

All das ist nicht schlimm, es ist nur nicht gut, das zu ignorieren, weil man dann am Bedarf vorbeientwickelt. Daher schrieb ich: Regex ist eleganter, split into tab aber wesentlich etablierter und verständlicher. Ich habe mehr als einen Kunden mit der Hausregel, dass solche "neueren Techniken" nur im Falle der faktischen Unvermeidbarkeit zu verwenden sind. Gerade habe ich ein paar ALV-Listen gestrickt, und dabei die REUSE-FuBaus verwendet. Der Kunde lebt lieber mit den Einschränkungen dieser Methode als mit einem Coding, den im Hause kein Mensch lesen kann.

Ich werde dabei auch nicht gefragt, ob ich das gut finde. Im Grunde kann ich denen aus der gleichen Codingvorlage auch einen OO-ALV mit allem Zipp und Zapp bauen. Wir reden hier aber über einen Kunden, dem ich erklären muss, dass Sortierung und Summierung nicht mit mir abgestimmt werden müssen, weil ich das nicht codiere, sondern es per Anzeigevariante flexibel gesteuert wird.

Nicht mehr aber auch nicht weniger als das wollte ich zu bedenken geben.

Ralf

Re: Zeichenkette nach komma holen

Hallo Ralf,

so wie du die Rahmenbedingungen im letzten Posting geschrieben hast, kann ich dich dann ja doch verstehen und stimme dir für deinen Fall voll zu.
Ich selber beschränke mich ja auch in vielen Fällen auf bestimmte Techniken.
Allerdings halte ich die "Hausregel" die du dort vorfindest schon für bedenklich. Auf kurze Sicht sicher die einfachste Lösung dafür zu sorgen, dass alle Programme lesbar und vom Kunden selber wartbar sind. Leider wird dabei übersehen, dass SAP selber immer mehr auf neuere Techniken umsteigt. Und wenn man nicht bei einfachen Entwicklungen mal übt mit den Neuerungen klarzukommen wird man über kurz oder lang auf der Strecke bleiben.
Und das regex in diesem Thread ist doch ein schönes Beispiel.
Es ist fast trivial für jemanden mit Erfahrung aber hinreichend komplex um die F1-Hilfe bemühen zu müssen wenn man vorher nie damit gearbeitet hat. Auch wenn derjenige der das sich nun beibringen muss das nicht sofort ( oder vielleicht auch nie ) selber anwenden muss, so weiß er dann ab dem Zeitpunkt wo er sich damit beschäftigt hat, dass es Alternativen gibt.
Das ist etwa vergleichbar mit dem ganzen Thread hier.
derkano hatte am Anfang nicht einmal einen Ansatz für sein Problem. Jetzt hat er mehrere Lösungsmöglichkeiten aufgezeigt bekommen und wird sich wohl oder übel mit der F1-Hilfe zu den Befehlen "SPLIT", "SHIFT" und "REPLACE" auseinandersetzen müssen, wobei er schon im Voraus weiß, dass jeder dieser Befehle letztlich seine Anforderungen erfüllen kann.
In Zukunft also hat er in ähnlich gelagerten Fällen die Wahl und kann (hoffentlich) das zum jeweiligen Problem passendste Verfahren anwenden.
Und das gilt eben auch für die Programmierer deines Hausregelprojektes.
Wenn sie sanft gezwungen würden sich ( allmählich - niemand erwartet Wunder ) mit den Neuerungen zu beschäftigen würden Sie auf längere Sicht davon profitieren.