Terminals can't pass current value in event case

[jackscl]

 

It's a very easy event case.

The problem is that the String to write (hex display) terminal passes the old value rather than the new value to the String out on my boss's computer when I clicked COM Write Button.But the problem never happens on my computer.Our computers' environment both are win7 and LabVIEW2014-Chinese.

Is there anybody can explicate this phenomenon? Thanks.

[RavensFan]

I can't think of anything that would explain what you describe.  It would violate the principles of dataflow unless there is something else happening off screen from the small screen shot you sent.

[Jacobson-ni]

Are you pressing COM Write as your key focus is still in the String to write field? If you are, try writing to the String to write field and then clicking somewhere else on the Front Panel before clicking COM Write.

I can't test this right now but I was talking to a colleague recently who was running into a similar type of issue which they avoided by changing the string control to update while typing.

[jackscl]

I upload the simplified VI .Please take a look,thanks.

[jackscl]

I upload the simplified VI on the 4th floor .Please take a look if you have time,thanks.

Maybe the mouse down event and button's mechanical action make the problem..

[billko]

What happens when you change the action of the String to Write to "Update Value While Typing"?  Like the others, I think maybe the control isn't actually updating if the focus is still on the String to Write.

Observe how your boss uses it as opposed to how you use it.  See if you can spot any differences.

Edit:

Yes, it's not updating until the focus goes away from the string control before you click the Com Write button, but changing the action to what I suggested results in some oddities.

Unrelated suggestion:

If a control or indicator is not using the default display, you'd better show the Display Style (for a string) or the Radix for a number to avoid confusion that could lead to serious problems.  (There's a world of difference between 255 decimal and 255 hex, for example.)

The whole VI could stand a do-over..

[jackscl]

When i use value changed event , the String to write passes current value.I will search the different between mouse down and value changed event.

Thanks for your suggestion.Usually I showed the raidx and display style in my code. .. this VI is not mine...the original author have left the company,and I took over it.This company like mouse down,but I like using value change...There may be many unknown pits waiting for me.

[rolfk]

---

@billko wrote:

Observe how your boss uses it as opposed to how you use it.  See if you can spot any differences.

---

I have a little anecdote about this. Back in a time where mobile phones didn't exist and phones with a keyboard instead of a dial were just starting to be appearing in the market, the company I was doing my education in had been designing a new telephone. In order to test it before mass production they would select a number of customers and install a telephone in their office to get field usage reports. From one of the customers they got consistent reports that the phone was always dialing the wrong number. They replaced the phone several times but the failure reports kept coming in.

So in a desperate attempt to find out what was the problem, they finally sent out one of the development engineers to just stand besides the telephone at the customer site and observe what might be happening. The problem was quickly found that way. The secretary working at that company was mildly put more a model than secretary. Besides makeup in abundances she also had huge fake finger nails. With the old dial phones that did not cause problems but with the new keys, she always touched the key in the row above first, so caused a wrong number to be dialed.

I guess it's another variant of PEBCAK. 

As to the problem at hand I wonder if it makes a difference to use the actual "New Value" terminal in the event structure rather than the control. I always use that terminal even if I don't need the control terminal anywhere else.

[Intaris]

Thread derailment detected.

Re: Dialing phones

Something similar happens to me with new touch-based Navigation and infotainment systems in cars. I tend to want to rest my wrist on the lower edge of the screen which more often than not actually registers as a button press and ocmpletely undoes all of my work (browsing for a particular song when you have >100k songs on USB takes a while).

My car has voice control and could theoretically play a certain song based on voice input, but the indexing only works for something like 20k files..... And it expects me to speak german so even then results are.... interesting. For calling people on my mobile it works a lot better.  I have less than 20k contacts in my phone.

[RavensFan]

Thank you for finally attaching the VI so we can see everything that is going on in the VI.

Others have already found your problem where the the original programmer used the wrong event and should have used Value Change and not Mouse down.

A few other problems.

1.  They put a bunch of unused terminals in sequence structure outside the loop, like they put some sort of fence around them.  Worse, they used a stacked sequence structure which hides some of them.  Those terminals belong in their respective event cases.

2.  There is blatant abuse of the Value property node.  They should have used the terminal instead.  Instead of having all those individual Value properties in multiple event cases.  They should *probably* be in the loop and read before the event terminal and connected to where they are used by wires.

3.  The stop button has problems with its label and the text on the button where it shows garbage characters rather than a readable word.