hooovahh

You will not be able to create a VIM that operates the same way my XNode does.  This is because the technique I used was to use the Array to Cluster function, and setting the number of elements using scripting.  However using the OpenG method you can do this another way.  It is likely less efficient and takes longer but if you want a VIM that does it this should do the trick.

Array Of Variants to Cluster.vim

There is some kind of short timeout for posting.  I can't remember the reasoning, and I don't have control over adjusting it but I too see it.  Basically if you are on a LAVAG page for a couple minutes, and then try to post something it won't work and you'll have to do as you described, copying and refreshing.  At least clicking submit doesn't clear out the text you wrote.  That would really suck.

In the LabVIEW community a phrase that has been used to describe undocumented, or incomplete features of LabVIEW has at times been called Rusty Nails.  In searching LAVA it appear this is never explained and so this post is intended to give a brief history with as many details as I know having not been active when this all took place.

The earliest reference to "Rusty Nails" found online (thanks to AQ) is by Greg McKaskle of NI in 1999.  Someone was asking about all the undocumented INI settings that could be found, and how some weren't exposed to the Tools >> Options dialog.  Greg's reply was this:

Quote

As mentioned, most of these configuration options are available from within the Preference dialog. There are also configuration options that aren't in that list because they are needed so early in LV's launch that the resources aren't open yet; so this isn't the complete list. The options that aren't in the preferences dialog are generally considered to be not useful or even harmful. They are sometimes there to allow us a backdoor or a workaround for when we change a behavior. They are also used to turn on obscure development features that we, the LV developers, use to make or debug LV. These obscure features are typically kind of like the attic or basement of a house, not finished out, not very interesting, and potentially harmful.

We have never tried to hide any of these strings, and I don't believe you will gain any benefit from trying out various combinations of the settings. If you ask technical support what a setting is, they will likely tell you that they have no idea. They are telling you the truth. I don't even know what some of them do without checking the code. Others, such as exoticcontrols, no longer do anything. It was once used to show a control palette submenu that contained controls that were still in work and not ready for prime-time. They were experiments, unsupported features, and guaranteed to crash if you did much with them. Just the sort of thing that we need for development, but not useful to even advanced LV users unless they have a death-wish.

If you experiment with the .ini file and you crash mysteriously losing hours of work, I'd suggest putting the file back to the way LV left it. Don't ask tech support to fix it or complain that the LV attic has rusty nails and splinters.

As for whether or not Resedit is wonderful, I personally prefer Resorcerer, but that is a different story. It is a low level tool that in the right hands is useful, in the wrong hands, well, its in the wrong hands. For the person that likes taking a multimeter and a soldering iron to computers and household appliances, its exactly what you always wanted. If you start monkeying with things in the resources or the .ini file, use common sense and do it on a copy or you will just end up reinstalling LV.

Once the fun and experimentation is over with, I think you will agree that the useful options, with very few exceptions are in the Preference dialog.

Back in the LabVIEW 5.x and 6.x era there was a new emerging technology that was LabVIEW Scripting.  NI had created scripting for their own purposes but the community saw it and wanted to be able to automate editing, or creating LabVIEW code.  With the help from Jim Kring and others, the basic tools for enabling scripting in LabVIEW were available.  The story of how this came about is worth a post of its own, but the summary is that NI shipped a VI that didn't have a password on the block diagram, which allowed for the creation of any object, given an ID.  Using a for loop, you could easily create every object in LabVIEW, including objects which facilitate in creating and manipulating code. Discussing scripting often leads into discussing other INI keys which enable private functions like the well known SuperSecretPrivateSpecialStuff.  It is possible this is one of the keys Greg was referring to.  Other INI keys from 5.x can be found here.

After these discoveries the NI forums started getting users asking about scripting, and private functions.  Users were looking for help, and documentation but NI wasn't ready for this knowledge to be public and so they started deleting all posts related to private, and scripting functionality.  Some of the motivation for the creation of LAVAG came about by a desire to have an independent place to discuss the LabVIEW topics that NI didn't want to have on the public forums, potentially adding to the number of support calls, and confusing new users with advanced topics that were undocumented or incomplete.

