Hi Neil;

   Have a look on the improper behaving MLE for scripts on various User event, Other event, etc that might be interfering with the MLE's data and/or formatting.

Regards ... Chris

I'm pretty sure the MLE just displays plain text.  If you want formatting you need to use the RTE control.

Hi, Neil - 

I'm not sure the following will address the problem you're experiencing, but you might wish to give it a try:

PB uses the Windows edit control for its Single-Line and Multi-Line edit control. In the DataWindow, that's different, but this edit window control (multi-line is a style option of the normal "single-line" edit control), PB pretty much hands the user interface management over to Windows.

In the Windows edit control, the display/edit area is bounded by a "format rectangle", whose properties can be obtained and modified via the SendMessageW Windows API function. This code temporarily shrinks the size of the format rectangle in the MLE slightly, pauses (so that you can see the effect), then restores the format rectangle's original size. Changing the size of the format rectangle forces the Windows edit control to re-format. Hopefully, this will correct your issue.

You'll need a WinAPI rectangle structure (suggested layout shown in comment block) and an External Function Declaration (also shown in a separate comment block).

/*
Structure definition:

global type s_rect from structure
   long  l_left
   long  l_top
   long  l_right
   long  l_bottom
end type
*/

/*
External Function Declaration:

FUNCTION ULong GetSetMultilineEditFormatRect ( &
   Longptr    hwnd, &
   ULong      msg, &
   Longptr    wParam, &
   REF s_rect lParam &
   ) LIBRARY "user32.dll" ALIAS FOR "SendMessageW"
*/

// Windows API Message ID's:
Constant UnsignedLong APIMSG_EM_GETRECT = 178 // 0x00B2
Constant UnsignedLong APIMSG_EM_SETRECT = 179 // 0x00B3

Longptr llptr_hmle
s_rect  lstr_rect

// Get multi-line edit control's handle, then get its edit format 
// rectangle via a Windows API function.
llptr_hmle = Handle(mle_1)
GetSetMultilineEditFormatRect(llptr_hmle,APIMSG_EM_GETRECT,0,lstr_rect)

// Prevent the user from seeing temporary changes to the multi-line edit.
// (comment out the following line so you can see what happens...)
//mle_1.SetRedraw(False)

// Temporarily shrink the mle's format rectangle to cause it to re-format contents.
// Values are in pixels, relative to upper-left corner of the mle control.
// I picked an adjustment value large enough that you can see its effect.)
lstr_rect.l_left   = lstr_rect.l_left   + 5
lstr_rect.l_top    = lstr_rect.l_top    + 5
lstr_rect.l_right  = lstr_rect.l_right  - 10
lstr_rect.l_bottom = lstr_rect.l_bottom - 10

GetSetMultilineEditFormatRect(llptr_hmle,APIMSG_EM_SETRECT,0,lstr_rect)

// Remove next two lines after you verify this works or not.
Yield()
Sleep(2)

// Now restore the original format rectangle to force it to re-format
// the contents again.
lstr_rect.l_left   = lstr_rect.l_left   - 5
lstr_rect.l_top    = lstr_rect.l_top    - 5
lstr_rect.l_right  = lstr_rect.l_right  + 10
lstr_rect.l_bottom = lstr_rect.l_bottom + 10

GetSetMultilineEditFormatRect(llptr_hmle,APIMSG_EM_SETRECT,0,lstr_rect)

// Don't forget...
mle_1.SetRedraw(True)

Return 0

I know the code executes OK, but I don't know if will solve your issue. Fingers crossed!

John

Hi, as far as I can contribute:

When you want a newline in a mle or a tab, you'd normally have to use ctrl+enter and ctrl+tab. See if things work when you replace the enters with ctrl+enters. 

Also, I seem to remember that pasted text would show correctly when your mle is editable and you place focus on it / click in it, but would lose the newline formatting once the control loses focus.

regards

Hi Neil...here are my thoughts on what you may be experiencing:

I'm not sure how your Excel files are being populated/ created, but when you go to the "next line" in an Excel cell by typing Alt+Enter it does not add both a CR (0x0D) and LF (0x0A) in the cell. Excel only adds a line feed (0x0A) which of course the MLE control will not interpret it to mean that the following content should be on the next line.

I believe what is happening is that when you paste the data directly from Excel (or from a PB MLE which obtained its data from Excel) in to Notepad, Notepad++, MS Word, Brackets etc. they all know how to handle the text should there only be a LF (0x0A) - just like they know how to handle a text file encoded with UTF-8 without BOM whereas PowerBuilder does not, but that's another thread altogether. That's why when you paste it into these programs and save it, then look at it with a hex editor it appears with both the CR (0x0D) and LF (0x0A). I suspect another program that is not interpreting it correctly, like the PB MLE control, is the utility you're using to import the data into the database (or, to be fair, maybe PB and your utility are handling it correctly in that they are taking it at face value, or literally, versus assuming it to mean you want both a CR (0x0D) and LF (0x0A)).

I know you stated that "...the data contains embedded LFs and CRs, but, in the MLE, all of the data is concatenated together into a single word-wrapped line and not shown on separate lines as it should be." but I don't think that's quite the case as far as the CRs and LFs. If you took the following code and execute it once the data was placed in the MLE you would see that only the LF (0x0A) is there:

Integer li_counter
String ls_string

//Prior to the next line executing make sure you have copied the text from the Excel cell in question on to the clipboard
mle_1.text = ClipBoard()

//Pull all the ascii values into a string
For li_counter = 1 to Len(mle_1.text)
	ls_string = ls_string + "  " + String(ASC(Mid(mle_1.text, li_counter, 1)))
Next

//Display all the ascii values...you will see there is no ascii 13 / CR / 0x0D
MessageBox("", ls_string)

You did a lot of work testing, trying to cover off the various scenarios prior to posting your question and provided a great overview as to what you already attempted which for me was a big help in understanding what I thought was happening. I think what was missing in the many ways you were trying to troubleshoot and look at the data was looking at how it was actually stored at the source, meaning in the spreadsheet. One way to see what I'm talking about is to create an Excel spreadsheet with two lines of text in a cell using Alt+Enter to enter the second line. Save that spreadsheet as a Unicode Text or Text (MS-DOS) file type and then look at it with a hex editor. You should see that the CR (0x0D) is missing even though when you open that same file by double-clicking on it, it will still display correctly, that is, on two lines.

I'm not sure if John's code will make a difference...and John, as usual, has provided some great code...since the issue is with the CR (0x0D) not even making it into the MLE since it likely never made it into the database either, but worth a shot.

HTH...regards,

Mark