Property node to check if running as executable

I want my Vi to automatically know if it is being run as an executable or as a VI so that I don't have to keep redirecting my reference path whenever I go back and forth between building a *.exe and running the VI
Is there a property node that checks??
Thanks, Kevin

Here is the VI in LV8.2.
It is better to check if Kind = Run Time System than Kind <> Development System.
Why ? Some day or on some computer, you might use an evaluation version of LabVIEW and the property will then return Evaluate for the development environment.
Attachments:
Is EXE.vi ‏9 KB

Similar Messages

Why knob need to use property node to change its value

Refer boiler vi in CLD exam sample question.
In the vi the knob vlaue is changed with a property node, it is not wired directly to a constant. The comment in the vi is something like "writing using property node because of the latch action of the booleans in the cluster"...
Huh? How do the booleans influence the knob even though they are in a same cluster? What principle is this called? I need to google this up, I didn't read it in.
my Labview books.
Attachments:
Boiler Main LV86.zip ‏61 KB

That comment doesn't make any sense.
There are two main reasons I can think of why you want to use a Value property node.
1. You want to control the order of execution by using the error wire.
2. You want to use a property node on multiple controls by feeding it references to different controls.
Neither of these appear to apply in the screenshot you show.
However, looking deeper, it looks like you can set the value of a specific item in the cluster by way of the property node. Check out the Link to section of its shortcut menu. I don't think you can use a local variable to set a given element of the cluster. Now you could change the value of the entire cluster. Read the cluster, bundle the new value for that one element, write to a local variable of the cluster. But you won't be allowed to do that because of the latched booleans that are a part of the cluster. Hover over the context help of that property node and read the description there as well.

Just checking on another odd feature: Typedef enum Property Node "Value" not reflecting changes in the Typedef?

Just encountered this odd behavior in LV 2011 which I reduced to the following example:
- create a new VI and drop an enum control on te FP.
- make this control a typedef and open the corresponding typedef
- create a "case 1" item and a "case 2" item
- save the typedef (I used the name Typedef Control 1) and CLOSE it (this is to allow updating of the original control).
- drop a case structure on the diagram and connect the enum to it:
So far so good. Now create a "Value" Property node for the enum and use it instead of the terminal:
If I now go back to the typedef and add a "case 3" item, save the typedef and close it, the control is updated, but the Property node is not.
How do I know that? For one, the Case Structure contextual menu does not offer to create a case for every value. Also, if I add a "case 3" case manually, it turns red.
Luckily, the magic Ctrl-R key stroke actually does solve this problem.
Tested in LV 2011.

By Ctrl-R trick do you simply mean running the VI? That is one way to force a recompile, but if you hold down Ctrl while pressing the run button you can recompile without running. This should not be "dangerous" in any situation.
As you have drawn your example, I see no reason not to use a local in that situation (ok, maybe for vanity). Still, I view the behavior you describe as a bug, and it should certainly be fixed for the benefit of local haters out there. You have to be a little careful where you draw the line between what gets handled in real time and what gets handled only at compile time.

Property Node in VI throws Error 7 in LV 7.1 but runs OK in LV80 and LV86

Hi everybody
I build a custom IVI instrument driver and using the LV tool <Generate VI Interface from Instrumnet CVI Driver> I was able to get a LV wrapper for each driver method. From LV86 I saved first in LV80 and from LV80 I saved as LV71. I have all these LV versions on installed on my PC.
I have no trouble in using these LV wrappers in any of these LV versions as they work OK.
Now my IVI driver has also Properties that the Import Driver Tool does not convert as a wrapper and for that reason I had to create a Property Node Warpper myself and saved in the same LLB under LV/instr.lib folder.
Once I have all these method wrappers and the property node wrappers I made a small VI
1. Initialize IVI With Options on a TCPIP instrument
2. Set-Get an IVI Timeout property
3 Close IVI driver on TCPIP instrument.
Good part is that in LV 86 and in LV 80 the VI is running fine when I use these LV version wrappers from their coresponding instr.lib folder.
As soon as I am going to use the LV 71 wrappers in LV 71 I could create the same small VI to Set/Get Timeout and the VI look OK nothing is broken but when I run it the Initialization is OK but as soon as is reaching the Timeout Set Property Node gets out an Error Code 7.
To run this VI the user need to install the jdCMR IVI driver then add the LV71 jdCMR wrappers inside LV71/instr.lib and then he may build any VI using these LV warppers.
The only problem is that the Property Node get out an Error Code 7 and the same error code get out from Property Node if I am picking the Property Node from VISA Advanced Pallette, connect this node to jdCMR driver, set Timeout property inside the node and after connecting the input and output references plus the input and output error to Initialize and Close LV wrappers I still get this error at running time.
The same LV 71 VI if I open in LV80 or in LV 86 runs without any problem?
Does anybody knows why LV 71 is not working the same way as LV80 and LV86 with respect to Property Node?
Btw When I save my VI from LV 80 to LV 71 I get this warning...
IVI Error Message Builder.vi
    Cannot save VI from VI.LIB to previous version.
