Größenänderung CustomControl
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo,
wir haben hier eine Anwendung mit einem normalen Dynpro, auf dem 5 Customcontrols mit jeweils einem Textcontroll sowie IO-Felder, Rahmen usw. enthalten sind.
Nun sollen alle Textcontrols per Button in der Höhe verändert werden. (Standard 5 Zeilen sichtbar, dann 20 Zeilen sichtbar).
Irgendwie habe ich keinen Plan, wie ich das realisieren kann. Denn obwohl die Customcontrols auf Resize stehen behalten sie stur ihren Wert.
Selbst bei meiner Testapplikation mit 2 Buttons, einer Textzeile, einem Customcontrol und einer weiteren Textzeile habe ich - trotz resize und keinem eingebundenen Control immer die "Originalhöhe" belegt (größer als die vorgegebene minimale Höhe).
Wie ist der richtige Ansatz? Wo kann ich auf die Höhe Einfluss nehmen?
MfG
Thomas R
[attachment=0]CC.png[/attachment.]
wir haben hier eine Anwendung mit einem normalen Dynpro, auf dem 5 Customcontrols mit jeweils einem Textcontroll sowie IO-Felder, Rahmen usw. enthalten sind.
Nun sollen alle Textcontrols per Button in der Höhe verändert werden. (Standard 5 Zeilen sichtbar, dann 20 Zeilen sichtbar).
Irgendwie habe ich keinen Plan, wie ich das realisieren kann. Denn obwohl die Customcontrols auf Resize stehen behalten sie stur ihren Wert.
Selbst bei meiner Testapplikation mit 2 Buttons, einer Textzeile, einem Customcontrol und einer weiteren Textzeile habe ich - trotz resize und keinem eingebundenen Control immer die "Originalhöhe" belegt (größer als die vorgegebene minimale Höhe).
Wie ist der richtige Ansatz? Wo kann ich auf die Höhe Einfluss nehmen?
MfG
Thomas R
[attachment=0]CC.png[/attachment.]
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4096 / 128 /
940
)
»
Hallo Thomas,
der mir bekannnte Weg so etwas zu realisieren ist folgendermaßen:
1.) 2 Screens - einer mit kleinen, einer mit großen CustomContainern.
2.) Beim Ändern der Größe auf den anderen Screen umschalten und deine Textedits mittels RELINK auf den neuen Screen binden.
der mir bekannnte Weg so etwas zu realisieren ist folgendermaßen:
1.) 2 Screens - einer mit kleinen, einer mit großen CustomContainern.
2.) Beim Ändern der Größe auf den anderen Screen umschalten und deine Textedits mittels RELINK auf den neuen Screen binden.
Beitrag
von black_adept (Top Expert / 4096 / 128 /
940
)
»
Hi Thomas,
ich fürchte fast dass du recht hast. Wenn du dir z.B. die Transaktion ME23N ( Bestellungen) anschaust wirst du sehen, dass SAP genau diese Technik selber verwendet um so ein Verhalten zu erzeugen. Schau dir doch in der FuGr MEGUI mal die Screens 13,19 und wahrscheinlich die Nummern dazwischen auch an. Da findest du genau die diversen "Aufklappstatus" der 3 Bereiche Kopf, Positionsübersicht, Positionsdetails .
ich fürchte fast dass du recht hast. Wenn du dir z.B. die Transaktion ME23N ( Bestellungen) anschaust wirst du sehen, dass SAP genau diese Technik selber verwendet um so ein Verhalten zu erzeugen. Schau dir doch in der FuGr MEGUI mal die Screens 13,19 und wahrscheinlich die Nummern dazwischen auch an. Da findest du genau die diversen "Aufklappstatus" der 3 Bereiche Kopf, Positionsübersicht, Positionsdetails .
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Thomas R.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Hi
Meine Empfehlung (da ich mit RELINK schlechte Erfahrungen gemacht habe):
1) Das Dynpro in Teilbereiche aufteilen.
Jeder Editor ist ein Block. Zusammengehörige Eingabefelder bilden einen eigenen Block.
Wichtig ist, dass diese Blöck in einem Punkt unterscheidbar sind: Fixe vs. variable Größe.
Sie dürfen sich aber auch nicht überschneiden.
Die Dynpros der Editoren bzw. die Custom-Container darin sind entsprechend mit resizing versehen.
2) Erzeugen eines "Trägerdynpros" mit Subscreenbereichen.
Die jeweiligen Teildynpros werden in die entsprechenden Bereich eingebunden.
Diese Trägerdynpro kopiert man dann so oft man eine untershiedliche Anordnung (Größe) haben möchte und passt das Layout dann entsprechend an.
3) Erzeugen eines Hauptdynpros mit einem großen Subscreenbereich.
Im PBO in der CALL SUBSCREEN Anweisung wird das Dynpro über eine Variable bestimmt.
Je nachdem welchen Wert diese Variable nun hat, wird immer ein anderes Trägerdynpro verwendet. Man muss nichts neu instanzieren oder mehrere verschiedene Objektinstanz verwenden. Die Felder und Controls bleiben außerdem ihren jeweiligen Dynpros "treu". Man muss die Felder nicht doppelt warten.
lg ADT
Meine Empfehlung (da ich mit RELINK schlechte Erfahrungen gemacht habe):
1) Das Dynpro in Teilbereiche aufteilen.
Jeder Editor ist ein Block. Zusammengehörige Eingabefelder bilden einen eigenen Block.
Wichtig ist, dass diese Blöck in einem Punkt unterscheidbar sind: Fixe vs. variable Größe.
Sie dürfen sich aber auch nicht überschneiden.
Die Dynpros der Editoren bzw. die Custom-Container darin sind entsprechend mit resizing versehen.
2) Erzeugen eines "Trägerdynpros" mit Subscreenbereichen.
Die jeweiligen Teildynpros werden in die entsprechenden Bereich eingebunden.
Diese Trägerdynpro kopiert man dann so oft man eine untershiedliche Anordnung (Größe) haben möchte und passt das Layout dann entsprechend an.
3) Erzeugen eines Hauptdynpros mit einem großen Subscreenbereich.
Im PBO in der CALL SUBSCREEN Anweisung wird das Dynpro über eine Variable bestimmt.
Je nachdem welchen Wert diese Variable nun hat, wird immer ein anderes Trägerdynpro verwendet. Man muss nichts neu instanzieren oder mehrere verschiedene Objektinstanz verwenden. Die Felder und Controls bleiben außerdem ihren jeweiligen Dynpros "treu". Man muss die Felder nicht doppelt warten.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Thomas R.
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
Hallo,
umgesetzt habe ich den Vorschlag von ADT, da damit kein Umswitchen von Controls notwendig wird. Funktioniert prima (Auch wenn ich - wegen 4 Resizing Blöcken - 16 verschiedene (Sub)Trägerdynpros benötige).
Die gesamte Programmlogik zum Füllen/Auswerten kann ich - bis auf eine sehr applikationsspezifische Kleinigkeit - unverändert übernehmen.
MfG
Thomas R.
umgesetzt habe ich den Vorschlag von ADT, da damit kein Umswitchen von Controls notwendig wird. Funktioniert prima (Auch wenn ich - wegen 4 Resizing Blöcken - 16 verschiedene (Sub)Trägerdynpros benötige).
Die gesamte Programmlogik zum Füllen/Auswerten kann ich - bis auf eine sehr applikationsspezifische Kleinigkeit - unverändert übernehmen.
MfG
Thomas R.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Vorteil:
Freut mich wenn ich helfen konnte.
btw. Welches Basis-Release habt ihr? 7.02? Da gäbe es auch noch sog. Dynpro-Splitter mit denen man das Dynpro in zwei getrennte Bereiche aufteilen kann und deren Größe kann man zur Laufzeit verändern (siehe neuer ABAP-Debugger)
http://help.sap.com/abapdocu_702/de/abe ... l_spcl.htm
Nachteil:Thomas R. hat geschrieben:Die gesamte Programmlogik zum Füllen/Auswerten kann ich ... unverändert übernehmen.
Thomas R. hat geschrieben:Auch wenn ich - wegen 4 Resizing Blöcken - 16 verschiedene (Sub)Trägerdynpros benötige
Freut mich wenn ich helfen konnte.
btw. Welches Basis-Release habt ihr? 7.02? Da gäbe es auch noch sog. Dynpro-Splitter mit denen man das Dynpro in zwei getrennte Bereiche aufteilen kann und deren Größe kann man zur Laufzeit verändern (siehe neuer ABAP-Debugger)
http://help.sap.com/abapdocu_702/de/abe ... l_spcl.htm
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
Hallo ADT,
die Verwendung eines Splitter-Controls klingt verlockend.
Aber bei unserem 7.01 (SAP_BASIS/SAP_ABA) finde ich leider keine Möglichkeit den Splitter einzubauen.
Im alphanumerischen Screen Painter über Bearbeiten → Anlegen Element habe ich leider keinen Eintrag 'Splitter Control' - und auch sonst finde ich nichts.
Dabei spricht die Hilfe
http://help.sap.com/erp2005_ehp_04/help ... ameset.htm
vom Splitter Container. Und ECC6.04 haben wir im Einsatz.
Die Klasse CL_GUI_SPLITTER_CONTAINER ist auch vorhanden.
Hast Du eine Ahnung, ob Kunden erst ab 7.02 den Splitter verwenden können oder vielleicht auch nur, welches Brett gerade meine Sicht einschränkt?
MfG
Thomas R.
Edit:
In der ABAP-Docu auf unserem System endet die Verweisliste
ABAP-Schlüsselwortdokumentation → ABAP - Referenz → Benutzerdialoge → Dynpros → Anweisungen der Dynpro-Ablauflogik → Subscreens, Tabstrip und Splitter Controls →
mit
ABAP-Schlüsselwortdokumentation → ABAP - Referenz → Benutzerdialoge → Dynpros → Anweisungen der Dynpro-Ablauflogik → Subscreens und Tabstrip Controls→
Ein eigentlich gutes Indiz, dass es bei uns kein Splitter für Kunden gibt.
die Verwendung eines Splitter-Controls klingt verlockend.
Aber bei unserem 7.01 (SAP_BASIS/SAP_ABA) finde ich leider keine Möglichkeit den Splitter einzubauen.
Im alphanumerischen Screen Painter über Bearbeiten → Anlegen Element habe ich leider keinen Eintrag 'Splitter Control' - und auch sonst finde ich nichts.
Dabei spricht die Hilfe
http://help.sap.com/erp2005_ehp_04/help ... ameset.htm
vom Splitter Container. Und ECC6.04 haben wir im Einsatz.
Die Klasse CL_GUI_SPLITTER_CONTAINER ist auch vorhanden.
Hast Du eine Ahnung, ob Kunden erst ab 7.02 den Splitter verwenden können oder vielleicht auch nur, welches Brett gerade meine Sicht einschränkt?
MfG
Thomas R.
Edit:
In der ABAP-Docu auf unserem System endet die Verweisliste
ABAP-Schlüsselwortdokumentation → ABAP - Referenz → Benutzerdialoge → Dynpros → Anweisungen der Dynpro-Ablauflogik → Subscreens, Tabstrip und Splitter Controls →
mit
ABAP-Schlüsselwortdokumentation → ABAP - Referenz → Benutzerdialoge → Dynpros → Anweisungen der Dynpro-Ablauflogik → Subscreens und Tabstrip Controls→
Ein eigentlich gutes Indiz, dass es bei uns kein Splitter für Kunden gibt.
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Der Hilfetext von dir zeigt leider auf einen Splitter-Container (CL_GUI_SPLITTER_CONTAINER) und den gibts schon länger in SAP nur eben für Controls.
Ich glaub das Splitter-Control gibts erst mit 7.02
Wir sind von 7.0 direkt auf 7.02 und dann stand es erst zur Verfügung.
Ob es das in 7.01 schon gab weiß ich daher leider nicht 100%ig. Schau mal ob es die Klasse CL_DYNPRO_SPLITTER bei euch gibt. Die wäre nämlich für die Kommunikation mit dem GUI zuständig, damit das Ganze funktioniert.
Der Weg über "Bearbeiten → Anlegen Element → Splitter Control" im alphanumerischen Screen Painter ist übrigens der Richtige. Im grafischen Layout-Editor kann das Splitter Control nämlich (noch?) nicht dargestellt werden.
lg ADT
Ich glaub das Splitter-Control gibts erst mit 7.02
Wir sind von 7.0 direkt auf 7.02 und dann stand es erst zur Verfügung.
Ob es das in 7.01 schon gab weiß ich daher leider nicht 100%ig. Schau mal ob es die Klasse CL_DYNPRO_SPLITTER bei euch gibt. Die wäre nämlich für die Kommunikation mit dem GUI zuständig, damit das Ganze funktioniert.
Der Weg über "Bearbeiten → Anlegen Element → Splitter Control" im alphanumerischen Screen Painter ist übrigens der Richtige. Im grafischen Layout-Editor kann das Splitter Control nämlich (noch?) nicht dargestellt werden.
lg ADT
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
!
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
2516
Views
Views
7
Antw.
Antw.
4848
Views
Views
CustomControl im Kundernreiter ME23N
von Foppa » 08.12.2015 21:21 • Verfasst in Dialogprogrammierung
von Foppa » 08.12.2015 21:21 • Verfasst in Dialogprogrammierung
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.