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