Darren's Weekly Nugget 06/19/2006

Have you noticed the new "Call Setup..." menu option when right-clicking subVIs in LabVIEW 8.0?  It's a really handy way to clean up your diagrams, and improve the load times of your VIs:
The code in the two frames is functionally equivalent.  In the second frame, I simply dropped the subVI on my diagram, right-clicked and chose Call Setup.  Then I selected "Reload on each call".  That makes the code function the same as doing an Open/Call By Reference/Close, like in the top diagram.  If I had selected "Load and retain on first call", the VI would be loaded into memory the first time it is called, but its reference would be kept in memory if the code is ever called again (like if this frame was in a loop).  If I had selected "Load with callers (like subVI)", it would behave exactly like a normal subVI (and the little "Call By Reference" halo around the VI would be removed).
So in this example, we are using Call Setup primarily to clean up our diagram, since both frames do exactly the same thing.  But there are some cases where it can improve performance as well.  One example where I have used Call Setup is in the VI Analyzer 1.1.  The subVI we use to load a configuration file in the VI Analyzer is rather large (with hundreds of subVIs).  In VI Analyzer 1.0, this subVI was called statically, meaning whenever you launch the VI Analyzer from the menus, this VI (along with everything else in the VI Analyzer) had to be loaded into memory.  In VI Analyzer 1.1, we used Call Setup on the file loading VI and selected "Load and retain on first call".  This improved the VI Analyzer launch time quite a bit, since now we only load the file loading VI into memory if the user needs to load a VI Analyzer configuration file.  In other words, with version 1.1, the waiting time it takes to load the file loading VI is only experienced by users who need to load a configuration file...with 1.0, everybody had to wait.
-D
P.S. - Check out past nuggets here.
Message Edited by Darren on 06-19-2006 12:38 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Call_Setup.jpg ‏149 KB

Hello Darren, i have a major problem with the call setup.
You mentioned that there are no more problems when the connector pane changes, well i couldn't figure that one out.
I have a large Application where i use a lot of the call setups when i made some chenges in the connector pattern i never get an error message.
When i build the exe file there is no error message coming up during the build process, it only comes up when the programm reaches the call and the error message only says :
Error 1031 occurred at Call By Reference Node in Untitled 1
Possible reason(s):
LabVIEW:  VI Reference type does not match VI connector pane.
With this kind of error message i can't even find out which Vi the error caused,
so i have to check each call setup in the VI.
This is even worse then in the old style, because if you had an error there you also saw which VI it caused.
So what possibility is there to make a general test of all VIs loaded with a call setup?
It seems to me that with the call setup the connector pane is picked once when you create a call setup from the normal vi,
and it only updates the connector pane when you do again your right click and set the call setup again.
why does it not normaly update the actual connector pane???
I also didn't understand that in the LV 7.x Version. because there was the same problem with the conector pane.
Why isnt there a possibility to auto update the connnector pane????
Greetings Daniel

