1. Neil Sutter
  2. PowerBuilder
  3. Monday, 20 December 2021 18:41 PM UTC

Hi, having an issue with a MultiLineEdit control losing/ignoring formatting, sometimes. This has been happening for years using many versions of PB, so it is not PB-version related; customer has just called me on it, so would like to find a solution for them. Here's a description, the best I can describe it:

Using a utility to import data from an Excel spreadsheet into a SQL Server database, Text_Image field. Not sure that is relevant, but it's the starting point.

In a PB application, retrieve a row of that imported data and display the text using an MLE. Formatting is lost. That is, 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.

So, here's where it gets strange. If that same data is displayed in Word (separate button on the same form using the same data that can display the data in the MLE), the formatting is correct, Word shows the data on separate lines as required/expected.

If, the contents of that text is selected and copied out of Word and pasted back into the MLE, the formatting is honored in the MLE; data is shown on separate lines.

If the contents of the MLE are then saved back to the database, and then later re-retrieved, the formatting is honored. Get's weirder....

I have pulled the data in several different places and using different tools and compared the text. It is identical in all cases. That is, if I select and copy the data from SQL Server directly, or from Word, or from Notepad, or from the MLE, and then compare any of those against the others, the characters match completely (using NotePad++ which has a hex comparison tool so I know the matches are identical). I've even put the app into debug and captured the contents of the variable used to transfer into and out of the MLE, and the contents of the data string is identical regardless of whether the formatting is honored or not.

I have even pulled the data out of the MLE which fails to honor the formatting and pulled the data out of the same MLE with the formatting honored, and compared the two at the hex level, and they are absolutely identical, same character count, same 0D0A pairs, everything.

So to make sure, I'm getting across the weirdness of this, here's an example set of steps:

- in the application, retrieve the data from the database and display the text in the MLE; it ignores the formatting, the text is shown squished together in a single word-wrapped line of text;

- manually select and copy that text from the MLE and paste it into Notepad; the formatting is honored, the text appears on multiple lines.

- select and copy the text from NotePad and paste it back into the MLE; the formatting is honored and the text appears on multiple lines.

- have the application save the contents of the MLE back to the database.

- close the app and reopen it. Retrieve that same data, the text appears in the MLE formatted - multiple lines of data.

So, what's happening? I assumed as I began the search, that the LFs and CRs were out of order, or missing or duplicated or some such. But as stated above, the text that ignores formatting and the text the honors the formatting is identical in character count and all of the characters, at the hex level.

I have to assume that there is some sort of flag or setting of some sort, but that would have to appear in the data stream and, as mentioned, the strings are identical for every comparison I can think of.

Any ideas?

Thanks,

Neil Sutter

 

Mark Goldsmith Accepted Answer Pending Moderation
  1. Tuesday, 21 December 2021 02:14 AM UTC
  2. PowerBuilder
  3. # 1

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

Comment
  1. John Fauss
  2. Tuesday, 21 December 2021 04:57 AM UTC
That's both an excellent analysis and explanation, Mark! Nicely done!
  1. Helpful
  1. Mark Goldsmith
  2. Tuesday, 21 December 2021 12:19 PM UTC
Thanks John ;)
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 21 December 2021 01:51 AM UTC
  2. PowerBuilder
  3. # 2

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

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Monday, 20 December 2021 22:38 PM UTC
  2. PowerBuilder
  3. # 3

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

Comment
  1. Neil Sutter
  2. Monday, 20 December 2021 23:06 PM UTC
Thanks John, I'll give it a try. wow, thanks for the extensive response.



Neil
  1. Helpful 1
There are no comments made yet.
Shenn Sellers Accepted Answer Pending Moderation
  1. Monday, 20 December 2021 19:33 PM UTC
  2. PowerBuilder
  3. # 4

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

Comment
  1. Neil Sutter
  2. Monday, 20 December 2021 21:38 PM UTC
Thanks Shenn, I intercommunicated a bit. When saying "format", I meant the formatting recognized by text editors: tabs, line feeds, and carriage returns. That is the only formatting needed in the MLE and that is the only formatting present in the strings presented to the MLE. Thanks for the reply, let me know if you have any other ideas on how to chase this weird, but interesting, issue.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 20 December 2021 19:19 PM UTC
  2. PowerBuilder
  3. # 5

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

Comment
  1. Neil Sutter
  2. Monday, 20 December 2021 21:39 PM UTC
Thanks Chris, will do,
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.