Merge Errors.vi
    Cannot save VI from VI.LIB to previous version.
Thanks
Sorin

Hi
For further testing of the IVI driver Property Node bug with LabVIEW 7.1 IVI drivers I download and installed two different IVI drivers from two very known instrument companies, Rodhe-Schwarz and Agilent Technologies.
I have to mention that both these companies releasead their IVI NI LabVIEW 7.1 drivers under NI Instrument Driver Network and ready to be installed and used by any customer of these two instruments.
The bug is present only in LabVIEW 7.1 version as if I take the same VI that breaks in LabVIEW 7.1 I could run it without any problem in LabVIEW 8.0 or LabVIEW 8.6 versions.
Anybody could test this bug for these two NI released IVI drivers in simulation in LabVIEW 7.1 by following these links below.
Agilent ag81150ni IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=55798957B1A633BDE0440003BA7CCD...
   Rodhe Schwarz rsngpt IVI Driver for LabVIEW 7.1 install from here. Run in simulation only by setting Simulate=1
http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E91D6659CE034080020E748...
After installation complete close LabVIEW 7.1 if was open, then restart LabVIEW 7.1 and now you may see under the LabVIEW Instrument Driver Palette two new IVI drivers ready to be used as LabVIEW 7.1 wrappers.
Open a new blank VI and from Instrument Driver Palette use two well known Vis that are Initialize With Options.vi and Close.vi add them on your blank VI block diagram and connect thm together. Accept all default parameters except Simulate that must be Simulate=1.
Both Vis run OK in simulation mode without errors. Now pick a Property Node from VISA Advanced Panel and squeeze this between the Initialize With Options VI and Close VI and make the instrument reference in-out and error in-out connections.
Now run these two simple Vis in simulation
I run Rodhe Schwarz IVI driver and Property Node passes OK until the end
I run Agilent IVI driver but Property Node is getting out Error Code 7 that is the same as my own driver error.
Both these IVI drivers are under NI Instrument Driver Networks and have been built and integrated as native NI IVI instrument drivers.
Question is why they behave so different with respect to Property Node from the VISA Advanced Panel?
I attached the screen shots as PNG files that show clearly the difference of VISA Property Node behaviour when used under the same circumstances.
Thanks  Sorin
Attachments:
ScreenTestShots.zip ‏152 KB

Payment Wizard- If there is a check jam and the run was executed.

If there was a check jam and the check run was executed, can they run the payment wizard
using the saved executed run? What do they do?

You flag the check(s) as damaged and then you can re-print them and remember to verify the new Chk starting number.

VI Reference Property Node inside sub-vi

Hey Folks,
I was always curious about why this is:
If I open a vi-reference in one vi, and pass the reference to a sub-vi, I can put a property node in the sub-vi and get all properties just fine - as long as I am in debug mode. When I compile to an executable this problem has its own error message and everything. So why does debug mode not throw an error too? I'm just trying to deduce what the heck is the difference.
Check my painstakingly time-consuming example.
-Devin
I got 99 problems but 8.6 ain't one.
Attachments:
OpenMyReference.zip ‏42 KB

When I discovered this issue I was coding an "About" modal screen that a user could select from a run-time menu. This was supposed to work just like Labview's "Help->About Labview" screen, giving program description and version information. So I tried to simply link in the revision from my vi's proerties because that would automatically keep a revision count and I didn't care what the format was as long as I could get a number. I just wanted an easy way to check the revision, and its easy to give someone simple instructions to check the "about" screen. Is there an easy way for a user to check the revision if all I do is put it in the application builder? User-friendliness is key, because for me to support the application I will need to have them tell me the revision they are using over the phone or in an email.
Will it be possible to create this screen in 8? If I just do it in the application builder, is there any way to link to it and build an "About" screen? I don't really care what format. It could be revision 728 as long as a user can get to it in a simple way. Otherwise I will have to just build a screen with plain text on it and edit the text by hand every time I build an application. Isn't there a more elegant way to do it?
Message Edited by billings11 on 10-20-2005 11:28 AM
-Devin
I got 99 problems but 8.6 ain't one.

