hooovahh

So in 2011 and 2012 with the super secret key turned on there is an "Invoke Built In Menu Item" for a VI. It states very clearly "NOT IMPLEMENTED" so I assume don't use this your computer will explode. But this feature would be nice. I was wondering if anyone had a method for invoking a menu item from a VI, and if anyone knew if/when this feature will be implemented? I noticed there is a similar invoke method for an application, but this makes me think it won't work for a VI specific menu item. So this is a bad example but I have a Help >> About Us menu item, how could I problematically call that as if the user pressed the menu item? There are many, work arounds I just thought this would be one of the cleanest for my setup.

Are you seeing this when in a build EXE or just in source? It took about 4 seconds in LabVIEW 2011 SP1 x86 within Windows 7 x64 to exit from source. I have many OpenG packages installed.

Please post some of your code if possible. Your claim is difficult to understand, unless there are other works at play.

Here's a post on Lava that mentions how to do it in Python (never tried it) http://lavag.org/topic/15304-calculating-dynamic-formulas-with-boolean-operations/ Also it links to an NI site where another method can be used. https://decibel.ni.com/content/docs/DOC-13186

It is unclear if you are talking about the database being password protected or something else. This is a LabVIEW forum and has little (if any) topspeed database experience. If this is regarding LabVIEW please re-phrase the question so it is clear you are talking about LabVIEW.

I had a similar complaint (without knowing the platform issues) so I have made a small VI that is called "Is Path Valid and Exists?" which uses the two OpenG VIs "File Exists" and "Valid Path". I never just use the "Valid Path" anymore. You could do something similar where it needs to be "Valid Path", and Not "Empty String/Path"

I've seen people add LabVIEW to their resume with less experience then that.

So if the file is read-only it can still be edited, (so a dirty dot) but you can't save it so any changes will not be kept, which in my mind is the real reason to set the file to read only. Sure I could edit a VI that is read-only, keep it in memory and then the changes will be implemented, but as soon as I close LabVIEW (and changes are discarded) the VI will revert back to the original file.

Or to prevent accidental changes to VIs in the vi.lib. Of course changing the file to be read-only maybe an easier alternative for this.

Well this is an interesting one. I've seen this event before and I just never had a need for it so I never used it. I assumed it worked the same way you wanted to use it. I couldn't open your snippet (I believe Lava may have removed the meta data on upload) but I made a quick VI that was blank, and a new VI that opened its reference and tried to do what you did. Sure enough I got the same error 1027. I tried tricking the method a few ways because I noticed if the VI was running I could register for the event but couldn't select any thing on the block diagram. So I tried running the VI registering and then stopping it but that didn't work. I also tried the "Fake Exec State" posted on Lava, and that didn't work either.

Oh sorry I misunderstood. In that case yes that would work decently well but probably not perfect. Even so any of these suggestions are better then what we have now, when a Main.vi is the startup VI and takes upwards of 20 seconds before the user even sees anything indicating the program is running.

I'm also going to side on Yair with the version issue. At times I've had up to 9 versions of LabVIEW installed on my machine at once. Unless you have a separate folder (or repository) for each version of LabVIEW there are going to be some issues for me using it. And if you do have a separate location for each version then, when there is some bug fix I now need to fix it in each location. Also I don't know how I feel about editing a users LabVIEW.ini. On the one hand it should be no different then adding tools menu items, or quick drop functions, but for some reason I feel like the LabVIEW.ini is a place for a user to customize LabVIEW the way they prefer it. What about the dreaded Auto Tool argument? Am I to force all developers to not use Auto Tool (or force them to use it)? Sure the majority of the settings we can all agree on (insert auto-feedback, terminals as icons, separate compiled code), I'm just thinking about the few that are user specific. I also like the fact that I can take one VIPC file which can contain all internal and external reuse code, and settings, and take it to a computer that is offline. There are many times where a PC will be in an environment where internet is not an option and bringing reuse tools and components (as well as SVN) are difficult. Now I just grab one VIPC which is a snapshot of the reuse used on a project. This is also great for configuration management because years down the road I can say exactly what VIs were used from the user.lib. I guess SVN could do that too with revision tracking so that's not as big of a deal. I'm glad it works for you but there are too many reasons for me to not use SVN for these types of changes.

