Skip to Content

SAP Screen Personas – How to replace the old style text editor

Note: This post was updated on March 14, 2017 with improved coding that incorporates customer feedback and suggestions from the discussions related to the original blog below.


In several transactions, if a long text is maintained, there is a choice between a simplified MS Word editor and the old school, SAPscript style editor. Certainly most people will want to go with the easier-to-use Word-like editor. However the trouble is that if the transaction is running via Personas (or the webgui for that matter), then we are presented with the rather awkward SAPscript editor:

In the following, I will show a potential workaround to get something that’s a little better. It will still not be the Word-style editor, because that relies on OLE when using the SAP GUI and this is not available in Personas or the webgui. Instead, it is possible to call a text editor control which is supported in Personas or the webgui and allows automatic word wrapping, copy/paste and better usability than the line editor above. It will look something like this:

It is possible to display this control in a popup window shown above or in full screen mode as well. To get this working, it requires some backend ABAP coding and an enhancement implementation. If this is an acceptable compromise, the below solution may be useful.

In all the cases when I faced this problem, I found that the same function module gets called in the backend. It is called FULL_SCREEN_NEW. So my example will work with this function module but some transactions may use a different function module to call the text editor. Still, the same principle should apply there too, so this solution can then be adapted to those function modules.

When the text editor is called, the FULL_SCREEN_NEW function module will verify if Word is enabled and if it isn’t, it falls back to the old editor. This happens in line 172:


Screen 1100 will call the ugly editor, so we want to avoid this. Now, we could do a core modification and replace this CALL SCREEN statement with an INCLUDE containing the code to call something else instead, but such changes are usually frowned upon, due to company policies prohibiting modifications.

To get around this issue, we can use an implicit enhancement at the beginning of the above function module. With the enhancement point, we will essentially replace the complete code of the function module with a slightly enhanced code, containing our logic to call the text edit control and any additional necessary functionality. The standard code is thus retained and for a non-ITS processing (like the regular SAP GUI dialog mode) it works exactly the same way like before. However when the ITS is in use, we will insert our enhanced code in place of SCREEN 1100 and call a new function module we create. This new function module will take care of calling the text editor control and write back the changed text into the standard data structures, so for the subsequent standard code the result will be as if we had processed the text via screen 1100.

To implement the necessary changes, I can offer two methods. The first one is using the standard transport system to load everything necessary into the target instance. The ZIP file linked below contains the two transport files and the documentation explaining how to use them. Importing the provided transport request, the necessary changes will be implemented.

Transport files

If transporting is not an option or the used object names do not conform to the local naming conventions, manual implementation of the changes is also an option. The following link contains the modified code of function module FULL_SCREEN_NEW, so the enhancement can be copied directly from this. It also has the complete code for the new, control-based text editor function module as part of function group Z_PERSONAS_TEXTEDITOR, plus screen shots of the related GUI statuses for full-screen and pop-up window mode.

Link to code

It is important to mention though that in case the function module FULL_SCREEN_NEW is changed by SAP, the enhancement should be adapted to reflect the changes in the standard code.

This method works both in Personas 2.0 or 3.0, however in Personas 3.0 we have much more freedom due to the JavaScript-based scripting engine which could use a multi-line text control for input and feed the text into the backend line editor. Going the route in this post may however be simpler than writing the script necessary for that, and it would be valid for all transactions using the same backend text edit function module. On the flip side, the scripted way would eliminate the need for backend ABAP coding and when used with a template, it can also be reusable.

By no means is this solution perfect and while it works, it doesn’t use all the capabilities of the employed text editor control. If you have additional ideas about how to improve the offered functionality, feel free to discuss it so everyone can benefit.

Please keep in mind that all this code is provided as-is, without any support or guarantees and it is not an officially sanctioned solution from SAP.