After LAVA's creation a subforum section was labeled Rusty Nails, and intended to be a place to discuss Scripting, ExternalNodes, XNodes, Private methods, and general LabVIEW hackery.  Over the years several private functions have been made public, and scripting has become an official feature shipping with LabVIEW.  Because of this the Rusty Nails and XNodes subforums were combined into what is now the VI Scripting section.  Even over on the official NI forums, discussions about private functionality and XNodes has been relaxed since those early days.  Asking for private methods and getting unofficial help is something users, and sometimes NI employees will participate in, without the heavy censorship seen earlier.  And topics of scripting are encouraged now that the feature has been official since LabVIEW 8.6.

If you have anything you'd like me to add regarding scripting's history feel free to reply and I can add it.  And if I got any of the details wrong let me know.  Again I wasn't around when this all took place and I've just tried putting down the details I've heard from other developers.

There are private events on the tree for Item Close? and Item Open? which is a filtering event and allows you to discard the open and close.  You need the super special private special stuff INI to access these.  Then I'd recommend turning that INI off after.

On 10/8/2018 at 6:03 AM, ShaunR said:

The conclusion I came to with my investigation was that a separate repository (in "Program Data") of installed toolkits, under each LabVIEW and toolkit version, enabled very quick and easy uninstall and version change by simply creating and deleting symlinks in the vi.lib directory pointing to them. Once that is achieved, then project based installs become a simple matter of choosing which links are present for each project whilst still maintaining menus in the palettes.

Oh I like this.  Have a single place where all packages, and versions of packages get installed (extracted), and then switch in the package and version "Installed" by setting up the symlinks.  I could see arguments that these links should link to under vi.lib, or user.lib or wherever, or I could see arguments for them being in folders relative to the project.  I think having to uninstall and reinstall packages (delete and recreate links) between projects isn't too big of a deal and would reduce the likelihood of cross linking issues where one developer opens it and if finds the reuse library in a different place than expected from another developer.

You didn't specify the operating system on your PXI but I assume it is RT, it can be Windows as well at which point developing on the system should be pretty easy.  If you're already familiar with RT on cRIO and cDAQ, then PXI should be no problem.  You configure the devices in MAX just like any other remote device, and can setup virtual channels or other basic things there.  Then in the project you add your target, write your VIs and run them there which get deployed.  There really isn't any other considerations between a cRIO and PXI.  If anything I'd say the cRIO can be more complicated due to the FPGA in the mix.  Afterwards you create a build of your application and deploy it.

EDIT:  Oh and if you really want to test deploying to RT devices you can load up a virtual machine and deploy to it as if it were a PXI with no hardware.

I think it would be hard to install DAQmx without MAX.  It is likely in your start menu as "NI MAX" if it isn't then that is probably needed to setup DAQ Assistant.  If it is missing, install MAX and you may need to reinstall DAQmx.  When DAQmx installs it looks at what things you have on your system and installs DAQmx support for those things.  If a thing is missing when DAQmx gets installed, it won't install support for it and you'll need to reinstall.  For instance if you have LabVIEW 2017 installed, and you then install DAQmx it only installs support for LabVIEW 2017.  If later you then install LabVIEW 2016 you won't have DAQmx support, until you run the installer again and it adds support for 2016.  During the second install it should see that 2017 support is already there and do nothing.

You probably already saw a discussion on Code Sharing, which has no conclusion yet.  My opinion is if it is stable and good and you don't expect much changes, submit it to the Code Repository here (package preferred).  If this is still in a state of flux and development, a site better equipped with change management like BitBucket or GitHub would probably be better.  That being said this is a fine place to start discussions and suggestions, and can be moved to Code In Development at your request.

Well G Package Manager appears to be more project oriented.  So install OpenG Array 1.0.0 for this project, but then be able to install OpenG Array 2.0.0 for a different project, or not have OpenG Array available at all in another project.  Lots of duplication but moving closer to sandboxing projects.  Because of this I'm unsure how palettes would be effected by VIs installed for a project and not the IDE.  But yes it does seem to be command line heavy, and not intended for installing VIPM or NIPM packages.