Is there a way to reference the property node value of a control in another VI?

Let's say that I have a situation like the one shown in the attached image.
I have an interlock system which is basically a bunch of booleans
If for example the "RF Enable" button in the "interlock VI" is true, then I should be able to flick the ON switch in my other VI (in the back), but if the value is FALSE, then it shouldn't allow it.
In other words, how do I check the value of a control across 2 separate VIs (running simultaneously)?
Thanks!!
Attachments:
sample.jpg ‏295 KB

Is one VI launched by the other, or are they launched independently? If it's the former then you just need to pass the control reference to the subVI via terminal node. If it's the latter there are a variety of ways to handle this:
Use a global variable - somewhat "sloppy" as it requires a global variable, and can lead to race conditions. In the "Interlock" VI you just set the value of the global variable when you change the value of the Boolean. In the other you're just reading it.
Action Engine - Ben wrote a Community Nugget a while back. Similar concept to a global variable.
Queue - The "Interlock" VI simply pops an element onto the queue with the value. The other VI just monitors the queue for a new element. It just needs to have something like a shift register to keep track of the last state.
Use the VI Server to access the controls of the "Interlock" VI. You can do this by accessing the "Interlock" VI's pane and get the control references. With the control reference you just need to get the value with a property node.
... (I'll let others chime in)

Is it better to use Invoke nodes or property nodes to set/get control values?

I have a series of VI's that run in parallel, each to manage different functions- pumping, sensing, a fluid flow model, an experiment generator/runner.
These need to exchange data, which I am currently doing using invoke nodes (that are all in subVIs), using methods "Set control value" and "Get control value". I find that every now and then (perhaps 1% of the time) the data isn't exchanged correctly and therefore the system doesn't work. I can imagine how "set" could go wrong if they happen simultaneously, and can devise ways of preventing this. However, the "Get" method suffers from the same problem. This is a major problem, because I want to leave it running for several hours.
I could in
principle achieve the same thing using property nodes and find myself wondering if this might be more reliable. But I don't want to change over only to find it makes no difference!
Can anyone advise?

You can use some kind of syncronization such as queues, occurances, or notifiers but I think the easiest way would be to create and action engine. This was only one action can execute at a time avoiding a "race condition". Possibly a write action and a read action might help. You also can add queues or notifiers into this concept. hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor

Error 1073807202 occurred at Property Node (arg 1) in VISA Configure

I am working with the 30-day evaluation version of LabVIEW
(Version 9.0 32-bit). I am attempting to perform the serial loopback test
described in NI's Developer Zone Tutorial, executing Basic Serial Read and
Write.vi. When I click the Run arrow a dialog box appears with the
following legend:
"Error 1073807202 occurred at Property Node (arg 1) in VISA Configure
Serial Port (Instr).vi>Basic Serial Read and Write.vi. LabVIEW: VISA or
code library could not be located. ...required drive not installed..."
I can find the "smplserl.vi" driver in the /examples folder on my PC.
What's wrong?

Did you do a search for that error? Install NI-VISA.

How can I make a "property node" for a VI?

Hello!
If I add a boolean button on the FP then I am able to make a property node for that button in the Block Diagram. But how can I make a property node for a VI? I have several VI:s an that together is one program. What I need to do is to verify what kind of VI some of my VI:s is. I need to verify if it is .exe or .vi-file, and if it is .exe then I want to disable run, abort, run continuously bottons otherwise not. I have hard that this is possible to do programmaticaly but I can´t figure out how. I am aware that I could do that manually in the File->vi properties->customize->windows appearance but theese choises makes it last forever.
I want to be able to stop and run and everything if it is a .vi file, but if it is .exe-file then all those buttons should be disabled.
Anyone have an example on this?
In an other message at this Forum I read "You can use the `Front Panel Window. Allow Runtime PopUp`" property to disable run-time shortcuts menues programmaticaly, but still I dont know how to create this property node.
/Amir

You really shouldn't open a new thread. If you don't understand something, ask and we will explain it.
Like I said in the other thread, you can check if you are running in LV or an EXE by using the Application>>Kind property. To get it, place a property node (from the Application Control palette) on the diagram, click it and find the property.
To set the properties for the VI, place another property node, right click it and select Select Class>>VI Server>>VI. You should have the properties you want under Front Panel Window.
To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf). I believe chapter 17 of the user manual explains about programmatic control of VIs.
Try to take over the world!