You must be Logged on to comment or reply to a post.
  • hi Tamas, thanks so much for that, it solved a big problem we had with a QM01 flavor.

    I have a question: there seems to be a problem when you save a text before saving the document (say in QM01 as opposed to QM02), where internally a flag is not set in Personas, and when you save the document the text header is not updated with the document number, if that makes sense - so when you open it in QM02/03 you can't see the long text anymore. Have you seen this problem happen and would you know what to do to fix it?


    • Hi Gabriela,

      If you have a problem with a flag not being properly set, then this is probably caused by a bug in my code. I'd have to implement this enhancement in one of our systems again and test to see what can cause this.

      You mentioned "a flag" - do you know which flag is it?

      • Yes, if you look at the code below, called upon saving a new notification in QM01, the flag indtx  (line 1873) is checked when executing via standard QM01 transaction, but when via Personas it's not; which causes the text header to not be updated with the new notification number.

        Hope it makes sense.

        And thank you for asking.


      • Hi Tamas, we are actually approaching a go-live date with our Personas implementation, I'm wondering if this would be a case for opening an OSS incident with SAP as a more proper channel for prioritizing this issue?

        Thanks again for all your help.


        • Since this solution involves an enhancement and it is not part of the standard functionality, you cannot open an OSS incident about it. There is no official support for this workaround.

          I will try to find some time to investigate where the mentioned flag can be set but I cannot promise a deadline when I will get to it.

          • Tamas, I have good and bad news.

            I removed your enhancement and the text still won't save when in creation mode.

            So, there is not a problem with your code.

            But there is a problem with Personas, or my flavor at least. It does work when in Basic Mode. It also works if I remove the Tab Caching...

            The text has to be saved regardless of the enhancement, naturally.



      • Tamas,

        Thank you very much for such a helpful post. Just a question. One of our clients is not using Personas due to EHP4/NW7. They are interested to remove the default line editor in WebGUI with something more simpler like notepad. We have done this in SAPGUI by disabling "SAPScript" & "Smart Forms" options using functional module RSCPSETEDITOR.

        Would appreciate if you could suggest a way to do it in WebGUI also (i-e disable line editor with a simple notepad like large text field).

        • The above method should work if the transaction is run via the webgui as well. Personas sessions are seen by the backend as webgui sessions when the decision is made about the editor.

  • Hi Tamas,

    I tried implementing the code exactly as given in your zip files but somehow the new long text editor that is being created is not an editable field in MM02 where I'm trying to use it.

    Also, it does not copy over the current long text from the text field. I'm not sure what could be causing this as I have not changed anything in your code.


    Do you have any suggestions for me?



    • Hi Amee,

      I don't know why does this not work for you in MM02. I haven't tested it in that transaction but I used this method a couple of times in other transactions without any problem. As you can see, others were also able to do this.

      You would have to debug the code behind MM02 and see how it uses the text returned from the function module, and if necessary, adapt the code to the particular requirements.


      • Thanks for your reply.

        I tried it in some other transactions too and getting the same problem in all.

        When I debugged, I see that the method  g_editor->set_selected_text_as_r3table is getting called correctly and its parameter even contains the data but somehow its not getting transferred to the new text editor window.

        I'm stumped and dont know what else to try to get it to work. Could it be some sort of permissions issue, even though it is development system that I'm trying it in?

        • Hi Amee,

          We've also encountered the same issue. Were you able to solve this issue by any chance ? If you were, would really appreciate any pointers.



          • After further investigation, we were able to fix and make it work : 

            In the PBO module "textedit_pbo",  the statement "create object g_editor_container" creates a custom container named 'TEXTEDITOR1', but does not attempt to link it to the dynpro. So, at first, I added a subsequent stmt "call method g_editor_container->link" to dynamically link the container to the the dynpros (100 , 110), but that did not work. So, I dropped the dynamic link attempt (keeping the PBO code exactly as delivered), and instead went into SE51 (Screen Painter, Layout editor) and physically added a custom control (container named 'TEXTEDITOR1') to the screens 100 & 110.  I'm assuming that's how it was intended to be. That worked, and now the editor shows up on screen.

          • Hi Jay,

            excellent news and congratulations for making it work in your use case. It is interesting though that this was necessary since the workaround did its job in other transactions as indicated by feedback and my personal experience. This means that apparently there is something different between the material master transactions and others where this solution worked without additional tweaking.

            Would it be possible to eventually describe your changes (with screen shots and maybe posting the code, highlighting what you altered)? That way others can also benefit from your success.



          • Hi Tamas,

            My transactions were Purchasing tcodes (ME21/21N, ME51/52N), not the MM02 transaction.  However, the issue I observed was exactly the same as the image in Amee's message (above).

            I implemented the artifacts in your attachment exactly as-is, except for the following additions:

            1. Using Screen Painter Layout Editor, I physically added a Custom Control container to screens 100 and 110. This fixed the issue of the Editor not appearing, as depicted in the image in Amee's message above.  (no other change to code or screen was needed just to make the Editor appear).


            2.  However, I did make one other specific improvement. The code as delivered in the attachment was rendering the Editor in edit mode even when the user was in Display mode in the original transaction.  So, I made a couple of small code changes :

            a) In the Enhancement code in FM 'FULL_SCREEN_NEW', I inserted 1 line (just before the CALL FUNCTION 'Z_PERSONAS_TEXTEDIT' statement),  to set a parameter that indicates whether the user was in display mode on the original transaction.


                     CONDENSE zz_titlestring.



            b) In the PBO Module, I check the parameter and set the Editor readonly mode

                      MODULE textedit_pbo OUTPUT.
                         data: lv_disponly  type char1.

                         << insert the PBO code from attachment here >>

                         GET PARAMETER ID 'DISPONLY' FIELD lv_disponly.
                         IF lv_disponly = 'X'.
                    * Set editor to read only mode
                             CALL METHOD g_editor->SET_READONLY_MODE
                                       READONLY_MODE = 1.

                      ENDMODULE.                 " TEXTEDIT_PBO  OUTPUT

  • Hi folks,

    I didn't see a spellchecker in the image of this alternative editor. Has anyone incorporated spellcheck functionality into this by any means ?  Any response much appreciated.



    • I don't think it is "best", by any stretch of imagination... but as far as I know, there isn't an alternative out there yet. It is unlikely the webgui would be changed in this regard - although nothing is impossible, but if it didn't happen for so many years, then it probably won't be done anytime soon. I would love to be proven wrong though.

      Perhaps in Slipstream Engine there is more possibility, but this should be evaluated to see if it's something we could do.

  • Hi Tamas,

    This blog is a life saver and has worked perfectly so far.  It should be said that SAP should offically implement something like this instead of ignoring the issue.  This blog has allowed us to move to HTML from SAPGui for our EAM group.  If it wasn't for this we would have ended up with a hybrid SAPGui and HTML concoction.

    Thank you very much for sharing.


    • Thanks, Brian. I’m glad this method worked for you and helped you to move forward.

      Let’s hope we can come up with a better solution. Unfortunately this is not something we (the Personas team) can change in the backend, otherwise it’d be done already ?