Having NIPM install VIPM packages seemed like great starting point...but that likely isn't going to happen.  NI really should have just bought JKI's IP, and turned it into NIPM, building off of what has worked well in current LabVIEW.  Oh and another thing to muddy up the waters, there is already a 3rd package manager aimed at LabVIEW, G Package Manager.  Haven't used it yet but it was presented on at the CLA Summit in a session I didn't get to see.  I wouldn't be surprised if all of these use a zip or some compression as their file format.

EDIT: NIPKG can be opened in 7-zip and is listed as a "Ar" Type, looking similar to a Debian package with gzipped tar balls.

Continuation of package building with OpenG and DEAB tools moved to here.

Have you reinstalled DAQmx since getting this error?  If not you should.  Also what version of LabVIEW, MAX, and DAQmx are you using?

I do love and use the Pre and Post Build/Install/Uninstall VI features.  I know it would be best to have some features be native, but having the ability to hijack the build process to make it do custom things really adds so much flexibility.

Contributions to the community are always appreciated thank you.  That being said you might want to look into the other alternatives that have seemingly similar feature sets to yours.  I've been using LVMark for several years.  It isn't HTML but a type of markdown format.  Years ago there was another attempt called Formatter which does look like HTML.

@David_L I get your point.  If someone wants to migrate this all to the Wiki that's fine.  I've been keeping the pruning to a minimum, so anyone updating a wiki can incorporate the suggestions from this thread.

Despite being on LAVA all the time, my power is quite limited and I believe something like hosting a Wiki here would take more than administrator controls and would need site controls, meaning only Michael would be capable of this.  I don't mind hijacking this thread, as I intend on periodically pruning it (as I've done a little so far) and after some time and discussions die down I'll delete the user posts.  Obviously this would be counter productive to the discussion taking place and I did think about locking this thread from the start but this is fine.  Keep it coming just know that your post maybe deleted after a conclusion has been made on a subject, or your content has been added to the main post.

46 minutes ago, David_L said:

I second the Wiki approach.  This allows everyone to easily contribute, without any one person having ownership of having to keep everything updated.  

To be fair I'm not the only owner of this, any moderator or admin on LAVA can update this as well.  But I get your point.

Wow lots of good discussion.

23 minutes ago, ShaunR said:

I really thought the NI Package Manager (which I always said they should have done instead of using the JKI one) would address all this. They could even have had native SCC integration. But from what I have seen it is a poor replacement for VIPM targeted at NI products rather than addons.

Totally agree.  I intend on presenting on reuse and package strategies, and in researching and discussions with NI about NIPM I think they got the messaging wrong.  By even calling it NIPM, where many LabVIEW developers have only known one package manager their whole career, means we already think NIPM is to replace VIPM.  But looking at the design choices NI made it doesn't look great.  One major current limitation is that a package is made for a specific version of LabVIEW.  This means if I want to distribute a toolkit I need to make a NXG 1.0 package, NXG 2.0 package, NXG 2.1 package, NXG 3.0 package, etc.  This is because the installation path is to a specific folder which changes with each version.  Then there is the lack of pre and post VI calls.  There is an option for calling EXEs.  Needless to say I'm not thrilled about having two (at least) package managers to think about, manage, and deploy with.

As for code sharing, I really like LAVAs low barrier to entry, flexibility with license, and automatic discussion page creation.  I like Git, and Bitbucket's version control and collaboration features.  I like NI's larger overall traffic, with potential high exposure.  And I like the tools network for ease of access for the developer.  Maybe instead of us trying to come up with the answer to "How do we share code?" we should just have a list of options, and reasons you'd use each, then talk about how to use each option.

15 hours ago, Fab said:

I would like to add to the "I'm Looking to Find Example Code and Toolkits" section the NI Reference Designs Portal at http://ni.com/referencedesigns

It is a collection of reference designs that Christian Loew and his team keep updating. It started with only Systems Engineering reference designs, but now it includes several other. 

