Skip to Content

Download the Source Code for this example here!


I have spent a fair amount of time in the past researching an OO approach to classic Dynpro ABAP Screen development.

ABAP OO mixed with Classic Dynpro

The approach that I have used in the past is basically a hack. It isn’t nearly as elegant as Model View Controller.

Always being on the lookout for a better approach to Dynpro based development, I was surprise to stumble across a little gem the other day as I was doing research on the new ALV Object Model in WebAS 640. What I found was a set of classes in Package SALV_DYNPRO that looked strangely like an OO Screen Framework for Dynpro. Sure enough after a little bit of investigation, it even began to vaguely resemble MVC. It isn’t quite the Holy Grail of Dynpro development because you still need a Function Group to house your Screens and Statuses; but with the right structure and some clever use of Includes, even this isn’t too big a deal.

Unfortunately the SAP classes are rather bound up in the complex coding of the ALV OM. My goal then was to try and create a simple example to prove out if these classes could be used outside of the ALV OM. I just wanted to create a very simple example with two screen. The program navigates between the two screens and responds to PBO/PAI events through OO event handlers.

The Old Stuff

Like I said earlier, there are a few legacy pieces to this puzzle. We might as well get those out of the way to begin with.

We need to create a function group to house our legacy elements. This is where we will create our GUI Status, a generic Gui Title, the screen definitions themselves and a generic function module to actually call the screens.

The GUI Status would be defined like normal. For the Gui Title we will just enter dynamic elements so that a single Title can service any number of screens that we have (&1 &2 &3 &4 &5).

For the Screens, we will define them in the Screen Painter just like normal. Be sure to set the OKCode to the variable G_OKCODE. One of the screens will have a few buttons on them so that we can demonstrate OO Event Handlers for them.

The flow Logic for all the screens will be exactly the same. We will use a generic set of modules (written by SAP and linked in via several includes) in every screen.

process before output.
module d0000_pbo_set_status.
module d0000_pbo.
process after input.
module d0000_pai_fcode at exit-command.
module d0000_pai.
module d0000_pai_fcode.

The function module itself, Z_DYNPRO_CALL_SCREEN, is designed to call a screen dynamically (either full screen or as a popup). The following is its coding.

function z_dynpro_call_screen .
*"-------------------------------------------------------------------- *"
*"Local Interface:
data: l_starting_x type i,
l_ending_x type i,
 l_starting_y type i,
 l_ending_y type i.
case i_popup.
 when space.
call screen i_dynnr.
when others.
l_starting_x = i_starting_x.
l_ending_x = i_ending_x.
l_starting_y = i_starting_y.
l_ending_y = i_ending_y.
if l_starting_x is initial.
l_starting_x = 1.
if l_ending_x is initial.
if l_starting_y is initial. l_starting_y = 1.
if l_ending_y is initial.
call screen i_dynnr starting at l_starting_x l_starting_y ending at l_ending_x l_ending_y.

The final piece is to link in the SAP includes for our Flow Logic Modules. That is done in the Global Data Section of the Function Group.

function-pool zesu_bc640_oo_dynpro_leg.
include lsalv_dynpro_frameworkdef. include lsalv_dynpro_frameworki00. include lsalv_dynpro_frameworko00. include lsalv_dynpro_frameworkf00.

The New Stuff

Now we are ready to take a look at the OO Screen Implementation itself. We will start by creating a class that inherits from CL_CTRLER_SCREEN_WINDOW.

We will have few attributes in this class that link our Screen Class to the Legacy Components. This is where we can supply the name of the Title, Status and Program to use for linking to these Legacy Components. The C_REPID field has the name of our Function Group Program.

The following screen shot shows the methods of our Screen Class.

You can see that the Framework provided by the inheritance (CL_CTRLER_SCREEN and CL_CTRLER_SCREEN_WINOW) provide plenty of event handlers that we can redefine with our own coding. However we will start with the CONSTRUCTOR. This is where we will initialize the screen framework and register our event handlers.

