01-27-2010 07:15 AM
01-27-2010 07:35 AM
Another approach is to create an enum (and make it a typedef) which lists all the actions you want. Connecting the enum to the selector of the case structure results in the text of the enum item appearing in the case structure. This part of the code then is self documenting! Use of an event structure like aeastet posted eliminates polling. I just added an enum to your VI rather than setting up the event structure.
Lynn
01-27-2010 07:39 AM
Johnsold wrote:
Another approach is to create an enum (and make it a typedef) which lists all the actions you want. Connecting the enum to the selector of the case structure results in the text of the enum item appearing in the case structure. This part of the code then is self documenting! Use of an event structure like aeastet posted eliminates polling. I just added an enum to your VI rather than setting up the event structure.
Lynn
You can use this method but then you still have to edit the code every time you add a button. The reason that I did the event structure the way I did was to make it maintenance free. Right click add a button and it is ready and working.
01-27-2010 07:56 AM
True. For just displaying the name of the selected button this works well.
In the original post a specific program for each case was mentioned, so I interpreted that to indicate that some editing would be needed anyway.
Lynn
01-27-2010 10:39 AM
nolsqn wrote:So my question is that is there any other way to implement this ... a rather more professional approach ?
01-27-2010 11:32 AM
I'm guessing what you want is a "released test launcher" which launches a predefined set of Test(x).vi's.
Create your enum. (you will be able to programatically change the property.Strings[])
Create a configuration file. Section [Tests Released] contains keys matching the enum property.strings[] and values of file paths (to the released vi's you want to launch)
the operator then selects the test from the enum and presses run test (your code opend the config file reads the vi pathopens a referance to it and run it from an invoke node
when you release a new test the operator (with admin privilages) goes to your add test button enters the test name and path to the vi and you update the config filwhen your app starts it can read the config file to learn what tests are released today that the operators can select from.
Easy-Professional-bullet-proof
01-27-2010 11:26 PM
my question was specific to , where i am using the search 1-D array , that is there any other way of comparing the strings ......because in the case of search 1-d array it gives me the index of the element which i am then using with the case structure to perform the specific tasks ..... in my program i know that my cases will increase and it will be deficult for me to use the index numbers as the reference to my case structure ..........
As i mentioned for examples if i change my program see the vi ... if i increase the number of options then its gets difficult to keep track of the 2nd case structure ..........the first case structure is there to assume the data coming in , which then gets compared with the existing array constant and then once it gets compared it performs the specific task .
Again my question is regarding the part where i am using the search 1-D array ....... how can i do that more efficently ? beacause i want to do my next step on the basis of this compare ...for example consider data is coming from the serial port and you know that the its a 1 byte of data and you also know that all of the combination of the input from the serial port and you want to make your decision , on first checking what byte of information has come and then doing the corresponding task....... so how can i implement this alternative to my basic approach ?
regards
01-27-2010 11:28 PM
to jeff Bohrer
can you send me an example of what you are talking about . just a basic example which i can use as a refernce?
regards
01-28-2010 09:49 AM
Place these on C:\
2 more vi's comming soon
01-28-2010 09:50 AM