03-13-2017 06:52 AM
Hello all,
i am trying to limit the number of lines entered by the user in a string control. This string will be then exported to a text file.
This is what i have done so far but all in vain.
03-13-2017 07:28 AM
Lines, in this case, are defined by End of line-characters. A user writing in a text box can write a novel without a single line break. It'd be easier to simply use String subset and take the first 256 characters (or however long you want it).
/Y
03-13-2017 07:46 AM
03-13-2017 12:21 PM
An end of line will represent an end of paragraph in some application. If the text is wrapped you can use the string Get Nth Line method to determine the number of wrapped lines in your string control. Now depending available and the font used by the application where you export the content of the string control you can determine the number of line that you can allow in your string control (your string control dimension must be constant).
Here is a possible way to do this using the string Get Nth Line method, an event structure and the string Key Down? filter event. You can modify it to disable/enable some keys when you reached the max line number (e.g. disable the return key, enable the delete key, ...).
03-13-2017 09:06 PM
Try this:
03-13-2017 09:27 PM
@paul_cardinale wrote:
... only if you wire a TRUE to the "replace all?" on top, (else the answer is never more than 1).
I would also use the "line feed constant", more universal.
03-14-2017 07:42 AM
Thank you. I did forget the boolean. However the "End of Line Constant" that I used is more universal because its output is platform dependent. However to be truly universal:
03-14-2017 07:44 AM
Better yet:
03-14-2017 09:47 AM
@paul_cardinale wrote:
However the "End of Line Constant" that I used is more universal because its output is platform dependent.
The problem is that if you manually enter multi-line text into a LabVIEW string control, pressing <enter> will not insert a CRLF, just a LF (even on windows!!) so your original code will not be able to count the lines in that case.
I have not done any benchmarking, but "normalizing" the EOL can change the string length and thus cause memory allocations. I don't know how optimized the internal code of "Search&replace" is if the output string is unwired, but I would probably wire the LF to both inputs to keep the string size constant. Interesting questions to explore... 😉