Here is a unusually chunk of code that caught me off gaurd! First off I could not reproduce at home last night so it resides in the attached snippet.
Before any of you ask "What Was Jeff thinking while coding up that disgusting mess?" I'll point out that I was working with another developer and he was picking my brain after I caught hime out on a R-G construct. (see proof of RGness in the first loop). the session had no point other than to slap some items down from the pallate and exploer them. Things like the odd uses of concat strings got mentioned etc...
All of the sudden my screen looked like this:
There is something not quite right about "concatenated string" I replaced with silver, modern, classic and system- no change thats right the text.text stopped respecting the object bounds!
Now look even CLOSER. concatenated string is a string cat of array. it is SORTED!
I suspect there is a LabVIEW enforced Race condition here:
since anyone would be out of their mind to actually wire up some of these function like this LabVIEW ensured my mind was blown.
now in case your mind is not sufficiently blown. place a conversion bullet to U8 in the first loop
(note this does not change the data type into the second loop because on the coersion into Riffle and "Poof" All better!
How did you get a cyan coercion dot?
Tools>>Options>> Environment- Colors uncheck default.
I thought I'd made it understood long ago that coersions are ugly! (there are some other default colors in my LabVIEW.ini too! like "Warn", "DAQ", "Util"...):smileywink: I chose the nastiest coersion dot color I could find! I never miss a coersion- but let 'em live if I can stand 'em!
I have heard of this behavior happening in past versions of LabVIEW when text is changed from normal to bold with a property node, but that doesn't seem to be the case here.
What version of LabVIEW were you running? I'd like to try to recreate the bug myself.
The snippet was created in 2011SP1.(32) I was not able to recreate at home on 2011f2(32)
the PC that created this
with a Xenon
I donwloaded the snip at home last night and confirmed the behavior still existed
I managed to recreate this bug have reported it under CAR #353347. It may be remedied in a future version of LabVIEW.
Jeff Bohrer wrote:
I appreciate the effort. can you provide details? what did happen, how can I predict it may be happening...
Old joke time:
A man went to the doctor coplaining about eye pain in the morning after drinking his marning tea. Dr said "Tell me more. What exactly do you do prior to the
Man replies, "I pour my tea add some sugar and stir it. Then I take a sip and then the pain."
Doctor replies "Next time, try taking the spoon out of the cup before drinking."
I referenced this joke many times with my son growing up when he would do something stupid and get hurt. He would lokk at me and I would simply say "Don't do that!"
We would benefit from knowong "what it is" that we should not do to avoid this issue.
Ben & Jeff,
I couldn't determine an exact guideline to follow to ensure that the text doesn't appear outside of the indicator. Whether or not the text is displayed incorrectly is definitely a function of the size/shape of the text box. Generally, the smaller the text box is and the shorter the string that is being displayed on the indicator, the more likely the text will stay inside the window. Using a smaller text box and toggling the vertical scrollbar is the best workaround that I have come up with thus far.
As far as I can tell, this behavior is only a problem with "Normal Display." Password, Hex, and '/' Code display work fine. Also, if you disable "Enable Wrapping," all of the text will remain inside the textbox, but you may have to toggle the horizontal scrollbar to see the contents of the textbox.