I have had great success in implementing the MultiEdit Widget for use as a text editor in an embedded application.
The text files that the MultiEdit widget edits are script files for the application, and is stored on an SD card or USB stick.
One observation that I have noticed is that when I use MULTIEDIT_GetText() to save text to the SD or USB, MultiEdit only terminates lines with a LF and not a CRLF for each line of text.
This poses a problem when opening the exported MutiEdit file with Notepad when trying to edit the text file missing CR characters. More intelligent editors will automatically interpret the LF as a CRLF.
If I import a text file from NotePad (or another external text editor) into MULTIEDIT, the widget has no problems with the CRLF characters. It also will save the text file with the CRLF character intact.
If I change a line of text in MultiEdit followed by CR, then that line of text will not have CRLF, only LF.
My work around for this is I analyzer every character being stored to the USB or SD card, and if I detect a LF without the CR, I insert the CR before the LF.
This way text files saved from MultiEdit can be opened in an external text editor.
I thought I would let you know, perhaps a minor fix to a future revision.
Thanks again.
The text files that the MultiEdit widget edits are script files for the application, and is stored on an SD card or USB stick.
One observation that I have noticed is that when I use MULTIEDIT_GetText() to save text to the SD or USB, MultiEdit only terminates lines with a LF and not a CRLF for each line of text.
This poses a problem when opening the exported MutiEdit file with Notepad when trying to edit the text file missing CR characters. More intelligent editors will automatically interpret the LF as a CRLF.
If I import a text file from NotePad (or another external text editor) into MULTIEDIT, the widget has no problems with the CRLF characters. It also will save the text file with the CRLF character intact.
If I change a line of text in MultiEdit followed by CR, then that line of text will not have CRLF, only LF.
My work around for this is I analyzer every character being stored to the USB or SD card, and if I detect a LF without the CR, I insert the CR before the LF.
This way text files saved from MultiEdit can be opened in an external text editor.
I thought I would let you know, perhaps a minor fix to a future revision.
Thanks again.