Jim Kring

Option 1 can be defeated by providing a VI with the same name and connector pane. Option 2 is possible, but requires a bit of thought+work and incurs performance penalties.

The only thing that I can think of, would be to make all of the VIs that are saved outside of the EXE part of a password protected project library (.lvlib) or class (.lvclass) and make sure that all of the .lvlib and .lvclass files get saved inside the EXE. I think that this might prevent the VIs from being called without the .lvlib or .lvclass files, which cannot be extracted from the EXE... but this is just a guess.

As Stephen mentioned, the diagrams are removed (by default), but I believe that the VIs (that are saved outside of the EXE) can be used as subVIs of other LabVIEW applications (within the same version of LabVIEW ) . This means that it is possible for the end customer of your application, to re-use the VIs in other applications and even build them into other EXEs.

Adding a new control to a front panel is considered to be editing a VI and is not possible while the VI is running. The "New VI Object" function can add controls to the front panel, but only on VIs that are in edit mode.

Take a look at this document. Specifically the 'Adding User Libraries and Instrument Drivers to the palettes" section.

Don't forget that you'll need to show NI a business case (how it will help NI generate revenue) The key to scripting in LabVIEW 8.x can be deduced from the following statement: Scripting features are exposed in LabVIEW <= 7.1, and scripting features allow you to write LabVIEW code, and scripting features are LabVIEW code, and LabVIEW code that calls scripting features will run in later versions of LabVIEW.

Housing prices in the bay area are falling. I'm hoping that the market will bottom out in one or two years. If it does, It should be a good time for first-time home buyers to get into the market. :thumbup:

We're not trying scare anyone (or rule the LabVIEW world). It's my life ambition to change the LabVIEW world (one VI at time). If you're scared by what you see, now, then hold onto your seat -- there's a lot more exciting stuff coming

Stephen: Thanks for the info. I'll update the code and try running the test cases.

Here is a tool that should work (I just whipped it up). It depends on the OpenG oglib_lvdata library. After some testing and clean-up, I'll add it to the oglib_lvdata library. Cheers, -Jim Download File:post-17-1165273923.zip

