Skip to Content
  *Introduction*  If you want to enable users editing standard texts in extremely simple and  straightforward UI, you can use the component described in this weblog. It’s a  class (OO ABAP) which pops up a CL_GUI_TOOLBAR (CFW) control which enables user to enter  text and save or close.   *Why not a standard transaction?  I had a request from a user. On a custom-made purchase order (I made it as a SmartForm) the user wanted to have a piece of freely entered text. The text should’ve been vendor-specific and user wanted to be able to change it from time to time. The obvious solution to me was a dynamical standard-text node in the SmartForm. The question was how to let the user edit standard text?  Stanard solution CALL TRANSACTION ‘SO10’ is not bad, but has drawbacks: 0.1.   0.2. Going directly to the text editor is possible by using the AND SKIP FIRST  SCREEN addition. However, returning to the calling program displays the SO10  first screen. It’s one useles and irritating screen too much for the user, and one click  too much:   0.3.   0.4. Formatting options are good to have. But if they are unneccessary for some  functionality, then it’s good to hide them from users. What they can’t see  they can’t break. Look at all the nice confuzing buttons to mess with in SO10:   0.5.   0.6. SO10 occupies the entire session screen – I can’t run it in a popup (or  any desired) container 0.7.    *The new component** All in all, I wanted to  make it as simple as possible for users. Ofcourse, I wanted to make my  life easy too, by making a generic reusable OO component with simple programming  interface. So  I came up with this.  This executable little sample program…   REPORT  Z_TEST_ST_TEXT_EDITOR. DATA: o_txe     TYPE REF TO zcl_standard_text_editor,       v_caption TYPE char100,       s_thead   TYPE thead.        * call screen CALL SCREEN 0100.  * MODULE s0100_start MODULE s0100_start OUTPUT.     SET PF-STATUS ‘BASIC’.     s_thead-tdname   = ‘VENDOR0000000011’.     s_thead-tdid     = ‘ST’.     s_thead-tdobject = ‘TEXT’.     s_thead-tdspras  = sy-langu.     CONCATENATE ‘Standard text:’ s_thead-tdname                 INTO v_caption SEPARATED BY space.     IF o_txe IS INITIAL.        CREATE OBJECT o_txe             EXPORTING i_thead   = s_thead                       i_caption = v_caption.     ENDIF. ENDMODULE.  * MODULE s0100_exit MODULE s0100_exit INPUT.   LEAVE PROGRAM. ENDMODULE.  …results with a popup screen: 
To report this post you need to login first.

11 Comments

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

  1. Salmon Salmon
    Dear Igor,
    I had used the standard text for default text in the sales transaction, and it would be great if your provided code can be replace the functionally of standard text.

    I have tried to implement your code, but found some errors.
    1. while declare attribute T_INITIAL_TEXT, our system didn’t have Associated type TY_T_TEXT.
    2. syntax error in method CONSTRUCTOR line 83 with error message “V_HEX1 must be a character-type data object (data type C, N, D, T or String), field string).”

    could you please advice regarding these problems?
    Thank you.

    Best Regards,
    Salmon

    (0) 
    1. Igor Barbaric Post author

      Hi, Salmon!P.S. By the way, this code does not replace the standard texts. It just enables another way to let the user edit standard texts.

      (0) 
      1. Salmon Salmon
        Hi Igor,
        The problem #1 has been resolved, I missed the 2nd step when trying the code, sorry….

        I tried the code on CRM 4.0 WAS 620.
        Thanks!

        B.Rgds,
        Salmon

        (0) 
        1. Igor Barbaric Post author
          Hi, Salmon (and everyone else who tried this)!
          I found the solution. The problem was not the version, but rather unicode. There’s “Unicode checks active” checkbox in class properties. If it’s checked, the systax check doesn’t pass the mixed (text and hex) CONCATENATE statement.
          Thanks to Durairaj Athavan Raja and Christian Finkbeiner I have corrected the code to be unicode independant and updated the weblog. You have to update the source code of CONSTRUCTOR and SAVE methods in the class.
          Thanks for patience!
          Igor
          (0) 
  2. Ian Stubbings
    Hi Igor

    I have just implemented your code but the toolbar events do not seem to fire.  Any ideas?  I have double check the atributes, mthods etc.  The code was copied and pasted in so there should not be any typos etc.

    I am on 46B BTW.

    Thanks in advance
    Ian

    (0) 
  3. Joachim Bultmann
    I know the Weblog is already old, but I have the same problem Ian had.

    The “save” and “close” button don’t do anything.

    The events seem to be registered but the event itself never starts.

    If anybody has a solution, I would be very glad and thankful.

    Best regards
    Joachim

    (0) 
    1. Johan Von Reedtz
      Hi Joachim,

      I faced the same situation as you did and finally after some lengthy investigation I found the solution.

      When used inside a class it is apparantly not an application event but a system event that should be registered.

      *—— register events
          REFRESH t_events.
          s_event-eventid = cl_gui_toolbar=>m_id_function_selected.
          s_event-appl_event = ‘ ‘.     “Change to this!
          APPEND s_event TO t_events.
          CALL METHOD me->toolbar->set_registered_events
                EXPORTING events = t_events.
          SET HANDLER: me->on_toolbar_func_sel FOR me->toolbar.

      I found this by looking at method FILL_TOOLBAR in std SAP class CL_BUPA_STATUS_ALV. I am on R/3 4.7 BTW.

      Best regards, Johan

      (0) 

Leave a Reply