Disabled property node hangs loop

I've got a parser loop, operating on streamed data from a CRIO via UDP. The loop operates at about 90Hz. In response to the user opening a file, the code will use a property node to enable (or disable and gray) a couple of boolean front-panel objects. When these property nodes execute, I see the CPU usage (in Windows task manager) go to close to 100% and coincidentally, the parser loop hangs. Other loops within the same VI continue to run. CPU usage stays at 100% until I force a VI abort.
With a small test-VI, I've noted that these property nodes require roughly 10ms to execute. This seems quite sluggish, but nonetheless, my thoughts are that my code, running at 90Hz, would be able to tolerate a single slip of the loop execution time, particularly because the UDP data is queued.
Any thoughts regarding this property node execution time or suggestions on how to improve the code? Thanks in advance.

Mark, thank you for offering to look at a stripped-down version of the code. I just couldn't spare the time required to simplify our complex code. However, I've been working on this problem in the past couple of weeks since I originally posted the question, and have made some progress toward a solution. Although I still do not have a conclusive explanation for the Labview's behavior, I thought I'd follow up with a list of what appears to have made improvements to the code. I'll concede that these suggestions are not definitive, but the problems are not repeatable and without any transparency into Labview's internal behavior, my analysis of the problems and my attempts to find a fix are admittedly speculative in nature. Software development shouldn't be magic, but damn it seems like Labview requires we dance around a black candle. Frustrating. OK, exiting rant mode, here is a list of what NOT to do if you want Labview to be more stable:
-- Do not use frames around your front panel objects. Our main panel has approximately 100 front-panel indicators. In an attempt to make the interface more intuitive, in a recent code revision we grouped the objects using frames. The effect was a sluggish UI and a processor loading that went to close to 85%. I'm aware from posts on this forum that overlapping indicators forces Labview to update all when any is updated. This is an understandable coding contraint. OK, fine, we weren't overlapping any idicators. But for pete's sake, why should the same constraint apply to a purely decorative object like a frame? This strikes me as a fundamental philosophical flaw in LV's coding. Group N objects with a nice frame -- update the objects N-squared times. If this is the result of using a frame, I would have preferred that NI not even offer the option. Bad choice on the part of the Labview coders and bad choice on our part for assuming zero frame impact on performance.
-- Do not use property nodes. We occasionally gray-out front panel objects when appropriate for the state of the software. This appeared to be contributing to Labview's instability. I built a diagnostic routine that measures execution time for the "gray-out and disable" property node. Generally around 8ms, but occasionally as high as 16ms. Good grief. I've got a code loop running at 90Hz. A 16ms hit isn't easy to tolerate or frankly to understand. Particularly when slow execution is the BEST of the consequences -- the worst is that the property node seemed on occasion to precipitate a hung loop.
-- Do not use Labview's built-in queue structure. Our code was originally using queues to hand off packets of data from a UDP-listener loop to a packet-parser. The UDP-listener blocks on UDP reception, shoves the packets into the queue. The packet parser blocks on data available in the queue and subsequently writes the data to file. NI would have you believe, and I did believe for a while, that this is an elegant producer/consumer approach to this problem. When our problem would occur, the UDP-listener continued to put data into the queue, but the packet parser would never retrieve it. Just went off into nowhere, consumed and forgotten by the Great Labview Scheduler in the Sky. The loop would hang, wouldn't respond to the stop button, would require a forced-abort. Subsequently, if we simply restarted the code, we couldn't be assured that the packets retrieved from the queue would be in chronological order. Seemed to be just randomly retrieved. Clearly the failures had corrupted some of the Labview internal data structures that govern the queue operation. We couldn't assure proper behavior unless we shut down and restarted Labview each time the error occurred. The solution was to abandon code elegance in favor of sequential operation -- get rid of the queue, listen for the UDP packet then parse it immediately. No queue handoff. No further parser lock-ups.
I'm not sure what other bombs might be lurking in our code. Our listener and parser code hasn't lately hung, but the problem is starting to move on to other loops. They'll run for hours and then just stop. Dead. Frozen. In the most recent cases, even the abort button won't shut them down. We have to use Windows Task Manager to kill them. I'll admit to harboring some deepening skepticism for any of the more clever and powerful "features" that NI has added to LV. From my perspective, these more powerful features cannot come free of cost -- they must impose some unavoidable computational burden on LV itself, a burden that LV seems unable to handle, with unpleasant consequences. Must we impose a moratorium on Timed Loops? Event structures? To what level of simplicity must I drive our code to ensure stability?
Thanks, everyone, for tolerating my frustration, and for your comments, if you've got any guidance you can offer.
-dave sprinkle

