LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

String box rejects input after built with App Builder

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

0 Kudos
Message 1 of 14
(3,084 Views)

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.

 

0 Kudos
Message 2 of 14
(3,076 Views)

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.

-----------------------------------------------------------------------------------------
Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 3 of 14
(3,070 Views)

@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.




0 Kudos
Message 4 of 14
(3,065 Views)

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

 

 

Michael Munroe, CLD, CTD, MCP
Automate 1M+ VI Search, Sort and Edit operations with Property Inspector 5.0, now with a new Interactive Window Manager!
Now supports full project automation using one-click custom macros or CLI.
0 Kudos
Message 5 of 14
(3,055 Views)

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

 

0 Kudos
Message 6 of 14
(3,040 Views)

@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?

-----------------------------------------------------------------------------------------
Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 7 of 14
(3,036 Views)

@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.

0 Kudos
Message 8 of 14
(3,023 Views)

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.

-----------------------------------------------------------------------------------------
Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 9 of 14
(3,012 Views)

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

 

 

0 Kudos
Message 10 of 14
(3,002 Views)