behavior extraordinarily

[Former Member]

Hi friends

In order to understand my problem

please call transaction cbih82, press F8,

'Start search anyway?' click yes,

'Do you really want to continue?' click also yes, at the hit list

chooce any incident and hit the button 'Safety Measures'. And now

you will see a field named 'Description' at the below part

of the gui.

Exactly this field is going to be filled through WebDynpro

via adaptive RFC.

A TextEdit element is used in order to insert a text which will passed

to the sap system (at the backend) later .

Java adds automatically \r\n as as usual when the user

makes a new line while inserting text in this text edit area.

This is so far OK.

e.g you insert a text like

sap 'line feed'

is 'line feed'

great 'line feed'

Java makes internally:

"Ltxt"= "sap\r\nis\r\ngreat\r\n"

But on the SAP side I get this text displayed like:

sap##is##great (inside a field named 'Description' ).

To sum up this mentioned field 'Description'

can be edited on the SAP side within the

transcation (cbih83). When you click on the

icon 'Display note' an editor will be launched.

It's like a magic, right there the line

feeds are interpreted correctly. I can see

the the text appearing one after another

sperated by new line (line feed).

With other words line feeds are exitisting

inside the editor but otherwise they are

displayed as # if you not launch this

editor. When I remove these # signs

on the other hand there won't be any

line feeds available inside the editor.

Has somebody else any idea how to

solve this strange occurance without deleting

linefeeds and displaying # .

regards

sas

[Former Member · Accepted solution]

Hi,

In order to solve this problem you must use the structure LONG_TEXT - which means change the bapi interface (and code).

In java you will use a single string attached to the text edit but when sending it to the BAPI you will convert it to the structure (represented by a table) LONG_TEXT. Whenever you encounter \r\n you will add a new line in this bapi table (also bear in mind that each line has a maximum chars limitation - usually 72).

Write a small java method that converts the java string to the abap table (represnted by the abap structure LONG_TEXT).

Aviad

[Former Member · Accepted solution]

Hello I thank you very much for your help.

You are saying: use the structure LONG_TEXT .

Do you mean on the abap side or java side ?

Reagrds

sas

[Former Member · Accepted solution]

Hi,

Abap Side.

Regards

Ayyapparaj

[Former Member · Accepted solution]

The Bapi was a standard original Bapi from SAP

it doesnt make to much sense to change the interface type to LONG_TEXT.

On the Java side I am using already a single string .

Bye

sas

[Former Member · Accepted solution]

Hi,

What is the BAPI name? Maybe there is already a structure for this LONG_TEXT.

If not you can create a Z_BAPI and add the desried long text table and then call the standard BAPI.

Aviad

[Former Member]

Matt I thank you for your detailed reply.

Indeed I have almost to rewirte the whole transaction

cbih82 in order to realize it.

What would you do to satisfy the customer in this case.

Actionally it is more an esthetic problem than

a functional problem as the editor shows the line feeds

correctly on launching the long text editor.

Regards

Erdem Sas

[matt]

I would tell the customer that this is how SAP works, and how the transaction is designed. They have three options that I can see, as far as I understand the issue.

1. Accept the limitation - and in my opinion also, it is only cosmetic.

2. Modify the standard transaction

3. Strip out the carriage return/line feeds.

The choice between 1 and 3, is really whatever is preferred. 2 is expensive, in terms of initial development and future support and maintenance.

Tell them 1 & 3 costs 0-1 Man Hour, without increasing support costs. Option 2 would be 5-10 Man Days for the initial development, and you'd have to allow about the same each year for support and maintenance. Plus it's higher risk, because the more complicated a development is, the harder it is to fix if it goes wrong, especially when the fixer might not be the original programmer.

I've regularly encountered this type of scenario over the years. When you start talking about money, the project management/business soon start to reconsider whether it is really necessary.

[Former Member]

Matt thank you again for your kindly efforts.

I will suggest those points to the customer.

I let you now the result.

Regards

sas erdem

[Former Member]

Hi Matt,

I have noticed something after my privious posting.

You spoke of modifying the standard transaction cbih82

as an addtional alternative.

Suppose customer is ready for modifying of transaction

cbih82. In that case what has to be adapted or improved

to not having this problem.

Regards

erdem sas

[matt]

Not a solution, but it might help you understand what is going on.

Do you understand that where you see \r\n, this is just a convention to represent return and line feed in windows systems? It represents in a form that you can view, the hex 0D0A. See here for more info. http://www.wilsonmar.com/1eschars.htm In unix, you'd only use \n, with Macs, you'd only use \r.

At the application server level, SAP doesn't recognise \r\n as anything other than just these undisplayable hexadecimal characters. It does not ascribe them with any special meaning. It just displays them as #, This is because the app server is designed to be platform independent. This is very important to understand.

When you see the description in the field, it just reflects what is being held in application server. When you click on the button to edit, however, this opens the editor control, which runs on the presentation server. Your presentation server runs on windows, is designed to handle normal windows conventions. So it does know what to do with \r\n. And so you see the field displayed correctly.

The upshot is, I'm afraid, that without re-writing the SAP program, you simply cannot achieve what you want. SAP have designed the transaction CBIH82 to work with only displayable characters.

matt

[Former Member]

Matthew Billing did you receive my very last posting ?

Regards

sas

[Former Member]

Aviad Levy

If you have called the transaction cbih82 you will

notice the problem is in the field where you can see

the short text. Because if you launch the editor

on pressing the button "Display note "at description field

the line feed is performed correctly. The problem is

inside of Decription field (short text)

\r\n is being displayed as ##

regards

sas

[Former Member]

hi,

The short text field is driven from the long text (as far as i know) - it is the first row.

Try to see if the standard BAPI has a structure for long text also.

If not (or if this solution does not suit your needs) the last resort is to replace the "/r/n" with regular spaces before sending it to the BAPI.

But this means that you wouldn't be able to reconstract this string.

Aviad

p.s.

I tried calling this transaction but its not customize for use (missing entry lists)