From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
06-04-2012 04:09 PM
Hello:
Have an application with a front panel string input that behaves properly.
Problem is that when I use Application builder this Particular string box does not allow me to enter any data
Data flow as follows:
Main VI name 'text mess" then goes to local variable and then to a Sub vi
Sub vi front panel name is also "text mess" inside of this vi it all handled as a local variable
Somehow Application builder has a problem
Do I need to initialize the string box?
Does Main vi string box have to be the same size as the Sub vi?
Does the fact that Main vi string box and Sub vi string box have the same name cause a problem?
Thank for the help
06-04-2012 04:36 PM
First of all, there are no string boxes
There are string controls and string indicators. What do you have ?
Second, with that many times you mention local variables, I'm thinking overuse/misuse of local variables.
Maybe a race condition ?
You need to show us some code.
And no there are NO link between the name of you main vi's controls/indicators and the sub vi's controls/indicators.
06-04-2012 04:58 PM
Off-hand I would say to get rid of your local variables, as dkfire elluded to. Use wires to your sub-vi instead. Please post your code.
06-04-2012 05:06 PM
@ge Osmonics wrote:
Somehow Application builder has a problem
Well, unless you tell us what kind of problem you have, we cannot help. Are there any error messages?
Does it run fine in the development system? (it is hard to tell from your post).
What is your LabVIEW version?
Could it be it is an indicator instead of a control? (this distinction is easily lost when overusing local variables)
GE Osmonics wrote:Do I need to initialize the string box? No! I don't even nkow what you mean by that.
Does Main vi string box have to be the same size as the Sub vi? No! Cosmetics don't matter, just the data.
Does the fact that Main vi string box and Sub vi string box have the same name cause a problem? No! You can even have controls with the same name in the same VI.
06-04-2012 06:51 PM
This may not be a problem with your code, but the setting of an environmental parameter. If you have checked the setting for "End text entry with Enter key" in your editor, this option will not be applied in your application. Look under Tools -> Options -> Environment -> End text entry with Enter key. The default is unchecked.
If it is checked, you have three options:
Create an INI for your application that contains returnKeyAction=True
Change the builder option to include the LabVIEW.ini file
Set the text control to Limit to Single Line
06-04-2012 10:39 PM
Hello:
Environment: LabVIEW 2011 SP1
VI works fine in development environment
Program origin goes back to version 4.0
Program is stacked sequence within stacked sequence ect... (text based architecture)
Global/local variables dominate maybe some 48 locals
Typical architecture is stack sequence ringed by all front panel control/indicators.
This seems to be the approved way at least 25 front line vi built this way
Application builder String controls (3 lines or more) will not allow input.
Smaller one line types work fine. Hope environment setting is the problem
Thank you for your help
06-04-2012 11:09 PM - edited 06-04-2012 11:11 PM
@ge Osmonics wrote:
Hello:
Environment: LabVIEW 2011 SP1
VI works fine in development environment
Program origin goes back to version 4.0
Program is stacked sequence within stacked sequence ect... (text based architecture) What do you mean by text based?
Global/local variables dominate maybe some 48 locals -- I think many of these can be replaced with wires.
Typical architecture is stack sequence ringed by all front panel control/indicators. -- Hard to maintain
This seems to be the approved way at least 25 front line vi built this way -- In what universe! Stop with the bad habits and use the correct archetecture. Your probably dealing with inherited code here, but I hope you have learned from their mistakes.
Application builder String controls (3 lines or more) will not allow input.
Smaller one line types work fine. Hope environment setting is the problem
Thank you for your help
Can you post your code?
06-05-2012 05:23 AM
@ge Osmonics wrote:
Hello:
Environment: LabVIEW 2011 SP1
VI works fine in development environment
Program origin goes back to version 4.0
Program is stacked sequence within stacked sequence ect... (text based architecture)
Global/local variables dominate maybe some 48 locals
Typical architecture is stack sequence ringed by all front panel control/indicators.
This seems to be the approved way at least 25 front line vi built this way
Application builder String controls (3 lines or more) will not allow input. What is 3 lines or more?
Smaller one line types work fine. Hope environment setting is the problem
Thank you for your help
Could it be that you have some timing issue that is resetting the control ?
Could it be that the control is disabled ? You know you can disable a control, so that you can't enter anything.
I would also change the program now, and remove ALL the stacked sequence structures.
I have never heard about a text based architecture that worked in a data flow programming language.
I have never ever used a stacked sequence structure, and I'm not planing on using them.
06-05-2012 07:36 AM
You may also have your string control limited to a single line. Right-click the string control and verify that "limit to a single line" is unchecked.
06-05-2012 09:05 AM
Hello:
Solution found the "String box" was configured as an indicator.
The String indicator was converted to a local read variable which feeds a sub vi String indicator.
In the development environment you can type into the indicator then press the run button and the text will communicate through the local variable and be display properly
by the sub vi string indicator. This VI was used for 15 years like this.
All these old VI s require front panel data configuration / fill out followed by pressing the run button.
In Application Builder I configured the VI to come up in non auto run allowing the user to fill out the front panel and then press the run button. The application builder indicator will
not allow you to type text into it (like the development environment) so it will not work as expected