Was ärgert Euch an ABAP?

[Madita2481]

Mich stört, dass

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: a,b,c TYPE i.

GeSHi ©

a) nicht funktioniert und
b) es aber auch keine richtige Fehlermeldung dafür gibt.

(Kann mich als Anfänger natürlich auch irren, aber den Fehler musste ich erst mal finden. )

[Willy1492]

Mich stört, dass

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: a,b,c TYPE i.

GeSHi ©

a) nicht funktioniert

Es funktioniert doch, nur anders als Du es evtl. von anderen Programmiersprachen gewohnt bist.
Bei Anweisungsketten haben die Anweisungen nur die Tokens vor dem ersten Doppelpunkt gemeinsam, die Tokens nach dem Doppelpunkt gehören jeweils nur einer Anweisung.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: a,b,c TYPE i.

GeSHi ©

entspricht also 3 Anweisungen:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA a.
2. DATA b.
3. DATA c TYPE i.

GeSHi ©

Die Variablen a und b werden dabei implizit mit Typ C und Länge 1 definiert.
Alles so dokumentiert.

b) es aber auch keine richtige Fehlermeldung dafür gibt.

Warum auch?
Das Beispiel ist ja syntaktisch korrekt.
Und die ABAP-Laufzeit-Umgebung kann ja nicht ahnen, dass Du eigentlich etwas anderes gemeint hast.

Kann mich als Anfänger natürlich auch irren, aber den Fehler musste ich erst mal finden.

Irgendwann gewöhnt man sich an die meisten Besonderheiten von ABAP.
Die Ketten-Anweisungen vereinfachen an anderer Stelle aber wirklich den Schreibaufwand, z.B.

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. PERFORM form_a USING field1: a 1, b 2, c 3.

GeSHi ©

statt

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. PERFORM form_a USING field1 a 1.
2. PERFORM form_a USING field1 b 2.
3. PERFORM form_a USING field1 c 3.

GeSHi ©

Und wenn Du den 2. Parameter in der FORM-Definition typisierst, meckert der Syntax-Check auch beim Versuch, einen falschen Typ im Aufruf zu verwenden.
Manchmal erschweren Ketten-Anweisungen aber auch die Lesbarkeit:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. DATA: field(10) TYPE c VALUE '1234567'.
2. SHIFT field RIGHT: DELETING TRAILING ' ',,BY 2 PLACES CIRCULAR.
3. * field enthält jetzt '56    1234'

GeSHi ©

Die einzige mir bekannte Stelle, an der die Syntax-Prüfung in dem Zusammenhang warnt, ist so etwas:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. UPDATE dbtab SET: field1 = 'X',
2.                   field2 = 'Y',
3.                   field3 = 'Z'
4.        WHERE fieldxy EQ space.

GeSHi ©

Das ist zwar syntaktisch auch korrekt, aber meist nicht gewollt, da nur die letzte der 3 UPDATE-Anweisungen eine WHERE-Klausel hat.

[Lucienne935]

Beim Anlegen einer neuen FORM-Routine benutze ich gerne die Möglichkeit, zuerst den PERFORM-Befehl zu codieren, und dann auf den Routinen-Namen doppelt zu klicken.

Und jetzt das Ärgernis:
wenn man mit Includes arbeitet (z.B. ein Forms-Include für einen Report), wird nicht der aktuelle Include zur Anlage der neuen Form vorgeschlagen, sondern das Rahmenprogramm.

Schön ist, dass die Parameter gleich mit angelegt werden. Toll wäre, würden auch die Typen der Parameter gleich mit übernommen werden. In der ABAP-Doku steht nämlich, dass typisierte Parameter wesentlich schneller sind als generische.[/code]

[ewx]

Und jetzt das Ärgernis:
wenn man mit Includes arbeitet (z.B. ein Forms-Include für einen Report), wird nicht der aktuelle Include zur Anlage der neuen Form vorgeschlagen, sondern das Rahmenprogramm.

Hi Jörg,

Wenn du dich an die SAP-Namensgebung für Modulpools hältst, dann wird immerhin für Form-Routinen immer das entsprechende Include verwendet.
Bsp:
- Rahmenprogramm: SAPMZTEST1
- Datendefinition: MZTEST1TOP
- Form-Routinen: MZTEST1F01
- PBO: MZTEST1O01
- PAI: MZTEST1I01

Gruß,
Enno

[florian]

...und hab ständig etwas, das mich auf die palme bringt. Finde nur nicht die zeit alles aufzuschreiben.
Im moment nervt mich, dass auch SAP unsinnigerweise meint ne eigene schriftart haben zu müssen, die obendrein nichteinmal dicktengleich ist!! (kenne keinen zweiten editor, wo das der fall ist).

Ausserdem hat mich gerade der folgende Fehler ziemlich fertig gemacht:
"Feld "GT_SELKRIT" unbekannt. Es ist weder in einer der angegebenen Tabellen enthalten noch durch eine "DATA"-Anweisung definiert."

Beim doppelklick auf die Variable hat die Workbench mich anstandslos zur entsprechenden Deklaration geführt.....

[Claudia264]

Hallo Leutz.

Was mich stört ist, dass die Zeilen auf 73 Zeichen beschränkt sind. Beim Programmieren ist das ja noch einigermaßen akzeptabel. Wenn man allerdings mit Formularen arbeitet und im Menü zwischen "Seite links/rechts" hin und her schalten muss, ist das schon sehr mühsam und ärgerlich.

mfg Andi

[Alva1590]

Hallo Leutz.

Was mich stört ist, dass die Zeilen auf 73 Zeichen beschränkt sind.

72 Zeichen, aber das wird mit Release 6.x besser.
(Wenn man mal einen Quelltext ausdrucken will,
ist man mit 72 Zeichen aber beser dran als mit 255.)

[Hayley540]

ich haette gerne wieder Zeilennummern in meinem Editor...
und der Punkt 'Bildschirmabgriff' bei der Einstellungsdrucktaste im Menue soll woanders hin. Ich weiss gar nicht wieviele Scrennshots ich dadurch schon ungewollt gedruckt habe!

[ewx]

Mich nervt, dass in der SE80 nur die Klassenimplementierung und Klassendefinition angezeigt werden, aber nicht die enthaltenen Methoden!
So, musste ich mal loswerden.

Gruß,
Enno

[Silke1341]

Mich nervt, dass in der SE80 nur die Klassenimplementierung und Klassendefinition angezeigt werden, aber nicht die enthaltenen Methoden!
So, musste ich mal loswerden.

Gruß,
Enno

ich vermute mal, dass Du damit lokale Klassen meinst.
Dem kann ich nur zustimmen.