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.
- SAP Managed Tags:
37 Comments