method constructor.
super->constructor( ).
repid = c_repid. dynnr = '0100'.
data: l_pfstatus type sypfkey.
case popup. when space.
l_pfstatus = c_pfstatus_window.
when others. l_pfstatus = c_pfstatus_popup.
r_status->set_pfstatus( pfstatus = l_pfstatus pfstatus_repid = me->c_repid ).
 set handler navigate for me.

Next we have the ON_CALL_SCREEN method. This is the event handler that is called by the Screen Framework whenever a Call Screen event is raised. By redefining this event we can hook into our Function Module from earlier thereby controlling which screens we call.

method on_call_screen.
call function 'Z_DYNPRO_CALL_SCREEN'
exporting i_dynnr = dynnr i_popup = popup i_starting_x = starting_x i_ending_x = ending_x i_starting_y = starting_y i_ending_y = ending_y.

Next we have the logic that is the OO replacement for the PAI Processing. By redefining ON_PROCESS_FCODE, we have our custom event handler for classic Dynpro Events.

method on_process_fcode.
super->on_process_fcode( fcode ).
if r_status->pfstatus_repid eq c_repid and ( r_status->pfstatus eq c_pfstatus_window or r_status->pfstatus eq c_pfstatus_popup ).
case fcode.
 when 'BACK' or 'CANC' or 'OK'.
set screen 0. leave screen.
set_fcode_handled( ).
when 'EXIT'. leave program.
when 'PRESS_ME'. raise event navigation_requested.
when 'HI'. message 'OO Event Handler! Yay!' type 'I'. set_fcode_handled( ).
when others. raise event handle_fcode exporting fcode = fcode.

When you press one of the buttons in my application I want to navigate to my second screen. I decided to implement this Event through my own custom event handler. Notice that in the processing for PRESS_ME, I just raise another event, event navigation_requested.

We then can create our own custom event handler for this event.

method navigate .
 if dynnr = '0100'. dynnr = '0200'.
dynnr = '0100'.
clear r_screen. me->display( ). set_fcode_handled( ).

So now all we need is a TCode to call our class. We could create an executable ABAP program that initializes our class and calls the constructor. We can then attach a traditional TCode to that Program. But that feels a little wrong somehow. Instead let’s stick with OO and create an OO Transaction Code that directly initializes our class. That way we can avoid procedural ABAP as much as possible.


