Umherspringende Methoden im quelltextbasierten Class Builder
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Du schreibst nicht nur für dich, sondern auch für alle anderen, die deinen Code warten müssen. Wenn es nicht gerade Unternehmsvorgabe ist ausschließlich in Eclipse zu programmieren empfinde ich so eine Aussage als egoistisch und arrogant.
Bist du eigentlich jemals in einem Projekt gewesen, in dem du nicht deinen geliebten MacBook verwenden konntest sondern via Citrix oder RDP auf das Kundensystem geleitet wirst?
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
tar
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
So arbeite ich ständig -- MIT dem Macbook 😂black_adept hat geschrieben: ↑23.10.2024 14:44Du schreibst nicht nur für dich, sondern auch für alle anderen, die deinen Code warten müssen. Wenn es nicht gerade Unternehmsvorgabe ist ausschließlich in Eclipse zu programmieren empfinde ich so eine Aussage als egoistisch und arrogant.
Bist du eigentlich jemals in einem Projekt gewesen, in dem du nicht deinen geliebten MacBook verwenden konntest sondern via Citrix oder RDP auf das Kundensystem geleitet wirst?
Ich muss mich genauer ausdrücken: Ich verwende Eclipse, wenn es Unternehmensvorgabe ist und dann interessiert mich nicht, wie es in andere Editoren aussieht.
Wie das in Projekten ohne diese Unternehmensvorgabe ist, weiß ich nicht -- das hatte ich ewig nicht mehr.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Die haben wir offensichtlich. Aber dafür ist das Forum hier doch da, über unterschiedliche Auffassungen zu diskutieren und sich die Gründe anderer anzuhören, auch wenn diese nicht immer überzeugen. Das bereichert doch letztlich alle, und keiner von uns verlangt ja vom anderen, dass er auf Knien sein Unrecht eingestehen solle auch wenn es in diesem Fall sicherlich angemessen wäre 🤣 .black_adept hat geschrieben:@tar und D&P: Warum einigt ihr euch nicht einfach darauf, dass ihr halt unterschiedliche Auffassungen habt, was die Ästhetik der Codeformatierung angeht.
Das wäre ja schön, wenn die SAP an der Stelle was macht. Kann ja auch nicht so schwer sein.black_adept hat geschrieben:Vielleicht noch ein Hinweis zum irgendwo angesprochenen Pretty Printer: SAP schraubt hier andauernd dran rum, gerade was Einrückungen angeht. @D&P: Ich glaube mich zu erinnern, dass wenn man in sehr neuen Releases z.B. nach Exporting direkt in die gleiche Zeile den ersten Parameter schreibt bzw. den Zeilenumbruch manuell entsorgt, der PP den Rest nach dem gleichen Schema angleicht.
Nur ist das halt komplett überflüssig, wenn man sich an die Konvention hält, dass die Schlüsselspalte vorne steht. In meinen Augen ist das ohnehin notwendig: Wenn irgendwo in der Mitte der Spalten (womöglich nachdem man schon im Debugger nach rechts scrollen musste) LAGERORT.ID steht, dann ist das von der Lesbarkeit her trotzdem ganz großer Mist.tar hat geschrieben:Lagerort.Id - ja, was wird mit "Id" hier wohl gemeint sein? Genau: ein Fahrrad! 🤭
Weit mehr als die meisten anderen. Deswegen achte ich ja z.B. so darauf, dass meine Unterroutinen deterministisch ihr Verhalten anhand ihrer Parameter ausrichten und nicht anhand irgendwelcher zu "Attributen" oder "Zuständen" umgelabelter klassenglobaler Variablen. Und wie gesagt: Auch die SE38 bietet heutzutage (anders als in Backend-Editor-Zeiten) locker genug Platz, um auch lange Zeilen problemlos darzustellen. Nur im Debugger kann es mal eng werden - aber meist geht es da auch, und wenn nicht, schaut man sich das komplexere Konstrukt halt wahlweise in Eclipse oder in der SE38 an.tar hat geschrieben:Interessiert dich überhaupt, ob dein Code im ABAP-Editor noch irgendwie verständlich aussieht oder ist Eclipse dein einziger Maßstab?
Das ist bei meinen Routinen kein Problem. Einerseits gliedere ich sorgsam, habe also keine Methoden, die sich über unzählige Bildschirmseiten erstrecken und bei denen man den Überblick verliert, welche Werte woher kommen. Andererseits weil ich, wie gesagt, sprechend benenne unter Ausnutzung der erlaubten 30 Zeichen anstatt, wie fast alle anderen (insbesondere die Apologeten der ungarischen Notation) es machen, mit kurzen, wenig sprechenden Feldnamen von der Form lv_betrag zu arbeiten.tar hat geschrieben:Was ist eigentlich mit jenen, die deinen Code in 5 Jahren warten müssen? Die werden sich ganz besonders freuen, wenn sie erstmal herumscannen dürfen, was denn die notationsfreien Variablen genau für einen Typ (Werte, Strukturen, Tabellen oder Referenzen) haben, ob sie nur interne Hilfskonstrukte sind oder Eingabeparameter oder Rückgaben sind.
Ich behaupte, dass mein Code für andere Programmierer weit besser zu lesen und zu warten ist als der Durchschnitt. Immer vorausgesetzt, sie sind in der Lage, 7.40-Syntax zu lesen.
Also CLEAR zu verwenden ist die Empfehlung der SAP. REFRESH macht dasselbe, nur eindeutiger und ist insofern eher besser als schlechter verständlich. Auch [] ist eine syntaktisch eindeutige und damit per se leicht verständliche Notation.tar hat geschrieben:Wie kann man bzgl. interner Tabellen nur weiter mit [], Clear und Refresh hantieren!?
Dass diese Notationen ihren Ursprung darin haben, von Kopfzeilen abzugrenzen, ist richtig. Gleichwohl ist man keineswegs gezwungen, Kopfzeilen zu verwenden, wenn man diese Syntaxen einsetzt. [] hinter den Namen zu schreiben heißt nichts anderes als "ich meine die interne Tabelle". Das war damals wegen der Kopfzeilen erforderlich, aber die Aussage ist heute nicht weniger legitim. Und wie gesagt, tatsächlich braucht man es nur selten. Nahezu alle Befehle, die man in der Praxis auf interne Tabellen anwendet, machen von sich aus schon deutlich, dass es sich um eine interne Tabelle handeln muss.
Genauso sagt REFRESH nichts anderes aus als "Leere die folgende interne Tabelle". Weshalb man stattdessen den weniger eindeutigen Befehl CLEAR verwenden muss, erschließt sich mir nicht. Wenn ein Entwickler ernsthaft nicht mehr weiß, was REFRESH bedeutet, dann reicht einmal tippen auf F1, und schon hat er wieder was gelernt.
Nun ja, spätestens im Debugger hast Du eine editorähnliche Darstellung auf dem Schirm. Deswegen will ich da keine ABAPdoc-Grütze und dergleichen sehen.Ralf hat geschrieben:Nein. Ja. Ich öffne den Editor nichtmal mehr.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das behaupten alle 😉 Und alle haben gleich (un)recht, weil sie das subjektiv betrachten. Sprich: "Wenn jeder so denkt wie ich, versteht er mein Coding".DeathAndPain hat geschrieben: ↑24.10.2024 15:08Ich behaupte, dass mein Code für andere Programmierer weit besser zu lesen und zu warten ist als der Durchschnitt. Immer vorausgesetzt, sie sind in der Lage, 7.40-Syntax zu lesen.
Also, wenn man eine Tabelle mit Kopfzeilen vorfindet, hat man da keine Wahl, das ist richtig. Aber wenn man Tabellen definiert, sollte man von solchen mit Kopfzeilen die Finger lassen. Das heißt, dass man insbesondere in Funktionsbausteinen aufpassen muss, wo die ggf. implizit deklariert werden (TABLES-Parameter).DeathAndPain hat geschrieben: ↑24.10.2024 15:08Also CLEAR zu verwenden ist die Empfehlung der SAP. REFRESH macht dasselbe, nur eindeutiger und ist insofern eher besser als schlechter verständlich. Auch [] ist eine syntaktisch eindeutige und damit per se leicht verständliche Notation.tar hat geschrieben:Wie kann man bzgl. interner Tabellen nur weiter mit [], Clear und Refresh hantieren!?
Ich hab damit kein Problem, ABAPdoc zu sehen.DeathAndPain hat geschrieben: ↑24.10.2024 15:08Nun ja, spätestens im Debugger hast Du eine editorähnliche Darstellung auf dem Schirm. Deswegen will ich da keine ABAPdoc-Grütze und dergleichen sehen.Ralf hat geschrieben:Nein. Ja. Ich öffne den Editor nichtmal mehr.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wie schon vorher geschrieben. Es gibt den ABAP Cleaner als Addon für Eclipse. Der ist von der SAP. Genau wie Clean ABAP. Das ist der neue "Standard" anstelle des Pretty Printer.DeathAndPain hat geschrieben: ↑24.10.2024 15:08Das wäre ja schön, wenn die SAP an der Stelle was macht. Kann ja auch nicht so schwer sein.
Die SAP macht an der Stelle also sehr viel in letzter Zeit. Nur nicht im todgesagten SAP GUI =)
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Nein, das behaupten nicht alle. Den meisten geht es am Hintern vorbei. Wie irgend jemand hier im Forum vor gar nicht langer Zeit erläutert hat: Die meisten ABAP-Entwickler haben keine Ansprüche an die eigene Codequalität. Da wird irgendwas reingehackt, und wenn es (zunächst einmal) funktioniert, ist es gut genug.ralf.wenzel hat geschrieben: ↑24.10.2024 15:28Das behaupten alle 😉DeathAndPain hat geschrieben: ↑24.10.2024 15:08Ich behaupte, dass mein Code für andere Programmierer weit besser zu lesen und zu warten ist als der Durchschnitt. Immer vorausgesetzt, sie sind in der Lage, 7.40-Syntax zu lesen.
Ich habe nicht den Anspruch, dass mein Ansatz der einzig mögliche sein muss. Aber ich erwarte von jedem Ansatz, dass er erkennbar eine Struktur zeigt, die auch dann verständlich ist, wenn man den Code nicht kennt. Sprechende Namen und Parameter statt leerer Methoden- oder PERFORM-Schnittstellen sind da schon man ein guter Ansatz. Bei einem OO-Fan würde ich alternativ auch eine sorgsame Klassendoku nehmen, wahlweise online in der SE24 oder alternativ als Kommentar im Quellcode gepflegt, die genau erläutert, was für Attribute es gibt und wie sie verwendet werden. Sowas habe ich allerdings noch nie zu sehen bekommen.ralf.wenzel hat geschrieben: ↑24.10.2024 15:28Und alle haben gleich (un)recht, weil sie das subjektiv betrachten. Sprich: "Wenn jeder so denkt wie ich, versteht er mein Coding".
Ja, so ein paar Ecken gibt es noch. SELECT-OPTIONS liefert Dir auch eine Tabelle mit Kopfzeile.Ralf hat geschrieben:Also, wenn man eine Tabelle mit Kopfzeilen vorfindet, hat man da keine Wahl, das ist richtig. Aber wenn man Tabellen definiert, sollte man von solchen mit Kopfzeilen die Finger lassen. Das heißt, dass man insbesondere in Funktionsbausteinen aufpassen muss, wo die ggf. implizit deklariert werden (TABLES-Parameter).
Um ehrlich zu sein, verstehe ich das Gewese um die Kopfzeilen aber nicht so recht. Ich bin der Meinung, dass sie sich gut handhaben lassen, wenn man sie mal verstanden hat. Deswegen habe ich sie länger verwendet als die Allgemeinheit und bin erst von ihnen abgewichen, als die Inline-Deklaration von Feldsymbolen gekommen ist. Davor war es üblich, Workareas (typischerweise mit dem Namen wa_tabellenname) zu deklarieren. Das fand ich extrem unelegant und klobig, zumal diese Workareas ja auch erst per DATA deklariert werden mussten. Eine Kopfzeile bietet mir das alles frei Haus.
Nachdem es allerdings die Syntax ASSIGNING FIELD-SYMBOL gab und neue Zeilen einfach per VALUE erzeugt werden konnten, anstatt dafür eine Workarea-Variable zu benutzen, habe ich die Notwendigkeit nicht mehr gesehen. Feldsymbole sind eleganter als Workareas (auch wegen des unnötigen MODIFY table), und indem ich den Tabellenname mit Winkeln als (inline-deklarierten) Feldsymbolnamen nutze, ist der Bezug optisch leicht zu erkennen. Diese Lösung halte ich für besser als Kopfzeilen, also nutze ich sie.
Aber Kopfzeilen finde ich weit weniger schlimm als ihr Ruf. Sie erhöhen halt etwas die Lernkurve für ABAP-Neueinsteiger, das stimmt. Mein Eindruck ist aber, dass viele einfach zu dusslig sind, mit Kopfzeilen umzugehen und daher sagen, Kopfzeilen seien so schlecht.
Egal, so oder so sind sie Geschichte.
Hier werden wir uns definitiv uneinig bleiben, weil ich es während des Programmierens und Debuggens einfacher finde, Felder grundsätzlich nach alphabetischer Reihenfolge vorliegen zu haben (außer bei der ALV-Ausgabe, die die Fachbereiche vorgeben und die man wg. diverser Hilfsspalten ohnehin umsortieren muss). Diese Reihenfolge halte ich auch bei Methoden, Parametern und etwaig mehreren hintereinander zu deklarierenden Variablen ein.DeathAndPain hat geschrieben: ↑24.10.2024 15:08Nur ist das halt komplett überflüssig, wenn man sich an die Konvention hält, dass die Schlüsselspalte vorne steht. In meinen Augen ist das ohnehin notwendig: Wenn irgendwo in der Mitte der Spalten (womöglich nachdem man schon im Debugger nach rechts scrollen musste) LAGERORT.ID steht, dann ist das von der Lesbarkeit her trotzdem ganz großer Mist.
Statt CLEAR und REFRESH sollte man FREE verwenden.DeathAndPain hat geschrieben: ↑24.10.2024 15:08Also CLEAR zu verwenden ist die Empfehlung der SAP. REFRESH macht dasselbe, nur eindeutiger und ist insofern eher besser als schlechter verständlich.
Code: Alles auswählen.
Auch [] ist eine syntaktisch eindeutige und damit per se leicht verständliche Notation.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
FREE macht etwas anderes als CLEAR oder REFRESH und für viele Fälle geht FREE gar nicht.
Und alphabetische Reihenfolge von Feldern? Ernsthaft? Da kommt doch keiner drauf. Die wichtigsten Spalten gehören nach vorn und das sind die Keyfelder.
Ralf
Und alphabetische Reihenfolge von Feldern? Ernsthaft? Da kommt doch keiner drauf. Die wichtigsten Spalten gehören nach vorn und das sind die Keyfelder.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
DeathAndPain
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Welche denn?
Nö.ralf.wenzel hat geschrieben: ↑24.10.2024 21:17Die wichtigsten Spalten gehören nach vorn und das sind die Keyfelder.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
1. Sag ich ja, dass FREE was anderes macht als CLEAR. Es ging doch hier um interne Tabellen.
2. Weiß ich nicht aus dem Kopf, bin unterwegs. Ich meine, bei Objektinstanzen.
3. Doch. Schon deshalb, weil der Key die Sätze einer Tabelle unterscheidet. Da ist doch völlig abwegig, die Keyfelder zu verteilen.
Ralf
2. Weiß ich nicht aus dem Kopf, bin unterwegs. Ich meine, bei Objektinstanzen.
3. Doch. Schon deshalb, weil der Key die Sätze einer Tabelle unterscheidet. Da ist doch völlig abwegig, die Keyfelder zu verteilen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Lass mich dein Gedächtnis auffrischen:ralf.wenzel hat geschrieben: ↑24.10.2024 22:361. Sag ich ja, dass FREE was anderes macht als CLEAR. Es ging doch hier um interne Tabellen.
FREE leert - wie REFRESH - interne Tabellen und setzt zusätzlich den zugehörigen Speicherbereich frei. Ansonsten wirkt FREE wie CLEAR, weswegen man auch gleich durchweg FREE verwenden kann/sollte. REFRESH ist ohnehin obsolet.DeathAndPain hat geschrieben: ↑24.10.2024 15:08Also CLEAR zu verwenden ist die Empfehlung der SAP. REFRESH macht dasselbe, nur eindeutiger und ist insofern eher besser als schlechter verständlich. Auch [] ist eine syntaktisch eindeutige und damit per se leicht verständliche Notation.tar hat geschrieben:Wie kann man bzgl. interner Tabellen nur weiter mit [], Clear und Refresh hantieren!?
Die Nutzung der ungarischen Notation war ein weiterer Diskussionspunkt. Es ist nun leider nicht so, dass ich im ABAP Editor einfach mit der Maus über eine Variable oder Methode gehen kann, um deren Definition einzusehen (wie bspw. in Visual Studio) - es braucht immer erst einen nervigen Doppelklick (oder F2) zzgl. Rücksprung (oder F3), um das zu erfahren. Vielleicht ist das in Eclipse anders, aber eben kein allgemeiner Maßstab für ABAP.
Wenn ich da nun im Code erst herumsuchen müsste, ob und wie eine Variable geleert wird (wie bspw. CLEAR für Kopfzeilen 🤢), ob und wie sie übergeben und ob sie zurückgegeben wird, um schließlich festzustellen, welchen grundsätzlichen Typ und welche Verwendung ich vor mir habe, ist das ein überflüssiger Mehraufwand, den man mit der ungarischen Notation vermeidet.
Funktioniert problemlos:ralf.wenzel hat geschrieben: ↑24.10.2024 22:362. Weiß ich nicht aus dem Kopf, bin unterwegs. Ich meine, bei Objektinstanzen.
Code: Alles auswählen.
data(lo_instance) = new cl_gui_alv_grid( cl_gui_container=>default_screen ).
" ...
free lo_instance.Es gibt genau 1 Stelle, wo Primärschlüssel nach vorne gehören: auf der Datenbank (geht in SAP auch gar nicht anders). Selbst bei der Ausgabe liegen meist Hilfsspalten davor (Stichwort: Status-Icon). Im Code ist es jedoch völlig irrelevant, an welcher Stelle ein Schlüssel liegt.ralf.wenzel hat geschrieben: ↑24.10.2024 22:363. Doch. Schon deshalb, weil der Key die Sätze einer Tabelle unterscheidet. Da ist doch völlig abwegig, die Keyfelder zu verteilen.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Also macht FREE etwas anderes als CLEAR. Danke für die Zustimmung. Wenn ich den Speicherbereich NICHT freigeben will, dann sollte man auch NICHT free verwenden.
Und dabei hilft dir lt_ekko, was NICHT erklärt, was IN der Tabelle ist? EKKO sind Einkaufsbelegköpfe, Einkaufsbelege gibt es viele. Und da finde ich es einfach richtiger, in den Namen zu schreiben, dass es sich um Umlagerungsbestellungen (zum Beispiel) handelt statt der Struktur. Weil die Frage, WAS ich damit machen soll, hängt ja nicht an der Struktur, sondern am Inhalt.tar hat geschrieben: ↑25.10.2024 09:45Die Nutzung der ungarischen Notation war ein weiterer Diskussionspunkt. Es ist nun leider nicht so, dass ich im ABAP Editor einfach mit der Maus über eine Variable oder Methode gehen kann, um deren Definition einzusehen (wie bspw. in Visual Studio) - es braucht immer erst einen nervigen Doppelklick (oder F2) zzgl. Rücksprung (oder F3), um das zu erfahren. Vielleicht ist das in Eclipse anders, aber eben kein allgemeiner Maßstab für ABAP.
....sind deine Methoden zu unübersichtlich.
Es gibt genau 1 Stelle, wo Primärschlüssel nach vorne gehören: auf der Datenbank (geht in SAP auch gar nicht anders). Selbst bei der Ausgabe liegen meist Hilfsspalten davor (Stichwort: Status-Icon). Im Code ist es jedoch völlig irrelevant, an welcher Stelle ein Schlüssel liegt.ralf.wenzel hat geschrieben: ↑24.10.2024 22:363. Doch. Schon deshalb, weil der Key die Sätze einer Tabelle unterscheidet. Da ist doch völlig abwegig, die Keyfelder zu verteilen.
[/quote]
Das magst du so sehen. Und solange du nicht für mich programmierst, kannst du das auch so machen.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
DeathAndPain
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Was hat denn lt_EKKO mit der ungarischen Notation zu tun? Nenne es einfach "lt_umlagerungsbestellungen". 🙄ralf.wenzel hat geschrieben: ↑25.10.2024 10:17Und dabei hilft dir lt_ekko, was NICHT erklärt, was IN der Tabelle ist? EKKO sind Einkaufsbelegköpfe, Einkaufsbelege gibt es viele. Und da finde ich es einfach richtiger, in den Namen zu schreiben, dass es sich um Umlagerungsbestellungen (zum Beispiel) handelt statt der Struktur. Weil die Frage, WAS ich damit machen soll, hängt ja nicht an der Struktur, sondern am Inhalt.
🤢ralf.wenzel hat geschrieben: ↑24.10.2024 22:36Das magst du so sehen. Und solange du nicht für mich programmierst, kannst du das auch so machen.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Du hast die Ungarische Notation nicht verstanden. Die besagt, dass der Name den Typ des Objektes widerspiegelt. Der Zeilentyp von LT_EKKO ist EKKO, weshalb sie LT_EKKO heißen muss, wenn man der Ungarischen Notation folgt.
Danke für den sachlichen Hinweis.tar hat geschrieben: ↑25.10.2024 10:42🤢ralf.wenzel hat geschrieben: ↑24.10.2024 22:36Das magst du so sehen. Und solange du nicht für mich programmierst, kannst du das auch so machen.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Herr im Himmel - es geht natürlich nur um die Präfixe.ralf.wenzel hat geschrieben: ↑25.10.2024 10:45Du hast die Ungarische Notation nicht verstanden. Die besagt, dass der Name den Typ des Objektes widerspiegelt. Der Zeilentyp von LT_EKKO ist EKKO, weshalb sie LT_EKKO heißen muss, wenn man der Ungarischen Notation folgt.
Vergleichbare Themen
10
Antw.
Antw.
3184
Views
Views
3
Antw.
Antw.
5207
Views
Views
Interne Tabelle in Class Builder definieren
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
von mamaierhofer » 20.03.2007 16:14 • Verfasst in ABAP Objects®
5
Antw.
Antw.
6855
Views
Views
Abstrakte Methode im Class Builder anlegen
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
von jay-tee » 18.12.2006 14:22 • Verfasst in ABAP Objects®
5
Antw.
Antw.
3327
Views
Views
Class Builder: Default für Meth.param. gepackt mit Dezimalen
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
von Gast » 06.02.2006 13:57 • Verfasst in ABAP Objects®
0
Antw.
Antw.
2690
Views
Views
Solution Builder (Build Block Builder)
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module
von SAP_ENTWICKLER » 19.12.2018 09:59 • Verfasst in Sonstige Module
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Stunde von DeathAndPain 3 / 191
vor einer Stunde von DeathAndPain 3 / 191
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor einer Stunde von DeathAndPain 3 / 191
vor einer Stunde von DeathAndPain 3 / 191