I'd argue this should probably go under contributing code, not finding code.  Either that or going under the Beyond Basics Training where more advanced topics are discussed.  I might be wrong but Reference Designs Portal isn't really a place I would see going to find a toolkit, or example on how to do some operation.  It seems more like a place to understand design patterns, and structure code.

I don't have admin controls, just moderator...

Dang so I can't even get this to work at the moment.  Using a physical keyboard CTRL+Shift+Up and Down does what I'd expect.  But the Keyboard Event code I have for some reason isn't doing what it should.  CTRL, and Shift seem to be working, or at least my on screen keyboard shoes them being activated when they should.  And the Up and Down appear to work as it goes up and down a line of text.  But when I put it in my application, it just doesn't do what I'd expect.  This is also with a whole bunch of waits added in case windows doesn't like fast key presses all the time.  I know I used this technique before but I can't seem to find the code that I used.

I couldn't make that work that way either...  It is possible something changed in LabVIEW since I used this trick.  It seems that setting the Index Value on the array makes focus go away.  And setting the KeyFocus any other time just sets the first element...darn.

But one method that does still work (and sucks even more) is you can navigate using various key combinations and you can simulate key presses to get the desired result.  So set KeyFocus to the string control.  This sets the focus on string control in the first index of the array.  Now if you press CTRL+Shift+Up Arrow, and your focus will be on the cluster element at index 0.  Now press Tab and it will be on the second cluster element.  Now press CTRL+Shift+Down Arrow and your focus will be on the second string control.  If you pressed tab twice it would be the third.  So you can programatically set the string control focus you want, but there is several complications with this method.  If you aren't looking at index 0 you need to do additional math to figure out what the index value should be, and how many times a tab is needed.  If I get some time today I'll try to post an example VI.  Mondays after a trip are always crazy

On 9/10/2018 at 0:20 AM, smithd said:

While I know 100 is just an example, its worth keeping in mind that 100 doubles is 6400 bits, 7 usec, or 0.00064% of your network bandwidth if updating every second.

Compound this with the fact that these doubles are actually being sent as ASCII strings, with some amount of precision and things get worst.  How about a table?  Or a 2D array of strings?  There could be lots of rows and columns and lots of data to send.

I agree that ideally the best approach is the compromise between the two extremes.  Don't send just 4, and don't send all, but instead send the 4 +/- some percentage of the total values (or maybe an upper limit of N).  The problem is this approach involving a skill I don't have alot of, which is web development.  As soon as it is in G I can handle it, but trying to send over say 20 of 100 values, then keeping track of the starting index, the scrollbars position, triggering to get more values, handing if the user scrolls too fast and needs to see blanks until the data refreshes, all is things I have difficulty with.  Basically what I'm getting at is you are right this is the best approach, but I'm not certain I'm ready for that type of challenge yet, I'll need to think about it, and hope I get like a week vacation to do it a few ways before refactoring half a dozen times first.

Also glad you got something on Windows 10, I haven't experimented with it much but I didn't think there was any additional issues last time I tested it.  Again maybe increases security causes issues?

EDIT:  Oh and Flavo you may want to get the latest release from here.  I don't know things are fixed, but your first image showed the first release with WebServices.

Sorry I don't really know the answer to this.  Chrome on desktop and mobile is primarily the browser I've been using.  I did notice that in IE there is sometimes a security warning that you need to enable something for it to work.  It is possible that there is some Edge security thing stopping it from working well.  

I have put some effort into adding arrays, and scrollbars to this.  Scrollbars I think I have working well enough, but when it comes to arrays there are multiple ways to do it and I couldn't decide which way met use cases better so it is on hold until I get some more time to try things out and think about it more.  For discussion here is the thought process.  If I have an array with 100 items in it, and I see 4 rows, and a scrollbar.  How should the data be sent back and forth?  Should I send all 100 values with every refresh?  Or only send the 4 items that the user can see?  The drawbacks to only sending the 4 values the user can see, is that when scrolling that scroll value needs to be sent, and then the new 4 values need to be sent back, and I feel like this would cause a laggy feeling.  Of course sending 100 values every refresh is also undesired.  Keeping track of the changed values would probably help