This has been a rather simplistic example, but hopefully it shows the potential for an OO (even MVC) approach to Dynpro Screen Programming. I am looking forward to creating a real world application using this approach in next few weeks. That will be the real test of how useful it might be.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Peter Inotai
    Hi Thomas,

    Thanks for this weblog, it’s really interesting.
    It’s a pity, that CL_CTRLER_SCREEN_WINDOW is only available as of WAS 6.40.

    Based on your codes in this weblog, it seems you are already addicted to the AB4 editor:-))))


    1. Thomas Jung
      I will take a close look at the SAP classes, but I don’t think there is anything in them real specific to 640.  I don’t see why they couldn’t be copied and down-ported to 46C.  I will pick through them this weekend and let you know.
    2. Thomas Jung
      >it seems you are already addicted to the AB4 editor

      I really like the HTML export of the AB4 editor.  I think it makes for a nicer presentation in Weblogs.  Now the code stays nicely formatted and you can print it out.  I like it better than the textedit approach.  It does add to the size of the HTML behind the Weblog.  That has caused me to hit the limit on the size of a weblog twice now.  I guess I should make a post in the SDN Suggestion Forum to see if that size can be increased.

  2. Christian Schäfer

    thank you for this weblog. I wonder if you ever found the User Interface Framework (BC-SRV-UIF), which has been developed for the TMW.

    It goes far beyond the approach described here by putting dynpros, subscreens, containers, controls, tables, menus or even individual fields into so called “GUI components” that interact with “UIA components” (User Interface Abstraction). This frameworks makes it possible to put together Dynpros with reusable components that can be exchanged with other components from the customer to enhance the application. The components are loosely coupled with a message mechanism.

    Unfortunately this framework is quite complex and hard (impossible?) to understand without some documentation and it seems it has not been used by more projects as there are still only the two TMW application classes.

    But it is still interesting that there are always new approaches to the same problems. 😉


    1. Frank Wagner

      That’s not the only approach to this problem. The (to my knowledge) first enjoy applications created for the new purchasing apps are based on a MVC dnypro framework. See package MEREQ in a R/3 >=46C or ERP System.

      This framework has in core the same concept as the framework of SALV_DNYPRO but is much more complete (for example tabstrip and control integration).
      In my opinion it will never be possible to create a real OO framework until it is possible to handle dynpro’s as controls. Without this you cannot display more than 1 dynpro on a screen or connect dynpros to splitter controls. Until this feature is available you will have two world’s (dynpros and controls on it).


  3. Sascha Kiefer
    Hi Thomas,

    a great weblog, but unfortuanetly 2 weeks too late 😉 I just started a dynpro project for which I already got some ideas from your former weblog but for me it also was not far enough object oriented. So I started to create my own kind of framework that lead to a very similar structure and processing as the framework you found (the only thing that realy calms me, is that the standard thinks in a similar way as I do 🙂
    But nevertheless I think you did a great job (again).



  4. Thomas Klingenburg
    Hi Thomas,

    your approach is a nice one. It works fine for me though I have a question. How do I place a ALV on a TAB strip within this framework. The Subscreen itself works fine, but the controls don’t show. Any idea?



    1. Thomas Jung Post author
      I have to say that I haven’t tried a tab strip within the OO framework.  Although interesting, I have been focusing most of my efforts of late on Web Dynpro instead.  I have no tips for you off the top of my head.  However in few weeks once my prep work for Sapphire is complete I will try and play around with this.  I will keep the email flagged for followup in my mailbox so I don’t forget.
  5. Sivakumar Subramaniam
    Hi thomas.,
              This weblog is very interesting .. i have on doubt .. how i can capture the POV event .. i tried but i am unable to capture .. please help in this ..


    1. Thomas Jung Post author
      My example isn’t setup for POV but it shouldn’t be difficult to extend. Just like I still have a PBO/PAI in my screens, add the PROCESS ON VALUE-REQUEST.  Now in that block in the screen call a method in the class. Should work just like the PBO/PAI dispatching.
  6. Paul Mazeika
    This is realluy cool…I ntoiced SAP now has the FM “SALV_FORM_DYNPRO_CALL_SCREEN” which is the same as your Z one above…assuming you wrote that.

    Question…I can’t seem to get statuses to work…like setting titles. How do you go about doing that?


    1. Thomas Jung Post author
      I did not write the SALV function modules.  As I said in the blog: “Unfortunately the SAP classes are rather bound up in the complex coding of the ALV OM. My goal then was to try and create a simple example to prove out if these classes could be used outside of the ALV OM. I just wanted to create a very simple example with two screen. The program navigates between the two screens and responds to PBO/PAI events through OO event handlers. “

      Therefore some sections of the code in this blog were copied from the SALV* function modules as their starting point.

      The status must be defined in your function group.  The sample class and function group are designed to set a status called WINDOW from the function group.

    1. Thomas Jung Post author
      Just looking at your code, I have to assume that g_pov_field is empty.  You should debug through the application and try to find out why the field is empty.
    1. Thomas Jung Post author
      T1 is a field from your module pool, but you are triggering this ASSIGN logic from within your class – right?  If so T1 would immediatelly be visible to the class. Like any global variables from your module pool, you would need to pass these explicitly into the class if you wanted to access them.
  7. Jörg Krause
    Hello Thomas,

    I tried out this framework following your explanations, and it worked almost fine. Almost, because I face a problem when the user navigates from screen 200 back to screen 100. Remember that the NAVIGATE event handler says:

      IF dynnr = ‘0100’.
        dynnr = ‘0200’.

    Now, when pressing F3 on screen 200 the control returns to screen 100, but the attribute “DYNPRO” still contains the value 200. Therefore, when I try to navigate again to 200, the handler is confused and does not react properly. I guess, I have to manipulate the “DYNPRO” attribute, when I am about to “set screen 0. leave screen.”? Or is ther a way to keep track of the displayed dynpro in a smarter way?


    Joerg Krause

    1. Thomas Jung Post author
      You are correct.  Of course this is just a learning example.  Probably better would be to call request_navigation for the BACK, CANC, OK as well.  You might even want to consider a special event for Leave Screen Navigation to correctly clean up the supporting logic.
  8. ritesh saurabh
    Dear sir,

    As per reference to your above example, I want to process function codes in the PAI of screen 100. ‘ON_PROCESS_FCODE’ method of class ‘ZCL_ES_00_DYNPRO_EXAMPLE’ is protected and EVENT based. I am using an instance of class ‘ZCL_ES_00_DYNPRO_EXAMPLE’ only.

    Kindly advise.

    Thank you very much.

    1. Thomas Jung Post author
      I’m afraid I don’t totally understand your question.  The handling of FCODEs from PAI is done in the ON_PROCESS_FCODE method of the class.  This method will be called automatically by the framework.  You need only redefine this inherited method and place whatever FCODE handling logic you want within it.  My example above shows this very scenario.
  9. Eric Lagasca

    Hi Thomas, can you re-upload the code (ZIP file) to this if you still have it? It seems that the move to SCN has rendered the link you provided dead.

    1. Thomas Jung Post author

      This blog entry and the linked source code sample is from 2005.  That means it is from before I came to work for SAP and therefore I don’t have a copy of the original content any longer (it would have been on my old employeer’s laptop).  If SCN has lost the content during the migration, I’m afraid I don’t have a way to bring it back.  I looked through my Content tab under my account and I don’t find an entry for this souce code download either. Best I can do is to put a post in the SCN bugs forum and hope an Admin can find the content in the old system and bring it forward.

  10. Alan Shaw

    Hi Thomas.


    I have been looking at this and want to use it to develop dynpros, but, how do I get any input data back to the controller class from the screen.

    1. Thomas Jung Post author

      Since this particular blog entry is almost 7 years old, you are stressing my memory here.  I haven’t done much Dynpro programming in the last few years anyway.  When I have, I’ve done an MVC approach using just a controller class without this framework (see example from the Next Generation ABAP Development book). 


      Still if I remember this sample right, you still have a dynpro screen defined. We are just making the dynpro events to be routed through a controller framework.  So field transfer would happen via global variable name mapping in the top of whatever program hosts the dynpro.  All attempts to make OO Dynpro always runs into the restriction that fields aren’t exposed in any way except this implicit variable transfer. 

  11. Raveendra Sunagar

    Hi Thomas,




    I am trying out ABAP Dynpro with OOP.

    I have created a class inheriting CL_CTRLER_SCREEN_WINDOW.

    I have also created a function group which contains 2 screens and FM to call the screen as described in this blog.

    But problem is method ON_PROCESS_FCODE is not getting triggered on pressing of buttons in screen 1. I saw ur comment stating that this will be triggered automatically by the framework.

    Could you please help in throwing some light on this issue.



    1. Gianpietro Dal Zio

      Hi Raveendra,


      i had the same problem due to wrong dynnr assignment in the ZClass constructor.

      The statement ‘call screen’ of the Function Group works with the 2 values for dynpro: ‘100’ and ‘0100’ but the framework ( cl_screen_framework) needs the right number (‘0100’).

      I solve the problem with the right assignment of <myZclass>-> dynnr with the right value: ‘0100’ as Charlike to Charlike assignment instead of 0100 (numeric to charlike assignment).





      Hope this help you..


Leave a Reply