Very neat. How do you distribute the quick drop shortcuts to your team? I've been using VIPM, I wasn't sure if there was anything else people use.

I like the concept but in practice you may find it difficult to update the UI while the main.vi is being loaded. I've noticed that when I do a Open VI Reference the UI is locked and doesn't update (something about thread swapping). So I don't know how you would update a progress bar with the new memory loaded percentage. The reason the the Sub-System loading works, is because there isn't one Open VI Reference call, there is one for each sub-system and then one for the main, and between each of these calls there is a time where the UI can be updated. If you can get an example working using this memory usage method I would be very interested in how it works.

Oh live a little on the wild side once in a while. Have you never visited a site with where the letter "s" is replaced with the letter "z" and you have more popups then Windows can handle. When you've gone that far into the internet and survived without a virus, that is the day you have won.

I have too, and I hope that means they will push for more refinement with the Arduino tool kit they made. Possibly charge some small amount for it so it can get some more support and development. I mean it works don't get me wrong, but I find minor bugs with it, and not officially supporting several Arduino boards. It doesn't look like support has stopped (last revision was last August adding IR Transmit VIs) I would just expect more interest for low cost hardware when combined with rapid prototyping in LabVIEW.

I recommend VMWare. It's quick and easy to delete a disk image and paste a backup with just Windows installed. The free version now allows making VMs even if it is called VMWare Player.

Mine are too, I was just trying to make it more generic. So that this loading splash screen with progress could be applied to applications where this dependency on sub-system architecture wasn't required. I guess I'm satisfied with it as long as new applications also adhere to this design pattern.

I'm not familiar with the BIN file format for images. It maybe a stream, which you can use with the Windows PictureBox. If this is the case you can create a .NET Control in LabVIEW to open it. If this isn't the case you may need to post an example BIN file so we can help understand what the file format is and how to view it.

Regarding 1abvi3w, I have seen this folder being generated temporarily when building an EXE, so I think this is probably correct and I can do some testing to see. I wasn't intending on loading all VIs one at a time then loading the top (from bottom to top) I thought that would be too time consuming. Really I think what would work best is maybe to load the 20 largest VIs (by file size I guess) then load the main VI. This way I don't have to load all 2000-5000 VIs, my goal would be to load just enough of them so that the progress bar can keep moving. Maybe the 20 largest VIs will load 70% of the total VIs (because they would load dependencies) and then loading the Main would use the 70% already loaded, and just load the extra 30% it needs. Just a thought I haven't fully tested any of this.

This is all in the name of understanding right? I don't have it working but I wanted to share what I had to see if someone else could figure any more out. So you can extract a newer LabVIEW EXE like Jim did and get the contents of it (I tested with 2011 EXE). However the contents may not be as useful as you'd like. There are alot of neat things like icon files, dialog information, version information etc. All of this isn't a big secret and can be viewed using Resource Hacker. You'll notice under the RCData there are a few sections and one of them should be much larger than the others. This the the main contents of your EXE and contains all the code needed to run (VIs, Controls, classes, and other files). In my two examples the large section was under "2" under the "RCDATA". Looking at this 2 file I found a few block sections. Near the end there is the RSRC section and it mentions the "FLAG" block and "LVzp" block. The Flag block for me contained one byte that was 00 for the two EXEs I tested. LVzp contained the large majority of the "2" file and I believe this is the secret to the file's information. The LVzp block started with the same for the 2 EXEs I tested which is the following: or in ASCII Now this is where I'm stuck. I'm guessing this pZk block is a compressed format of some kind but can't figure out what. Searching google for this header as a file returns nothing. I believe if we can decompress this we may have the file structure of the EXE listing out its contents. I also did find some EXE_Miner on NI's site but it again only works with older versions of LabVIEW before this compression was done.

