Materialnotiz Button programmieren

Re: Materialnotiz Button programmieren

Moin LoW-RiDeR,

da sind ja wieder mehrere Baustellen.

1. Die Methode ACTIVATE_ADD_COLUMNS ist dazu da, dass die zusätzlichen Felder überhaupt eingeblendet werden und somit sichtbar sind. Der Text, der in diesen zusätlichen Spalten angezeigt wird wird in der Methode FILL_ADD_COLUMNS erzeugt. Da diese Zusatzfelder kaum lang genug sind, um die Materialnotiz anzuzeigen soll diese Methode lediglich herausfinden, ob so ein Text vorhanden ist und wenn ja soll ein Text angezeigt werden, sonst soll das Feld leer sein
2. Ob eine Materialnotiz vorhanden ist hast du ja herausgefunden. Dein aktuelles Coding macht das allerdings doppelt - einerseits direkt programmiert in der Methode FILL_ADD_COLUMNS und andererseits in der danach von dir aufgerufenen Methode ANGELWINGS_TO_DUST. Doppelt brauchst du das nicht machen, sondern du kannst einfach ein IF ANGELWINGS_TO_DUST( ... ) = abap_true. field_content = Info, dass materialnotiz existiert. ENDIF. schreiben.
3. Warum normalisierst du deine Materialnummer im Feld gv_matnr. Kommt die tatsächlich falsch von SAP im Feld MDKP-MATNR übergeben daher?
4. Wenn du die schon normalisieren musst, verwende den Konvertierungexit CONVERSION_EXIT_MATN1_INPUT. Es gibt diverse Firmen, die ihre Materialnummer anders aufbereiten oder gar intern darstellen ( mache eben auch ohne ALPHA-Konvertierung ), so dass du in Teufels Küche mit deiner Vorgehensweise kommst. Ich schätze, dass das in deiner Fa. ok ist - aber im allgemeinen eben nicht
5. Wofür die recht überflüssigen "FREE" Befehle am Ende der Methode? Wer hat dir denn das beigebracht?
6. Ich weiß ja nicht, ob in deiner Fa. Namenskonventionen herrschen. Aber ich schätze, dass der Name gv_matnr diesen nicht entspricht. Wenn doch, solltest du vorschlagen, die Namenskonventionen mal zu überarbeiten

Wie dem auch sei - du bist ja schon recht weit.
Melde dich wieder, wenn in der MD06 jetzt in einigen Zeilen die Information, dass eine Materialnotiz vorhanden ist, sichtbar ist oder wenn dir irgendwas noch nicht klar ist.

Re: Materialnotiz Button programmieren

Moin LoW-RiDeR,

warum rufst du immer noch die Methode ANGELWINGS_TO_DUST auf? Du hast die Entscheidung, welche in dieser Methode gekapselt ist doch schon in deinem Coding vorgesehen, denn nur dann wird doch der IF-Block angesprungen.

Aber ok - machen wir mal weiter.
Ich hatte dir am 1. Oktober vorgeschlagen dir ein Testprogramm zu bauen, welches die Methode DISPLAY_MATERIAL_MEMO aufrufen soll ( Punkt 5 ).
Da solltest du weitermachen, denn dann kannst du das Ganze zunächst außerhalb der MD06 austesten.

Eigentlich sollte ich dich das folgende selber rausfinden lassen - aber du musst ja mal irgendwann zu Ende kommen.
Daher hier die Info: Ruf ( aus deinem Testprogramm heraus ) den Funktionsbaustein MD_MATERIALNOTIZ auf und schaue, ob der das macht, was du brauchst.

Re: Materialnotiz Button programmieren

Moin LoW-RiDeR,

aktuell solltest du ( wenn du alles bisher richtig umgesetzt hast ) bei einem Doppelklick in der MD06 auf dem BREAK-POINT in der Methode ZCL_MD06_ENHANCEMENTS=>MD06_NAVIGATION landen und diese Methode hat 2 Eingabeparameter: Hast du dir die mal genauer im Debugger angeschaut, wenn du auf dem BREAK-POINT landest.
Vergleiche, was das drin steht, je nachdem ob du in der Liste auf dein Zusatzfeld oder ein Standardfeld doppelklickst.

Re: Materialnotiz Button programmieren

black_adept hat geschrieben: ↑

14.10.2021 15:03

Ich weiß ja nicht, ob in deiner Fa. Namenskonventionen herrschen. Aber ich schätze, dass der Name gv_matnr diesen nicht entspricht. Wenn doch, solltest du vorschlagen, die Namenskonventionen mal zu überarbeiten[/list]

Hi black_adept,

da es mir sonst keine Ruhe lässt, eine Frage am Rande: was spricht denn gegen den Namen "gv_matnr"?

Danke,
Murdock

Re: Materialnotiz Button programmieren

black_adept hat geschrieben: ↑

27.10.2021 17:05

Der Screenshot mit dem Codeauszug, welcher die Variable gv_matnr enthält ist der für die Methode "interface~FILL_ADD_COLUMNS".
Alle dort definierten Variablen haben einen Vorsatz lv_ oder gv_ was auf die ungarische Notation hindeutet.
gv_matnr ist eine dieser innerhalb dieser Methode definieren Variablen und somit eine lokale Variable wohingegen der Vorsatz "gv_" auf eine globale Variable hindeutet.

Ach so, alles klar. ich dachte Du störst dich generell an der ungarischen Notation oder hier an dem Suffix "matnr".

Re: Materialnotiz Button programmieren

