Lange Texte im Tabellenpflegegenerator
Beitrag
von DeathAndPain (Top Expert / 1970 / 264 /
415
)
»
Hallo zusammen,
in einer eigenen Customizingtabelle möchte ich gerne lange Texte hinterlegen. Optimalerweise als Datentyp STRING, notfalls würde auch ein langes CHAR-Feld gehen.
Der SE11-Tabellenpflegegenerator kann jedoch nicht mit Tabellen umgehen, die Stringfelder enthalten, und bei CHAR-Feldern geht es im Dynpro maximal bis 255 Zeichen. Selbst die "Rollbar"-Funktionalität erlaubt es nicht, im vom Tabellenpflegegenerator erzeugten Table Control längere Texte einzugeben.
Kennt jemand eine Lösung, wie ich das zum Laufen bekomme, oder bedeutet das, dass ich ein passendes Pflegeprogramm für die Tabelle komplett von Hand schreibe? Und wenn ich es komplett von Hand schreiben muss, wie kriege ich dann die Anbindung ans Transportsystem hin (also dass er beim Sichern einen passenden Transportauftrag verlangt und darin einen entsprechenden Eintrag anlegt)?
in einer eigenen Customizingtabelle möchte ich gerne lange Texte hinterlegen. Optimalerweise als Datentyp STRING, notfalls würde auch ein langes CHAR-Feld gehen.
Der SE11-Tabellenpflegegenerator kann jedoch nicht mit Tabellen umgehen, die Stringfelder enthalten, und bei CHAR-Feldern geht es im Dynpro maximal bis 255 Zeichen. Selbst die "Rollbar"-Funktionalität erlaubt es nicht, im vom Tabellenpflegegenerator erzeugten Table Control längere Texte einzugeben.
Kennt jemand eine Lösung, wie ich das zum Laufen bekomme, oder bedeutet das, dass ich ein passendes Pflegeprogramm für die Tabelle komplett von Hand schreibe? Und wenn ich es komplett von Hand schreiben muss, wie kriege ich dann die Anbindung ans Transportsystem hin (also dass er beim Sichern einen passenden Transportauftrag verlangt und darin einen entsprechenden Eintrag anlegt)?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Tja, das ist leider eine große Schwachstelle in SAP-Systemen...
Traditionsgemäß werden "Standardtexte" mit SO10 erstellt, in eine Customizingtabelle eingetragen und dann werden die Einträge über Standardcustomizing transportiert und die Texte selber über Report RSTXTRAN.
Wenn du die Langtextpflege selbst programmierst, kannst du dich hieran orientieren:
https://www.tricktresor.de/blog/tabelle ... aufnehmen/
Ich bin mir aber gar nicht sicher, das Transportsystem Strings in dieser Form überhaupt unterstützt oder ob es dann einen Fehler gibt.
Traditionsgemäß werden "Standardtexte" mit SO10 erstellt, in eine Customizingtabelle eingetragen und dann werden die Einträge über Standardcustomizing transportiert und die Texte selber über Report RSTXTRAN.
Wenn du die Langtextpflege selbst programmierst, kannst du dich hieran orientieren:
https://www.tricktresor.de/blog/tabelle ... aufnehmen/
Ich bin mir aber gar nicht sicher, das Transportsystem Strings in dieser Form überhaupt unterstützt oder ob es dann einen Fehler gibt.
Beitrag
von DeathAndPain (Top Expert / 1970 / 264 /
415
)
»
Vielen Dank, das hilft mir schon weiter.
Aber selbst, wenn es gar nicht geht, kann ich mich über CHAR mit 800 Zeichen Länge retten; die langen mir. Blöd wird nur die Programmierung des Pflegedialogs. Da werde ich dann wohl im Dynpro Strings haben müssen, die ich für die Datenbank dann in CHAR konvertieren muss. Außerdem ist das Ganze natürlich aufwendig.
SSTRINGs würden mir schon reichen; die taugen ja sogar für Tabellenschlüssel.Ich bin mir aber gar nicht sicher, das Transportsystem Strings in dieser Form überhaupt unterstützt oder ob es dann einen Fehler gibt.
Aber selbst, wenn es gar nicht geht, kann ich mich über CHAR mit 800 Zeichen Länge retten; die langen mir. Blöd wird nur die Programmierung des Pflegedialogs. Da werde ich dann wohl im Dynpro Strings haben müssen, die ich für die Datenbank dann in CHAR konvertieren muss. Außerdem ist das Ganze natürlich aufwendig.
In Dynpros kannst du Strings nicht verwenden.
Du musst sie mit Hilfe des Controls CL_GUI_TEXTEDIT darstellen.
Du musst sie mit Hilfe des Controls CL_GUI_TEXTEDIT darstellen.
Beitrag
von DeathAndPain (Top Expert / 1970 / 264 /
415
)
»
Das halte ich für ein Gerücht. Das entsprechende Table Control habe ich soeben angelegt.In Dynpros kannst du Strings nicht verwenden.
Und wie viele Zeichen kannst du eingeben?
132 Zeichenewx hat geschrieben:Und wie viele Zeichen kannst du eingeben?
https://help.sap.com/doc/abapdocu_752_i ... fields.htmSAP Doku hat geschrieben:Da ein Dynpro-Feld maximal 132 Zeichen lang sein kann, können maximal 132 Zeichen bzw. Bytes einer Zeichen- bzw. Bytefolge an das Dynpro transportiert werden.
Beitrag
von DeathAndPain (Top Expert / 1970 / 264 /
415
)
»
Es stimmt nicht, was Du sagst. Das Feld kann doch in seiner visiblen Länge auf dem Dynpro schon länger sein als 132 Zeichen, dazu noch rollbar und damit als Stringfeld von unbegrenzter Länge (deswegen ist im Layout-Editor das Feld "def. Länge" auch leer und ausgegraut, wohingegen das Feld "vis.Länge" mit der Spaltenbreite im Dynpro gefüllt ist).
Gerade habe ich in ein solches Feld meines (per Wizard angelegten) Table Controls 170 Zeichen eingegeben. Anschließend habe ich den Debugger gestartet und diese 170 Zeichen auch tatsächlich in der internen Tabelle vollzählig wiedergefunden.
Gerade habe ich in ein solches Feld meines (per Wizard angelegten) Table Controls 170 Zeichen eingegeben. Anschließend habe ich den Debugger gestartet und diese 170 Zeichen auch tatsächlich in der internen Tabelle vollzählig wiedergefunden.
Das sage ich ja nicht, sondern die SAP-Doku! 
Aber gut zu wissen, dass auch STRING dargestellt und bearbeitet werden kann.
Da hat sich in den letzten GUI-Versionen wahrscheinlich auch einiges getan.
Ich kann mich erinnern, dass ich Probleme mit Strings auf Dynpros hatte.
Aber gut zu wissen, dass auch STRING dargestellt und bearbeitet werden kann.
Da hat sich in den letzten GUI-Versionen wahrscheinlich auch einiges getan.
Ich kann mich erinnern, dass ich Probleme mit Strings auf Dynpros hatte.
Beitrag
von DeathAndPain (Top Expert / 1970 / 264 /
415
)
»
Vor allem geht es sogar im Table Control. Das ist keine Selbstverständlichkeit: Gerade vor ein paar Tagen habe ich erst geflucht, weil ich eine Passworttabelle pflegbar machen und dabei die Passwörter aussternen sollte. Ein entsprechendes Feld-Flag im Layouteditor gibt es ja ("unsichtbar"), nur kann man es bei Table Control-Feldern nicht benutzen.
Beitrag
von black_adept (Top Expert / 4134 / 131 /
956
)
»
Warum sollte das nicht gehen? LOOP AT SCREEN verwendenDeathAndPain hat geschrieben:Ein entsprechendes Feld-Flag im Layouteditor gibt es ja ("unsichtbar"), nur kann man es bei Table Control-Feldern nicht benutzen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von DeathAndPain (Top Expert / 1970 / 264 /
415
)
»
Weil der entsprechende Haken im Layout Editor bei Table Control-Feldern ausgegraut ist.Warum sollte das nicht gehen?
Netter Schleichweg. Hätte ich auch drauf kommen können.LOOP AT SCREEN verwenden
Na ja, dass ich ihn nicht gesehen habe, hat dazu geführt, dass ich mir einen kreativen Workaround ausgedacht habe, auf den ich auch stolz bin:o Ich stelle das Passwortfeld der internen Tabelle nicht mehr im Table Control dar.
o Stattdessen stelle ich im Table Control eine mit "Passwort" überschriebene Spalte dar, die es in der internen Tabelle gar nicht gibt. Diese definiere ich als Dropdown mit den möglichen Werten "******" und "Passwort ändern". Da es die Spalte in der internen Tabelle, die dem Table Control zugrundeliegt, nicht gibt, kommt das Feld bei allen Zeilen defaultmäßig mit dem ersten Wert der VRM_VALUES, also mit "******" hoch. Das steht also bei allen Zeilen der Liste.
o Außerdem hinterlege ich an dem Dropdown einen OKCODE. Wird dieser bei einem Feld des Table Controls ausgeführt (was nur geht, indem der Benutzer im Dropdown den alternativen Wert "Passwort ändern" wählt), dann habe ich bei der Auswertung des OKCODEs die Zeile der Tabelle. Ich rufe einen modalen Subscreen mit zwei ausgesternten Nicht-Tablecontrol-Feldern, die identisch einzutippen sind. Wenn der Benutzer das gemacht hat, wird die Passwort-Spalte der entsprechenden Zeile internen Tabelle (die es, wie gesagt, im Table Control gar nicht gibt) entsprechend aktualisiert.
o Der Dropdown springt anschließend (im Rahmen des neuen PBO) wieder auf den Wert "******" zurück, da es ja kein Quellfeld in der internen Tabelle dafür gibt, so dass die vom Benutzer vorgenommene Auswahl keinen Bestand haben kann.
Kannste sagen, was Du willst: das war kreativ. Wer hätte gedacht, dass man produktiv mit Table Control-Spalten ohne zugehöriges Feld in der internen Tabelle arbeiten kann?
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
Und intuitiv verwendbar scheint es obendrein zu sein, weil man mit den zwei Passwortfeldern Verwechslungen bei der Eingabe vorbeugen kann.
Muss ich mir merken
Muss ich mir merken
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 / 1970 / 264 /
415
)
»
Na ja, dass man ein unsichtbares Passwort doppelt eingeben muss, ist jetzt keine neue Innovation, die ich mir als meine Leistung an die Brust heften wollte. Dafür hätte man auch mit ausgesterntem Table Control-Feld eine Lösung finden können. Ich hätte das wahrscheinlich so gemacht, dass ich in der internen Tabelle eine weitere unsichtbare Spalte für das erneut eingegebene Passwort eingefügt hätte. Die Lösung, die ich jetzt habe, ist noch schöner, war aber auch deutlich aufwendiger zu bauen (zumal ich mir vorher nicht ganz sicher war, ob das so überhaupt hinhauen würde), und die Lösung mit der Zweitspalte im Table Control hätte wahrscheinlich ausgereicht.
Beitrag
von black_adept (Top Expert / 4134 / 131 /
956
)
»
Die Lösung mit dem modalen Screen ist schöner als das Pflegen in der Tabelle, da so (falls später mal benötigt) auch einzeln berechtigt werden kann, was im TC zwar auch möglich aber dennoch weniger intuitiv gewesen wäre.
Aber eine Frage zur Dropdownbox: Was du da implementiert hast ist die Funktionalität einer Drucktaste - mit dem Unterschied, dass der User etwas mehr klicken muss. Kann in gewissen Situationen durchaus gewollt sein - besonders wenn man viele User hat die sehr "Trigger-Happy" sind. Hier auch?
Aber eine Frage zur Dropdownbox: Was du da implementiert hast ist die Funktionalität einer Drucktaste - mit dem Unterschied, dass der User etwas mehr klicken muss. Kann in gewissen Situationen durchaus gewollt sein - besonders wenn man viele User hat die sehr "Trigger-Happy" sind. Hier auch?
Vergleichbare Themen
6
Antw.
Antw.
12942
Views
Views
4
Antw.
Antw.
2457
Views
Views
0
Antw.
Antw.
1312
Views
Views
Modifikation im Tabellenpflegegenerator / Tabellenpflege
von olli-x » 11.08.2006 14:48 • Verfasst in ABAP® Core
von olli-x » 11.08.2006 14:48 • Verfasst in ABAP® Core
17
Antw.
Antw.
14754
Views
Views
SAPMV45A USEREXIT Itab Pos.Texte / Head Texte
von Luigi91 » 31.01.2014 09:31 • Verfasst in ABAP® für Anfänger
von Luigi91 » 31.01.2014 09:31 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
3390
Views
Views
Konvertierug vom datentyp char der länge 4 in char der länge
von ratoshuan » 28.06.2006 11:33 • Verfasst in ABAP® Core
von ratoshuan » 28.06.2006 11:33 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
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
Unbeantwortete Forenbeiträge
Nutzung UserExit COOM0003 für Abrechnungsvorschriften Aufträge
vor 6 Tagen von fico_fschluesener 1 / 1000
vor 6 Tagen von fico_fschluesener 1 / 1000