Code 180 and Large strings with Simple Text View

Question

Hi Gents,

 I have a large log.txt file I'm trying to pump into the GUI. I'm doing this by trying to append a SimpleText.String. But I'm getting:

EMWI ERROR: code: 180, info1: 81177174, info2: 13
For details please visit https://doc.embedded-wizard.de/errors
 

I gather SimpleText just can hold hundreds of lines of text. What type of component should I be using?

 

Mike // PP Systems

 

Answer 1

Hello Mike,

the error code 180 indicates that the string contains the character with code 13 and there is no glyph in the given font for such character. The code 13 is carriage return (CR). Embedded Wizard uses only code 10 (New Line, NL or \n) to terminate a line. If the original text file encodes lne ends with NL+CR simply remove the CR before appending the text to the text view. If the the text file encodes the line ends by the single character CR, convert this character to NL.

Also please take in account that the more text you append to the text view the more memory is needed to store this information.

Best regards

Paul Banach

Comments

Hrmm ... I traced it down to '\t' . EwNewStringAnsi() does not seem to like tabs. Or is it DefaultFont ?

---

Hello Mike,

from EwNewStringAnsi() point of view, \t (tab) is just a character code. There is no special restriction nor handling for this. Similarly, the text drawing operations treat \t as a regular character. If the used font does not contain the glyph for character code 9 (tab), the default glyph is used instead. This is the case for the Default Font. You have following options:

Option 1: Just before you pass the string to Embedded Wizard, process it and remove all \t and \r (CR) signs.

Option 2: If you want some tabulators, you can replace the \t characters by one or more blanks (code 32).

Option 3: In the attribute Ranges of the font used to display the text configure the character 9 to be mapped to some other character e.g. to blank (0x20):

Option 4: If its is essential to have text spans being aligned at particular horizontal positions (as tabulators do), you can use the Attributed Text view. In such case you can layout the text in tables with rows and columns. Please see the section Layout the text in columns.

Option 5: Use two or more Text views arranged side by side. In such case extract the text found on the left of a tab and assign it to the left Text view. The text on the right of the tab could be assigned/displayed in the right Text view. When the user scroll the contents, scroll both text views simultaneously.

I hope one of the above options help you to find a working solution.

Best regards

Paul Banach

---

Yup yup, stripped \t and high ascii at the lower level. All is well with code 180s.

Struggle I'm having now is feeding .log file f_gets() lines into a Device.String. f_gets() seems to overwrite Device.String so quickly the Obvserver (which appends them to a SimpleText) never picks up all of the changes. I think. I'm guessing that's the issue because if I slow it down with a Timer it works. Albeing much too slow with the 1ms delay.

---

Hello Mike,

maybe your actual approach is not ideal for this application case? I don't know your exact implementation, but I suppose you have some String property in Device and you assign to this property text fragments from the log, one by one. Each time new fragment is assigned the String property broadcasts a notfication. Thereupon the GUI can react and read the text fragment from the property and append it to some Text view.

This application case will not work if you change the property String multiple times within the same screen update cycle. In such case the alternations of the property are accumulated and the notifiction is broadcast only once after the last alternation. This is expected behavior, since properties are used to reflect a concrete value in the device. If the value changes quickly several times, the GUI displays only the latest value.

What can you do?

Option 1: Use the property String to store all log contents, not only the latest fragment. In other words, instead of appending the text fragments in the Text view, you can append the log contents to the String property. It reflects then the 'entire' log content.

Option 2: Instead of transfering the log fragments via a String property use the System Event to feed the application with new log data. Unlike the property, if you generate a sequence of events all events will be processed individually.

I hope it helps you further.

Best regards

Paul Banach