Error -70038 occurred at Property Node in nimc.fb.power.power.coordinate.vi

HI,
I created a Real Time application with debugging enabled that only makes a straight line move and then finds center (using SoftMotion function blocks). When I run the VI from the project everything works fine. When I create the executable and run the application as a start up some times it moves beyond the limit switches and I have to abort the application, it never really works as smooth as it does when ran directly from the project.
I simplified the application. When connecting to the executable ( Operate>>Debug Application or Shared Library...)
I saw that sometimes I was getting an error that said the find center function could not be executed because the driver was not enabled. This was never needed when running from the project. I added the Power SoftMotion block and I enabled the driver before getting into the while loop that finds center. Again the VI ran without errors when ran directly from the project, but when I connected to the executable I found the following error coming out of the Power SoftMotion block (the name of my VI is: "Testing SEND to ZERO by itself.vi"):
"Error -70038 occurred at Property Node in nimc.fb.power.power.coordinate.vi --> Testing SEND to ZERO by itself.vi
Possible reason(s):
Motion: An unexpected error has occurred internal to the driver. Please contact National Instruments with the name of the function or VI that returned this error"
I am using cRIO 9022 as a controller and two 9512s.
LabVIEW 2009
NI-RIO 3.2.1
SoftMotion
Any idea why the VI works fine when ran directly from the project but does not work as expected when ran as a stand alone application directly on the cRIO?
Thanks,
Fab
Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion

Marc,
When I simplified my program, I forgot to put the Power Function block inside a loop and make sure I was sending a pulse for the execute input. I am guessing that could have caused the weird error.
If I see it again, I will let you know.
Thanks,
Fab
Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion

Property nodes to items in cluster are FRAGILE

This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

CoastalMaineBird wrote:
This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
For the disabled property inside of cluster whos definition hcanges... we are screuued.
For the events your idea to include the text name, is the same technique that Jim Kring shared with us when he discovered the same thing can happen with dynamic event references. I belive that was CAR'd.
No solutions so no bonus points.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Tab Page visible property node not working correctly

I am making a vi in which we have a tab control with 6 pages and to move from one page to another there is ring control with option for every page on page 1( page 1 is the default page), at a time only one page is visible so we can move only through that ring control present on page 1 and to come back to page 1 from all other pages there is button "go back" on all other 5 pages, everything is working fine for 5 pages but when after going on page 6 and then if i press go back button instead of going back to page 1 program hangs and one more thing that i noticed is after stopping the program the page 6 becomes the default page( which otherwise is page1) i dont know why this is happening.
I am attaching the snippet of the code which executes when i press go back button.
one more thing that i am not getting here is when i checked the program through step execution, the last property node( page6 ) that is executing first after that it goes to first property node and then it goes in sequence, this also i want to how is this happening.
Solved!
Go to Solution.
Attachments:
tab page property node.png ‏43 KB

I think you would be better off just to use your array and turn on/off the necessary tabs instead of explicity setting each property every iteration.
Attached is one example.
"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
Attachments:
set visible tabs.png ‏56 KB

All objects property node and grouped objects

Hi
I am trying to position a the objects on my GUI in the centre of the screen using property nodes. However, I do not want to have to have a property node for every decoration, image and control. Is there a way that I can group all the objects and then use a property node to position them? I have tried using the all objects property node but none of the indexes seems to apply to my group of objects.
Help please!
Many thanks.
John
p.s. i have uploaded my test vi's. The chart, decoration and exit button have been grouped. use the control on check.vi to set the object to move.
Solved!
Go to Solution.
Attachments:
check.vi ‏13 KB
run.vi ‏13 KB

Tab pages are a nice way to group GUI objects.
Instead of using a decoration,
use a tab control
Remove all but the first tab
Hide the tab
Set the proprties of the tab control and the control on that page will move, hide, show along with the tab control.
I hope that helps,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Property node to check if running as executable

Similar Messages

Maybe you are looking for