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 everyone 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 modifications 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.
The attached file contains the changed 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_PERS_GLOBAL, plus screen shots of the related GUI statuses for full-screen and pop-up window mode.
Since the forum software doesn't allow ZIP files to be attached, you'll have to remove the .TEXT extension from the file name in the archive to get the original ZIP file.
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 actually also helps in Personas 3.0 although there we have much more freedom due to the JavaScript-based scripting engine which could call a text edit control 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. On the flip side, it would eliminate the need for backend ABAP coding and ultimately is the better solution.