DOI Wordprocessor: why is long text being cut in table cells?

[Former Member]

I use DOI Word Processor Interface to populate a [templ.doc] template file with data.

There is an empty table in the template and I put there my internal table content with

the method wpi->insert_table2( ).

The problem long (too long for corresponding cells) strings are not wrapped but cut to the length of the cells.

As a result I have loss of data.

Also tried wpi->insert_table() but the same result.

How do I solve the problem?

[Sandra_Rossi]

Maybe install latest sapgui frontend, that would maybe take into account more than 255 characters (I saw some mails on the web about this maximum length)

[Sandra_Rossi]

also Note 683926 - Automation: parameters truncated in multibyte systems .(253 characters)

[Former Member]

Hi Sandra!

Thank you for attention!

But what do you mean "Note 683926 - Automation" ?

I'd also add that in my case text is truncated not to 255 symbols but to

approx. 30. And that looks like truncate is being done according to the current cell width rather than some fixed length, not sure though...

Best regards,

Kechebek Kechebekov

[Sandra_Rossi]

I tried on my system, with sapgui 6.40, I don't have this problem. I have a structure with a field of 128 characters in which I put a very long text, and it is correctly inserted in the cell (as if you were typing characters in it).

What is your sapgui version? Try install latest. Or word version maybe?

In word, does your table have dynamic row height? (NOT fixed)

[Former Member]

My sapgui version is 710, final release.

My word version is 2003 SP3.

And I think my guess about cell width as determining value isn't right because I've just found out that

long text with english letters only is wrapped onto 2 lines of a cell but is still truncated..to 40 symbols.

This also excludes the variant with fixed row height.

Maybe a bug of the 710? Or any settings on DOI...

[Sandra_Rossi]

It may also be windows (for OLE). I also tried with a sapgui 710 and word 2003 and there's no problem.

Could you try my little program : copy SAPRDEMOOFFICEINTEGRATION to custom program, and replace code below WHEN 'COPYLINK', with:

      DATA lt_col TYPE soi_cols_table.
      DATA ls_col TYPE LINE OF soi_cols_table.
      TYPES : BEGIN OF ty_s_data,
                var TYPE char128,
              END OF ty_s_data.
      DATA ls_data TYPE ty_s_data.
      DATA lt_data TYPE TABLE OF ty_s_data.
      DATA lo_error TYPE REF TO i_oi_error.
      CALL METHOD document->get_wordprocessor_interface
        IMPORTING
          wp_interface = wp_ref
          retcode      = retcode.
      IF retcode EQ c_oi_errors=>ret_ok.
        REFRESH lt_col.
        ls_col-colindex = 1.
        APPEND ls_col TO lt_col.
        REFRESH lt_data.
        GET TIME.
        ls_data-var = 'text djkfdjslfkjsd jfksdfjdlskdf jfkdsfjd jkfsdjflksdj jdfskfj sdlkf jkldfsjfklsdjflks jklfsdjfklsdfjl'.
        APPEND ls_data TO lt_data.
        CALL METHOD wp_ref->insert_table
          EXPORTING
            data_table      = lt_data
            info_table      = lt_col
            lowerbound      = 0
            upperbound      = 1
            doctable_number = 1
            clearoption     = 0 "1=clear only accessed columns
            startrow        = 1
            varsize         = 'X'
          IMPORTING
            error           = lo_error
            retcode         = retcode.
      ENDIF.

Run the program, click F2 (-> word is started asynchronously, doc is displayed), insert a table in this doc, do not close, click F7 from program (-> it inserts the text in the first cell).

Tell me what happens.

[Former Member]

Hi Sandra!

Your sample worked fine and I was confused with the fact.

And now I've understood what happens.

Actually all is OK about english characters...when testing I tried to put charN, N>40 into char40.

But...the source of the bug are russian(all non-english I think) characters.

The thing is that it's OK for ABAP variable to be char40 and to contain 40 russian characters,

but it's not OK for Word for some reason, maybe because those chars are encoded with 2 bytes and the bug occurs when transforming to Word's 1 byte....in any case I believe it's DOI bug. Do you agree?

One more moment. To solve my problem I built a new table extending my source table with 1 field char80 (source field was char40).

I used such a syntax:

  
TYPES: BEGIN OF ty_data_xt.
   INCLUDE ty_data.
TYPES: field_xt TYPE char80, 
   END OF ty_data_xt.

And used insert_table2() method. And it seems that here is one more bug of DOI:

that doesn't show field_xt data, though I describe that in lt_colnames properly.

So I had to redescribe ty_data_xt with full field list (avoiding INCLUDE).

Thanks for such a great help, Sandra!

Best regards,

Kechebek Kechebekov

[Sandra_Rossi]

Hi Kechebek, I'm happy you found what was going on. I am not sure if it's DOI bug or not : maybe, or maybe not.

Maybe you need to add a code page conversion between the server code page (get it by calling function module RFC_SYSTEM_INFO, export parameter RFCSI_EXPORT-RFCCHARTYP) and the frontend code page (get it by calling method CL_GUI_FRONTEND_SERVICES=>GET_SAPLOGON_ENCODING). If they are different, then add in your program a conversion via CL_ABAP_CONV_OUT_CE (documentation supplied with the class). If they are the same, then I don't have any more idea.

About the 2nd problem, it is maybe again a problem of codepage, did you try a column name with occidental characters like "test" ?