05-22-2013 11:36 PM
Development Platform: 32-bit Windows 7, LV2012 Professional Development System.
Production Platforms: Windows XP.
We have a test application we've developed (in a hurry, I might add) that has a curious issue. As part of the setup for each test, we read a text box with a serial number entry and record it in the log files. Standard enough.
This works fine on the production machines - no apparent problems.
However, on the development machine, when I try to read the text box, all I get is an empty string. I've tried reading it directly from the terminal, as well as using a Value property box. Every time, there is nothing in the string. This is even if I'm looking at the text box and there's data visible in it.
I do clear the text box on several occasions, so I'm looking to see if one of those is occurring at the wrong time. And, indeed, I'm currently looking at a probe value of "" from the Value property node with the string "1234" visible in the text box while NONE of the clearing functions have been hit.
The test application uses a fairly standard user interface event loop model, with one event loop handling user inputs and the other event loop handling the business logic.
Does anybody have any idea what might cause this, or a better search string to find clues?
Thanks,
Geoff
Solved! Go to Solution.
05-23-2013 05:05 PM
Hi GeoffF,
I understood that the executable works on production machines but it didn't work in the development machine, am I right?
Does the VI work in the development machine?
Best,
Carmen C.
05-23-2013 05:58 PM
Hi Carmen,
That's correct. Everything works fine in the development machines using the executable. However, when running the executable OR the VI on the development machine that particular text box does not respond.
To clarfity further, there is another text box that is already on the front panel that does respond properly. (It has to for the test to proceed, as it is the Part Number entry field, which selects the set of tests.) The suspect text box was copied from that first one and renamed. I have looked to see if I've created multiple copies, but can't see anything to suggest that.
There are other text boxes on other tabs of the front panel, too, but mostly they're parts of clusters. All but this one respond correctly.
Regards,
Geoff
05-24-2013 12:43 AM
Actually, change that second sentence in my last reply:
Everything works fine in the production machines using the executable.
It seems to work OK in a second Windows XP development machine, but this is yet to be confirmed.
05-24-2013 08:08 AM
GeoffF,
Make sure that the first development computer has all the necessary driver.
Carmen C.
05-26-2013 08:43 PM - edited 05-26-2013 08:46 PM
Hi Carmen,
The driver set should be OK, since the production machines were set up using an installer built on the development machine. I would hope that the production environment would work the same as the development environment.
On the original issue, I seem to be having a timing issue. I have noticed a few log entries on a machine with the production environment that seem to have the serial number behind by one. That is, I enter "1", then "12", then "123", then "1234" and so forth and the log entries show "" twice, then "12", then "123" and so on.
Regards,
Geoff
05-26-2013 10:48 PM
As promised, I did get to the bottom of it.
Simply enabling "Update Value While Typing" gave me the result I expected.
To explain: I had a Key Down event for the first text box from which this text box was copied. Every time a key was hit in that text box, the value would be read and updated. I did not have any events for the new text box. It wasn't updated until certain other events happened. By then, it was apparently too late (most of the time on the development machine and some of the time on the Production machine).
Enabling the "Update Value While Typing" flag meant that the value field would be properly up-to-date every time it was viewed/accessed.
Life is a learning experience...