My guess (I haven't tested anything, yet) is that the type descriptor of an lvclass only references it by name and you will need to open a VI server reference to the .lvclass, in order to get all the nitty gritty info.

Yes, Stephen knows, I'm sure It probably wouldn't take a whole lot of reverse engineering thoughtful inspection to figure it out.

Don't worry about me. I get to see Michael, in person, many times each week and he tells he how awesome I am, all the time Cheers,

You are correct. The OpenG variant tools do not yet handle LVClass.

Yes, you are right about \00 through \1F, Actually, the code I wrote already did \00 through \1F, but somehow the VI documentation and my posting/question stated \00 through \0F. But, my code also redundantly included \r (\0D) and \n (\0A). I've fixed that, now.

Since we're diving into the nitty-gritty corner-cases of the LabVIEW path data type... I just learned that the Build Path primative allows appending an absolute path, when the base path input is an empty path. This isn't stated in the context help, but the detailed (on-line) help states: "If base path is an empty path and name or relative path is an absolute path, this function sets appended path to the absolute path in name or relative path."

I have a design question regarding the encoding of special characters in INI file section and key names (for example, if you have an EOL or other special character in your section/key name). This relates to an improvement being made to the OpenG Variant Configuration File IO VIs that allow variant data to be written to and read from INI files. I have posted the design question, here. Your feedback and participation in this process is appreciated, since many people rely on these VIs. Thank you,

And sometimes an installer is an exe.

Thank you, Chris, for your totally awesome contributions to LAVA. Our community is much better off having you as one of its key members. I'm sure I speak for everyone in saying... we LAVA you

No problem. Here are the files, saved in 6.1. Download File:post-17-1165100870.zip

Chris (Davis), This is a tricky problem. One thing that should be noted is that Excel escapes quotes by repeating the quote twice (e.g., " becomes "" in the CSV file). For example, I think that Excel would save your example as the following: "Chris","Davis, Jr.","asdfpoiu2134098",12/01/2006,01:15:06 PM,12.00,13.00,24.00"asdfwer234098lkj","weoirtuwe234098",1,1,0,0,"This is a test""weoriu324098lj","This question has a, comma in it",1,1,0,0,"More text here""wqeroi2340981","This question has been cut off, with a ""quoted piece of text",0,0,1,1,"in it""23498osfuoiwuer","This question has a ""QUOTE"", and a comma in it",0,0,1,1,"Kinda Rough" I have created a VI (attached) that seems to handle Excel CSV files correctly. (However, it might not work on your original example strings, since it expects quotes to be escaped.) This is something that I was thinking of adding to the OpenG code, someday, so I have BSD'ed the VI. If you want to help polish it up, so that we can add it to the OpenG string library, that would be great Download File:post-17-1165043092.zip

An empty path is the root folder (e.g., "/" on Linux). If you list the contents of the root folder (i.e., an empty path) on Windows and Mac, it will return the list of drives on the computer. So, technically, an empty path is a folder (directory) that exists. The OpenG VI (File Exists) works in exactly the same manor as the NI VI. However, the OpenG VI "Valid Path" does not return a TRUE, when an empty path is wired in. This is the VI that you should probably be using, first and foremost (instead of "Check if File or Folder Exists.vi") for checking if a path is valid. That said, I can see your point about how confusing this is. Most LabVIEW developers are not aware of the fact that an empty path is the root folder/directory, by definition.

OK, I'll fess up -- it was me, Omar wow'ed with this trick. I guess I'm starting to fall into the "old dog" learning (not so) new tricks, category. Thanks, Omar! -Jim

Hey Kurt, Great example! I have some thoughts... In LVOOP, the class data (the GOOP class reference, in this case) is private, which means that a child (DataSource.Sine, for example) cannot read/write the parent's (DataSource) data. In your example, both the parent class (DataSource) and child class (DataSource.Sine) have LVOOP object data, which is their own GOOP object reference. This means that the LVOOP object data of a DataSource.Sine object has both a DataSource.Sine GOOP reference and a DataSource GOOP reference. However, all members of the DataSource.Sine (child) class use the DataSource.Sine reference and all members of the DataSource (parent) class use the DataSource reference. This means that the parent and child classes are not using the same GOOP object reference! For example, DataSource.Sine.Create.vi initializes the DataSource.Sine GOOP reference. If this is passed to any parent class member, such as DataSource.Read.vi, then an error will occur, since the DataSource GOOP reference is null (recall that DataSource.Sine.Create.vi initialized only the DataSource.Sine GOOP reference and not the DataSource GOOP reference). The solution that I have found, is for the base class to define a GOOP reference in its LVOOP object data, and for child classes to use the base class object reference. However, since the LVOOP object data of the base class is private, and not directly accessible by child classes, the base class must define protected (not private) methods called GetGoopReference and SetGoopReference, which the child classes can use to access the GOOP object reference. The child class constructors must use SetGoopReference to set the GOOP reference in the LVOOP data, when the object is first created, and the other child class methods must use GetGoopReference to get the GOOP reference in the LVOOP data, so that they can access the GOOP data. I have modified your plugin example, to show what I mean You can download this example, here: http://jimkring.com/LVOOP_Plugin_JK01.zip My mod's are not very clean or complete -- it was a quick hack. Take a look at DataSource.Demo.vi to see what I've done. Here are some of the changes: modified the DataSource.Sine LVOOP data, deleting the DataSource.Sine GOOP reference. added DataSource.GetRef.vi and DataSource.SetRef.vi protected methods for allowing DataSource.Sine methods to access the GOOP reference modified DataSource.Sine.Create.vi to call DataSource.SetRef.vi, to allow it to set the GOOP reference in the parent class LVOOP data. added DataSource.Test.vi to set a data element in the parent's data modified DataSource.Read.vi to call DataSource.GetRef.vi in order to get the GOOP reference

Hi Chris. Welcome to LAVA. Your story reminds me of a similar choice I had to make, back in college. We had to do a engineering lab project using HPVEE. I had a very difficult time getting anything done in HPVEE (I gave it a fair try), so I petitioned to use LabVIEW instead (since I had used LabVIEW a little already, at that point). My request was granted, thankfully. And, interestingly, that college course now uses LabVIEW. We're looking forward to your participation in LAVA. Cheers,