DO'H. Well it's been a while since I read this whole thread so I missed that. Regarding how do I know my FP is ready to be shown? Well my Main.VI isn't the main UI you see when you run, it goes like this. Launcher - Main VI - - UI Actor - - DAQ Actor - - Logging Actor - - Other Actors My Launcher is as I described, a splash screen with a progress bar, cancel button, and opening actors one at a time then opening Main VI. Main VI has some init stuff to do (read config files) then it calls all Actors to start. Each Actor then has its own init operation (including UI Actor). So my Main VI sits in a loop telling the UI Actor to Show Window. It won't be able to do this until all init has been completed. If Main VI doesn't hear the reply from the UI Actor:Show Window within a short timeout, it will wait then call the Show Window again. When it finally does get the reply from the UI Actor, Main VI hides it self and UI Actor shows its self. In this way my Launcher is a splash screen loading the VI hierarchy, and Main is a splash screen (without progress bar and cancel) that has the same front panel as Launcher. This has a nice effect of a progress bar increasing then when it is full it disappears, and soon after the UI Actor is shown. There are several flaws with this but after initial debug it works well. My question back at you is how do you do you know where in the EXE your VIs are so you can open a reference to them in the Launcher? Through trial and error I noticed that the path to the file within the EXE was the same as it was on disk from the project file to the Actor Core. I wasn't sure if this was always true, and I wasn't sure where files that aren't relative to the project file are stored. In source I have this structure. C:ProjectsExample.lvproj C:ProjectsActor 1Actor Core.vi In the EXE it appears to be this <dir>My Example Program.exe <dir>My Example Program.exeActor 1Actor Core.vi What about files not relative to the project like vi.lib files? Where are they stored in the EXE and are they subject to change?

So I had an idea for a progress bar loading splash screen with a cancel option. It's an idea that others have done before but I modified slightly. There is a splash screen VI that is very small and then loads the main VI dynamically. But how mine differs is I am able to have a progress bar loading each of the Actors, before loading the Main VI. If you load the Main VI in the splash screen the UI will be locked until that Open Reference operation is complete because it needs to load the entire VI hierarchy. So instead I will open a reference to each Actor Core, which is the majority of the VIs each actor will use. During this a progress bar can be shown displaying which actor is being loaded and a cancel which would send a stop to the for loop loading each actor. If cancel isn't pressed then after opening each actor, we then open the Main VI which takes much less time to load because each actor is already loaded. This all works great but you may ask your self "How does the splash screen know what actors exist and need to be loaded without causing them to be loaded into memory already." The only solution I came up with, is in my Build Specification I call a VI before making the EXE. This VI will search my project for actor cores, and then write to the applications config INI file saying what the actor names are, and where in the EXE they can be found. Then the loading splash screen reads this INI file and uses its information for the UI. This all works and in practice loads quicker than just loading the Main VI dynamically, for some reason. I tried making an example of what I described using the Actor Frame work but couldn't make it work due to my very VERY limited Actor Frame work experience. I just used the term actor in this post so others would know what I was talking about. But in general this could work for any producer consumer engine architecture that is broken up into sub components. Heck this could work with anything with classes in it and just load each class before loading the Main. Or even more generic what if we got a list of all VIs greater than a certain file size (say 50KB) then load each of them before loading the main.

Very cool indeed. I wanted to make something, the best I could do is a face.

No need to make something new LabVIEW already has a peak detection. <LabVIEW>vi.libmeasuremamon.llbWaveform Peak Detection for 1 Chan.vi It's on the palette under Signal Processing >> Wfm Measure >> Waveform Monitoring