I am trying to take the readout from an instrument and if the readout matches certain strings (from the instrument programming manual) I want to set an indicator to a specific value, different for each possible string. A case structure seems like the best option, with all the possible readouts as the cases. I did this and added "" as the default case to send out a value for the no-match case. The trouble is that if I wire the readout string to the case structure it always executes the default case no matter what the readout (and yes, before anyone asks, I verified that the readout strings match my cases exactly). To check that the case structure was working I wired a constant to the case structure and it works fine, even when I copy and paste the value from the readout string to the constant. Also, I made sure that case insensitive matching was selected so that's not the issue. Anyone have an idea why this is happening? I can post sample VI's if necessary.
Found the problem. Converted the strings into byte arrays and looked at the ascii values. Apparently one had a new line character at the end even though there was no new line on the indicator. Fixed comparison by trimming white space on strings. Look out for that.
To check exactly what's in your string you can wire it to an indicator, right-click on that indicator and choose '\'Codes Display. This will then show codes such as \n for newline, \00 for ASCII 0, \FF for ASCII 255, etc.
Related
While using form fields I stumbled upon the following behavior of dynamically-sized fields. AFAICT, passing a right arrow key event to the form driver leads to appending of spaces to the field buffer. I.e., this:
case KEY_RIGHT:
form_driver(f, REQ_NEXT_CHAR);
break;
when the cursor is at the end of the field string will append spaces to the field buffer. I am baffled as to how this is the default behavior. IMHO, hard stopping at the end of the field buffer string would be the correct, intuitive behavior, and spaces should be appended only when the user explicitly does so.
Reading the source code I see this is tied to a compatibility macro(?) called GROW_IF_NAVIGATE? I see this as a prime example of a simple enhancement that allows the user to opt out of this behavior. In the meantime what are my options? Just trim?
EDIT: the behavior controlled by this macro is more bizarre than I originally thought. It only limits growth when moving after the end of the field as specified in the field creation. IOW, when the macro is disabled (0), after filling some part of the field the growth is still allowed until the cursor reaches the end of the field where the growth indeed stops. Trimming is perhaps the only recourse here.
From a cursory reading of the latest source code field navigation is not taking into the account the content of the field. The field buffer can be grown by either navigating to the right or typing in characters (or a combination of both). Navigation adds padding characters which are replaced with blanks when the field buffer is eventually evaluated. The macro GROW_IF_NAVIGATE allows/controls the growth of fields when the end of the field window has been reached.
It seems that the recourse is to either not issue the request to navigate to the form driver, and this requires keeping track of every and all field input, or simply discard all padding, but this invalidates input with trailing spaces.
I am working on an application that converts text into some other characters of the extended ASCII character set that gets displayed in custom font.
The program operation essentially parses the input string using regex, locates the standard characters and outputs them as converted before returning a string with the modified text which displays correctly when viewed with the correct font.
Every now and again, the function returns a string where the characters are displayed in the wrong order, almost like they are corrupted or some data is missing from the Unicode double width spacing. I have examined the binary output, the hex data, and inspected the data in the function before i return it and everything looks ok, but every once in a while something goes wrong and cant quite put my finger on it.
To see an example of what i mean when i say the order is weird, just take a look at the following piece of converted text output from the program and try to highlight it with your mouse. You will see that it doesn't highlight in the order you expect despite how it appears.
Has anyone seen anything like this before and have they any ideas as to what is going on?
ך┼♫יἯ╡П♪דἰ
You are mixing various Unicode characters with different LTR/RTL characteristics.
LTR means "left-to-right" and is the direction that English (and many other western language) text is written.
RTL is "right-to-left" and is used mostly by Arabic and Hebrew (as well as several other scripts).
By default when rendering Unicode text the engine will try to use the directionality of the characters to figure out what direction a given part of the code should go. And normally that works just fine because Hebrew words will have only Hebrew letters and English words will only use letters from the Latin alphabet, so for each chunk there's a easily guessable direction that makes sense.
But you are mixing letters from different scripts and with different directionality.
For example ך is U+05DA HEBREW LETTER FINAL KAF, but you also use two other Hebrew characters. You can use something like this page to list the Unicode characters you used.
You can either
not use "wrong" directionality letters or
make the direction explict using a Left-to-right mark character.
Edit: Last but not least: I just realized that you said "custom font": if you expect displaying with a specific custom font, then you should really be using one of the private use areas in Unicode: they are explicitly reserved for private use like this (i.e. where the characters don't match the publicly defined glyphs for the codepoints). That would also avoid surprises like the ones you get, where some of the used characters have different rendering properties.
What kind of sign is "" and what is it used for (note there is a invisible sign there)?
I have searched through all my documents and found a lot of them. They messed upp my htaccess file. I think I got them when I copied webadresses from google to redirect. So maybe a warning searching through your documents for this one also :)
It is U+200E LEFT-TO-RIGHT MARK. (A quick way to check out such things is to copy a string containing the character and paste it in the writing area in my Full Unicode input utility, then click on the “Show U+” button there, and use Fileformat.Info character search to check out the name and other properties of the character, on the basis of its U+... number.)
The LEFT-TO-RIGHT MARK sets the writing direction of directionally neutral characters. It does not affect e.g. English or Arabic words, but it may mess up text that contains parentheses for example – though for text in English, there should be no confusion in this sense.
But, of course, when text is processed programmatically, as when a web server processes a .htaccess file, they are character data and make a big difference.
Is it possible to read a text file to a string using fortran77.
I actually have a text file in the following format
Some comments
Some comments
n1 m1 comment_with_unknown_number_of_words
..m1 lines of data..
n2 m2 comment_with_unknown_number_of_words
..m2 lines of data..
and so on
whereas n1,n2.. are the orders of the objects. m1, m2,..are the number of lines which contains the data about these objects, respectively. I also want to store the comment of each object for further investigations.
How can I deal with this? Thank you so much in advance!
I can't believe nobody called me on this.. My apologies this in fact only grabs the first word of the comment...
------------original answer----
Not to recomend F77, but this isnt that tough a problem either. Just declare a char variable long enough to hold your longest comment and use a list directed read.
integer m1,n1
char*80 comment
...
read(unit,*)m1,n1,comment
If you want to write it back out without padding a bunch of extra spaces thats a bit of effort but hardly the end of the world.
What you can not do at all in f77 is discern whether your file has trailing blanks at the end of a line, unless you go to direct access reading.
------------improved answer
What you need to do is read the whole line as a string then read your integers from the string:
read(unit,'(a)')comment
read(comment,*)m1,n1
at this point comment contains the whole line including your two integers (perhaps that will do the job for you). If you want to pull off the actual string it requires a bit of coding (I have a ~40 line subroutine to split the string into words). I could post if interesed but I'm more inclined as others to encourage you to see if your code will work with a more modern compiler.
According to Oracle at JTextArea documentation, if you wish to wrap lines AND wrap at word boundaries and not character boundaries you must use code as follows:
jtaOutputPrimes.setLineWrap(true);
jtaOutputPrimes.setWrapStyleWord(true);
Please note that the jtaOutputPrimes is the name of my JTextArea on my JPanel.
The issue comes in when I use the method append to add text to the JTextArea as follows:
jtaOutputPrimes.append(",");
In this case, the setWrapStyleWord setting does not work. It continues to use the character boundaries and not the word boundaries.
I have found another person experiencing same issue here: setWrapStyleWord issue
Now, lets say you are running an JApplet that has this JTextArea. If you type in the text area, it will word wrap fine, but any passed text from the append method does not work.
I believe this is a bug, and I cannot find Oracle acknowledge it as such anywhere.
Can anyone help? Thanks!
I found out why this was happening, and this simple fix may be beneficial to others. The issue came into play because when I appended the comma (,) to the JTextArea it was eliminating the white space between words. To fix this, I simply placed a space after the comma like so, and it worked.
jtaOutputPrimes.append(", ");