on 07-20-2008 1:17 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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)
User | Count |
---|---|
94 | |
11 | |
11 | |
10 | |
9 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.