Similar Messages

  • Darren's Weekly Nugget 08/08/2006

    As of this morning, LabVIEW 8.20 was officially announced at NI Week 2006.  I am going to use the next few Darren's Weekly Nuggets to describe some features I personally added to LabVIEW 8.20.  These are the kind of features that (hopefully) make people say, "Whoa, cool!", yet aren't quite big enough to make it as bullet points on marketing material.
    For starters, I'll mention the Remove Breakpoints from Hierarchy utility that you will find in the Edit pull-down menu of any open VI.  Selecting this menu option will remove any breakpoints you have set in the current VI (i.e., the VI from which you selected Edit > Remove Breakpoints from Hierarchy), along with any breakpoints in the current VI's subVIs.  A summary dialog then comes up and indicates how many breakpoints were removed from each VI in the hierarchy.
    I've seen this feature request a number of times on the NI Discussion Forums, so I hope the word gets out to everybody who has wanted this feature in the past.
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    hallelujah!  thanks to NI for listening!  I've been wanting that feature for sometime now. 
    2006 Ultimate LabVIEW G-eek.

  • Darren's Weekly Nugget 08/14/2006

    I hope everyone who attended NI Week 2006 had a good time...my favorite part was getting to ride a Segway, which I had always wanted to do.  My favorite product demo was probably the Rubik's Cube solver, complete with motion-controlled "robot" hands that actually solved a cube that I had personally mixed up.
    Anyway, this week's nugget is part 2 in my "Cool Things Darren Added to LabVIEW 8.20" series of nuggets.  I remember thinking a while back that it was a little weird that I could right-click on a control in a Global or Control VI and choose Advanced > Hide Control, but then really have no way to show that control again, other than writing a VI to do it.  So in LabVIEW 8.20, you'll notice a new menu option to allow you to do this.  Just select Edit > Show Hidden Controls and Indicators in a Global or Control VI, and all hidden controls and indicators will be displayed, along with a summary dialog showing the labels of all controls and indicators that were shown.
    The menu option is not available with regular VIs, but you can still use this feature relatively easily on them.  Just open [LabVIEW]\project\ShowHidden Core.vi, specify your VI name, and run it, and all hidden controls will be shown.
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Darren wrote:
    The menu option is not available with regular VIs, but you can still use this feature relatively easily on them.  Just open [LabVIEW]\project\ShowHidden Core.vi, specify your VI name, and run it, and all hidden controls will be shown.
    To add this option to the tools menu you can use the attached llb to use it in regular VI.
    Just drop it in LV82/project and you will get the "Show hidden controls and indicators ..." in Tools menu
    Darren do you have some new way in 8.2 to cusomize the LabVIEW environment? Like /projet to add menu in "tools" menu, /wizard to add in "file" menu. Do you have some nugget on this subject?
    Dany
    Dany Allard
    Attachments:
    ShowHidden.llb ‏84 KB

  • Darren's Weekly Nugget 08/28/2006

    Here's an obscure one for everybody.  The In Range and Coerce function (Functions > Programming > Comparison palette in 8.0 and later) takes many different datatypes as inputs.  One of the datatypes it accepts is a path.  Prior to LabVIEW 8.2, the In Range and Coerce function would always return False for its "In Range?" output if you wired paths as inputs, no matter what the values of the paths were.  In LabVIEW 8.2, however, the function can actually do something with paths.  Specifically, it will check the ASCII values of the path characters and indicate whether or not the input is within the specified range.  Check out this screenshot:
    As you can see, the value of "c:\blah4.txt" is determined to be "in range", i.e. in between the values "c:\blah1.txt" and "c:\blah5.txt".  I don't know when I would possibly use this behavior, but it's nice to know it's there.
    -D
    P.S. - Check out past nuggets here.
    Message Edited by Darren on 08-28-2006 10:40 AM
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    In_Range_Coerce_8_2.jpg ‏113 KB

    [...] As you can see, the value of "c:\blah4.txt" is determined to be "in range", i.e. in between the values "c:\blah1.txt" and "c:\blah5.txt".  I don't know when I would possibly use this behavior, but it's nice to know it's there.
    I could imagine a scenario with VIs myVI_1.00.vi, myVI_1.01.vi, myVI_1.02.vi ... of different versions that are located in the same directory and wait to become loaded dynamically. Inside a possible caller, set the borders of the coerce function programmatically to the highest/lowest available VIs (assuming subsequent VI versions are all available) and the caller gets a VI loaded - whether requesting a VI name in range of the available VIs or a newer/older version that ist not there.
    May sound a bit academic, but it can easily achieve some cool "injection" abilities of testing newer/older VIs without changing the caller's code, if this itself is prepared to handle dynamic VI calls! I know this could be achieved with other comparison functions, too - but one can say the same with the coerce function itself.
    Greetings,
    Hans

  • Darren's Weekly Nugget 02/27/2006

    This week's nugget deals with front panel control references. If you need a control reference on the panel (like when you're sending a control reference into a subVI), you typically drop a Control Reference from the Refnum palette on the front panel, right-click, and choose the appropriate class. Also you sometimes will have to right-click and choose "Include Data Type" when dealing with a control class that may have more than one data type associated with it (like a single-select vs. a multi-select listbox). This gets even more confusing if the data type of the control you're dealing with is not the "normal" data type of that control (an array data type listbox is a good example).
    Turns out there's a much easier way to create a class-specific, type-specific control reference on the front panel. Assuming you already have the appropriate control (like our afore-mentioned listbox) on your front panel, just drop a control reference on the front panel, then control-drag the control *into* the control reference. You'll see that the control reference automatically adapts to be of the proper class and data type of the dragged control.
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Aitortxo wrote:
    I used to create a reference from control, then right-click and create control, and then cut-paste to the SubVi front panel.
    I did it this way as well...  Now I have to write a vi to try this out!
    Thanks Darren!

  • Darren's Weekly Nugget 05/08/2006

    In LabVIEW 7.x and previous, you can highlight multiple objects on your panel or diagram and press Ctrl-A to perform the last alignment operation you performed from the "Align Objects" button on the toolbar.  In LabVIEW 8.0 and later, pressing Ctrl-A now does a "Select All" operation on the panel or diagram.  This makes the Ctrl-A operation in LabVIEW more consistent with other applications.  For those of you missing the old Ctrl-A functionality for aligning objects in LabVIEW 8.0, don't worry.  It's still there, you just have to press Ctrl-Shift-A now.
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Yeah, I know,
    sometimes there are those nasty Q&D bits of code which simply have to get done on the spot where I have to stand up and introduce myself as a space-aholic.  That, and the fact that I only have a 19" monitor (1024*1280) makes it really easy to run out of space going from left to right......
    I do a lot of document processing, and I really need the portrait mode of my monitor.  This basically reduces me to the "good 'ol" days of 15" monitor screen real-estate.
    So that's my excuse, and I'm sticking to it.
    As for scripting, I have zero experience with it.
    And as for the LV style guide, yes I've read it, but I think I need a robotic arm to pick up a printed copy and slap me in the face with it every hour or so to prevent me from indulging in extravagant diagram expansion.
    I think I read once that agoraphobia was the fear of open spaces, would this make me a virtual agoramaniac?
    Shane.
    Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

  • Darren's Weekly Nugget 05/15/2006

    Check out the following VI that ships with LabVIEW 8.0 and later:
    [LabVIEW]\vi.lib\utility\MD5Checksum.llb\MD5Checksum file.vi
    This LLB is available for download on the Developer Zone, but I decided to include it in the shipping VIs in LabVIEW 8.0.  It's a great, 100% G-based implementation of the MD5 algorithm for generating checksums.  I've used this VI for a couple of purposes.  One was to do checksum matching on the files generated by an installer versus the depot files used to create the installer.  Another time I used this VI was in a project where I had a pretty complicated parser that was analyzing text files from disk.  When I stored the parsed information from the file, I also stored the file checksum.  The next time I needed to load the files, I compared the stored checksum against the checksum of the current revision of the file on disk.  If they were the same, I used the stored parsed information instead of having to go through the time-consuming process of parsing the file again. 
    To learn more about the MD5 algorithm, check out http://en.wikipedia.org/wiki/Md5 .
    -D
    P.S. - To give credit where credit is due, one of my colleagues on the LabVIEW team, Steven Harrison, was the original author of this VI.
    P.P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    You can look at the code, and there is nothing that is sensitive to any part of the filename or filetype.
    For me, it works for any filetype. How are you using it?
    LabVIEW Champion . Do more with less code and in less time .

  • Darren's Weekly Nugget 08/21/2006

    Here's another feature I added to LabVIEW 8.20.  Check out the six new VIs in the File I/O > Advanced File Functions subpalette.  Some of them were already shipping with LabVIEW, but I added them to the palettes in 8.20 in hopes that people will find them and use them.  Here's what they do:
    Check if File or Folder Exists.vi - Given a path to a file or folder, returns a true/false value as to whether or not that file/folder exists on disk.
    Recursive File List.vi - Given a path to a folder or LLB, will return all the contents of that folder/LLB...in the case of folders, it will recurse all subfolders to return their contents as well.
    Compare Two Paths.vi - Given two paths, will return a true/false value as to whether path B is relative to path A, and will also give the relative path between the two.
    Get File Extension.vi - Given a path, will return the file extension of that path, along with the part of the file name that preceeds the extension.
    MD5Checksum File.vi - Returns the MD5 checksum of a file.  I've talked about this VI in a previous nugget, but it's officially on the palettes now in LabVIEW 8.20.
    Generate Temporary File Path.vi - Generates a unique path that you can then use with other File I/O VIs and functions to create a file in the temporary folder on your system.
    I hope LabVIEW developers find these useful.  Make sure to submit suggestions to LabVIEW R&D if you find yourself writing VIs to do common functions that you think should be on the palettes for all to use.  That was my primary motivation for putting these VIs on the palettes in the first place.
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Damien's single-element queues are not really being used as queues, but as a data store.  The benchmarking he did was comparing the single element queues against other data storage/retrieval mechanisms.  That's a different use case than recursion, where you would be using the queues to actually store multiple items (the files/folders you're recursing).  If you want to benchmark my VI vs. yours in terms of performance on recursing folders, go for it...like I said, it was a while ago, but when I did it, the shift register/build array method was faster.  As I mentioned in my previous reply, my VI ships with LabVIEW 7.0, so you can try it.  Note that you have to run File I/O benchmark VIs more than once, since the first run will often take an indeterminately longer amount of time, as Windows implements caching to speed up subsequent File I/O operations.
    -D
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • Darren's Weekly Nugget 08/02/2010

    Just in time for NI Week, LabVIEW 2010 has released!  Over the next several weeks, my weekly nuggets will highlight some of my favorite features in LabVIEW 2010.
    Cool LabVIEW 2010 Features Part I:  Replace and Insert with Quick Drop
    Soon after I released Quick Drop with LabVIEW 8.6, one of the first requests was the ability to do Replace and Insert operations with Quick Drop instead of the palettes.  Well, it took a few releases, but we finally got it:
    Replace with Quick Drop
    Select one or more diagram objects, press Ctrl-Space to bring up Quick Drop, type a palette object name (or a project item if you have one or more LabVIEW projects open), press Ctrl-P, and all the objects you had selected on the diagram will be replaced with the object name you specified in Quick Drop.  And yes, it does do the replace "correctly" with Compound Arithmetic...
    Insert with Quick Drop
    Select one or more diagram wires, press Ctrl-Space to bring up Quick Drop, type a palette object name (or a project item if you have one or more LabVIEW projects open), press Ctrl-I, and a separate instance of the object you specified in Quick Drop will be inserted on each wire.  I also included special functionality when Ctrl-Shift-I is pressed.  I call this "Smart Insert".  With Smart Insert, a *single instance* of the object name you specify will be inserted on multiple wires.  As an example, if you select a refnum wire and an error wire, press Ctrl-Space, type "Property Node", and press Ctrl-Shift-I, a *single* property node will be inserted on both the error wire and the refnum wire.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    I would argue that the expected behavior for Ctrl-Space....Select....Ctrl-P for the 1/x function replaced by a Compound Arithmetic should be:
    =====> 
    not what it currently is:
    ====> 
    This, BTW, is what the "Replace" menu does, so there is no benefit really in using the Ctrl-HyperSpace projection (at least to me).
    And similarly for (-x) and x^2.

  • Darren's Weekly Nugget 01/16/2007

    Hi all,
    Did you realize that exactly one year ago today, I posted my first weekly nugget?  Well, I've decided one year is a good stopping point...this is going to be my last weekly nugget.  It's been a lot of fun helping you guys out with little tips and tricks I've come across in my 8 years of LabVIEW development (this week I also celebrate my 8th anniversary at NI).  For my final nugget, I just have some simple advice.  One of the coolest things about LabVIEW is the ease with which we can come up with solutions to problems.  On the other hand, there are very complicated approaches to problems that are often warranted, depending on the complexity of the desired application.  I really admire my LabVIEW colleagues who are able to come up with extremely creative, extremely complicated ways to solve problems that I never could have thought of.  However, I think we should always devote a little time in the beginning to trying to discover the *simplest* solution to a problem.  You may come up with some corner cases that your simple solution doesn't cover, but don't forget to weigh the added time and effort you have to put in to address the corner cases, and also don't forget the added risk of new bugs you'll get when implementing the complicated solution.  It may sound kinda silly to mention this as a nugget, but I have definitely seen my share of apps that took a *way* too complicated approach to solve a fairly simple problem, when the most cost-effective, robust solution would have been quite a bit simpler.  Anyway, it's general advice, and some may not agree, but it's served me well so far in my LabVIEW career. 
    So that's all folks.  But don't worry, I'll still be around...
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    We Want Nuggets!! We Want Nuggets!!
    Join the movement...
    Message Edited by altenbach on 01-16-2007 02:08 PM
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    arnoldsays.jpg ‏18 KB
    churchsign1.jpg ‏16 KB

  • Darren's Weekly Nugget 11/08/2010

    Cool LabVIEW 2010 Features Part XI: Export Data to Clipboard (or Excel or DIAdem)
    I thought I was done with my "Cool LabVIEW 2010 features" series a few weeks ago, but then I stumbled across this one today:
    These new Export Data options are available on Waveform Charts, Waveform Graphs, Tables, and Arrays (including constants!).  Choosing the Export Data To Excel or Export Data To DIAdem options will launch those apps with a new document containing the data.  Choosing Export Data To Clipboard will simply copy the data to the clipboard, at which point you can perform a Paste operation in whatever app you wish (Excel, DIAdem, Notepad, Word, LabVIEW, etc.).  Here are a few things I discovered when exploring this new feature:
    On Windows, the columns are tab (\t) delimited, and the rows are line feed (\n) delimited.  I didn't check other platforms.
    When using this feature with the Table control, it works best if you deselect Advanced > Show Selection on the table before exporting.  Otherwise, you have to select (i.e. highlight) the data you want to export in the table.  It seems to me that most of the time I'd want to export the entire contents of my table.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    mysticfree wrote:
    "Export Image" property?  DO'H!  Of course.  In all my searching, I don't know how did I miss that one ....  boy, is my face red.  
    Happens to the best of us!
    Promise.
    Paul <--Always Learning!!!
    sense and simplicity.
    Browse my sample VIs?

  • Darren's Weekly Nugget 06/15/2009

    One of my favorite features of LabVIEW 8.6 is Linked Tunnels.  I can't believe I haven't written a nugget about these yet!  In case you haven't heard, wiring tunnels in multi-frame structures is a lot easier in LabVIEW 8.6:
    See those tiny white triangles on outer edges of the string tunnels?  Those indicate the input/output tunnels are "linked".  There are two equally awesome use cases for linked tunnels:
    You are adding a new pass-through wire on an existing case or event
    structure that already has a bunch of frames.  When you pass the wire
    through one of the diagrams, if you right-click the output tunnel you just created and choose Linked Input Tunnel > Create & Wire Unwired Cases
    to link the input and output tunnels that bookend that wire, it will
    automatically wire up those tunnels in every other frame of the
    structure.
    You are adding a new frame to an existing case or event structure that already has linked tunnels.  When you add the new frame, all linked tunnels will already be wired together on the new diagram.
    I like this feature so much, I tried to figure out a way to show it off in my NI Week 2008 keynote demo.  But since Tim only gave me 10 seconds to write my VI, I wasn't quite able to squeeze it in. 
    Message Edited by Darren on 06-15-2009 04:54 PM
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Fantastic!
    This is a great feature that I was not aware of.  Thanks Darren. 
    Using this feature when creating State Machines or Event Structures will be very useful and highly appreciated.
    You should definitely show this during NI Week.  This is a feature that has been long awaited....  (by me)
    RayR

  • Darren's Weekly Nugget 02/09/2009

    Shortly after NI Week 2008, I found out that NI employees could take the NI Certification exams.  Previously this was not allowed.  Once I found out, I took the CLAD, the CLD, then the CLA.  Don't worry, I passed them all. 
    Over the past few weeks, I've posted information on my LabVIEW blog detailing how I prepared for each exam.  I recommend checking out my articles before you plan on taking any of the LabVIEW Certification exams:
    Preparing for the CLAD
    Preparing for the CLD
    Preparing for the CLA
    -D
    P.S. - Check out past nuggets here. 
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    NIquist wrote:
    Just out of curiosity, why would NI not want their employees to be certified in the very products they sell and support???
    I'm not certain about this, but I *think* it was simply a manpower issue. Up until recently, they didn't have enough staff to grade exams submitted by both customers and NI employees.
    -D
    P.S. - I'm glad you like the blog!  I have tons of ideas for articles, it's just a matter of finding time to post them.  The certification exam prep articles were highly-anticipated though, so I knocked those out first. 
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • Darren's Weekly Nugget 05/04/2009

    One of the nifty features of LabVIEW 8.6 was the ability to edit the properties of multiple objects at the same time.  Most of the literature on this feature focuses on editing front panel objects, but did you know you can edit the properties of block diagram objects as well? 
    For most diagram objects, the property list is pretty limited (or nonexistent). For the functions above, the only properties you can change are the adapt to source option on the Output Configuration of the functions, and whether or not the functions' labels are visible.  There are other objects (particularly constants) with more useful configuration options.  For example, you can change the items in multiple enum and ring constants at the same time.  For string constants, you can change several formatting options.
    How has the ability to edit properties of multiple objects (either FP or BD) been particularly useful to you LabVIEW 8.6 users out there?  And what properties would you like to see be editable on multiple objects that aren't there yet?
    Message Edited by Darren on 05-04-2009 04:06 PM
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    diagram_select.png ‏2 KB

    Thoric wrote:
    I created a mock-up of my application's panel (one of them, anyway) that has 48 identical controls within a large tab of an otherwise empty vi. It uses the same type-def for the controls. I tried using multi-property, and it worked with lightening speed! So, on the second tab pane, I created another 48 controls, from a second type-def. I tried multi-property for this new set of 48, and it worked, but slower. I re-selected the first 48 controls, and although it worked again, it was slower still.
    So I created a third tab pane (my application has six panes by the way), and another 48 controls. Now it's starting to grind to a halt. Multi-select takes a long time to populate the Properties window, and a good long time to affect any changes too. A disproportionately long time. In fact, as I look at it now, LabVIEW has frozen
    I do get trouble with my LabVIEW installation, with things like Quick Drop crashing occasionally, so maybe this slow behaviour won't be seen by others?
    (Actually, while I've been writing this and playing with the multi-property tool, LabVIEW has frozen on me three times. I wonder if something more serious is amiss...)
    Thoric,
    I tried multi-select properties on 48 controls on the UI you gave, and I didn't see any of the slowness you've described (running a 2.4GHz(x4) quad core with 4 GB RAM here).  The first launch of the properties page took a few seconds, but each launch after that was very quick.  And applying the changes only took a few seconds.  I also tried the same operation in the LabVIEW 2009 beta and saw pretty much the same speed.
    Also, I've never seen Quick Drop crash.  Do you have problems with other applications on your computer besides LabVIEW?
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • Darren's Weekly Nugget 06/22/2009

    Today's nugget deals with gracefully closing a LabVIEW built EXE window.  Most everybody knows the trick of using the Quit LabVIEW function at the end of a built EXE to close its window.  In fact, you may have even included some extra logic, like with a Conditional Disable Structure or the App.Kind property, to make sure Quit LabVIEW doesn't run while you're developing and debugging your VI in the LabVIEW editor:
    Have you ever noticed, though, that sometimes when you quit a LabVIEW built EXE, you see a brief flicker of the toolbar?   This can happen if you have your VI set to have a dialog window appearance (so that there is no toolbar), and you run the Quit LabVIEW function after clicking the "Stop" or "Exit" button that you created on your VI's front panel.  In this case, the built EXE, upon going idle, will show a toolbar (with the Run button) for an instant before the panel closes.
    To avoid this toolbar flicker, you can make one simple change to the code above:
    By calling FP.Close, you are telling LabVIEW to hide the front panel of the VI/EXE first before exiting.  This way the extra cleanup that LabVIEW must do can occur without the front panel of the built EXE showing, and we never see the toolbar flicker.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Sebster:  Yes, it will work, but you should clear the error before you execute the code. Furthermore you will need to get the reference to the calling VI (or the top level VI).
    Darren: Thaks a lot for the hint, the FP.Close was really new to me. Maybe you adress the other side (splash screen while loading) in a further nugget.
    Felix
    www.aescusoft.de
    My latest community nugget on producer/consumer design
    My current blog: A journey through uml

Maybe you are looking for