Ich bin genauso wenig Fan der ungarischen Notation wie Ralf, sehe es aber zugleich auch wie black_adept: Wenn man sie schon verwendet, dann sollte sie wenigstens stimmen, sonst gehen jegliche Argumente, die für ihre Verwendung sprechen, den Bach runter. Das habe ich bei Codes anderer Leute leider schon zu oft gesehen, dass blind alle Variablen mit lv_ beginnen, egal on sie lokal, global oder Im/Exportparameter sind. Da merkt man dann, dass der Betreffende nicht mal mehr verstanden hat, was er da eigentlich tut, sondern blind lv_ schreibt, weil er es bei anderen so gesehen hat. Und dann ist dieses Präfix definitiv nur noch Wasserkopfmüll.

black_adept hat geschrieben: ↑

27.10.2021 17:05

...ist es Usus, lokale Variablen mit "l" und globale Variablen mit "g" ( oder globale Klassenattribute mit "m" (= member)) beginnen zu lassen.

Das ist ja gerade das Verlogene an der objektorientierten Programmierung: "globale Klassenattribute" sind bei Licht betrachtet nichts anderes als globale Variablen der Klasse. Mit dem Verweis auf die Tugendhaftigkeit von OO als Ausrede wird von sauberer Parametrisierung der Unterprogramme abgewichen und wieder wie in grauer Programmiersteinzeit als "Attribute" verbrämte globale Variablen verwendet, mit all den damit verbundenen Nachteilen, dass man nämlich, wenn man ein Stück Code anschaut, rätselraten darf, wo deren Wert herkommt und wo er nachher hingeht. Ich habe schon bei mehr als einem Programmierer Programme gesehen, deren Hauptprogramm nicht mehr als eine Kette parameterloser (!) Methodenaufrufe war und man dann anfangen durfte zu forschen, auf welche Weise diese Methoden zusammenhängen bzw. welche Daten von wo nach wo laufen (oder anders ausgedrückt: wie das Programm überhaupt arbeitet). Das macht es unendlich viel schwerer, einen Fehler zu finden oder den Code zu erweitern. Was man da an Zeit verbrennt, ist locker das Tausendfache der Zeit, die es den ursprünglichen Programmierer gekostet hätte, seine Methoden diszipliniert zu parametrisieren.

Den Vorsatz "m" kenne ich eigentlich nur als globalen REF TO DATA, wo dann dynamisch eine globale Variable gefüllt wird. Aber das habe ich bislang nur selten gesehen und bin mir daher nicht sicher, ob es "offiziell" so definiert ist.

Re: Materialnotiz Button programmieren

Mit dem 2. Teil kann ich nur sagen: Wer so was schreibt, wird in Reports genau so einen Mist verzapfen.

Du machst den Fehler, rational zu denken. 😜 Das tun die Leute aber nicht, sondern folgen Prinzipien, die ihnen eingehämmert worden sind. Bei klassisch-prozeduraler Programmierung bestehen diese Prinzipien aus: "Globale Variablen sind böse und sollten nicht benutzt werden. Verwende stattdessen Parameter!" Also machen die Leute das.

Bei OO-Programmierung wird hingegen gepredigt: "In Attributen wird der Zustand des Objektes festgehalten. Sie sind gut, gegen ihre Nutzung ist nichts einzuwenden, da man an ihnen immer den Zustand des Objektes ablesen kann." Was davon hängenbleibt, ist: "Attribute sind gut und dürfen benutzt werden." Also machen die Leute das. (Und was man alles als "zum Zustand des Objektes gehörig" betrachtet, ist eine hervorragend dehnbare Ansichtssache.)

OO war mal lieb gemeint. Man kann damit ganz tolle Sachen machen. Aber: Das Gros der Entwickler ist mit den dahinterstehenden Konzepten überfordert. Sie haben die dahinterstehenden Philosophien schlicht und ergreifend nicht ausreichend kapiert. Vielleicht ist das auch ein Problem mangelhafter Lehre, kann schon sein.

Aber das Endergebnis sieht so aus, dass die Masse des vorhandenen OO-Codes erheblich schwerer zu verstehen und zu warten ist als der prozedurale Code. Und zwar auch bei Anforderungen, bei denen man die Spezialitäten von OO wie Abstrahierung usw. überhaupt nicht braucht (und das ist die Masse). Ich verweise auf mein Lieblingszitat, das ich mal irgendwo gelesen habe: "I don’t know the answer but I do know that debugging what happens after pressing a command in VA01 is easier to follow than the equivalent in ME21N. Or is that just because I am an OO novice?"

Und damit bin ich der Meinung, ein mächtiges Werkzeug, mit dem kaum einer richtig umgehen kann, aber trotzdem alle arbeiten (mit den entsprechend pfuschligen Ergebnissen) wirkt sich in der Praxis schlechter aus als ein einfacher strukturiertes, dessen richtige Verwendung in den Köpfen zumindest zu einem erheblich größeren Anteil ankommt. Und selbst wenn man es verstanden hat: bei einer Aufgabe, bei der die größere Mächtigkeit des komplexeren Werkzeugs keine Vorteile bringt, ist das einfachere Werkzeug - die Formroutine - leichter zu schreiben und leichter zu verstehen als die Methode mit ihrem Klassenoverhead. Deswegen nutze ich sie noch immer gerne und baue nur dort Klassen und Methoden, wo sie aus meiner Sicht Vorteile versprechen, anstatt es aus ideologischen Gründen immer zu tun.