hooovahh

First is there any errors? Second what is the value of Data? This is important. Leaving it blank will mean do nothing, where filling it in might mean to read specific memory registers. You'll likely want to consult the manual, or even some other text based libraries to get an understanding of what registers need to be read, and how to scale the data that is read.

Tunnels was a big one for me. Was there something added to the functionality of static VI references? Maybe adding the right click for their type? Or maybe I'm thinking about features in the dynamically calling VIs allowing for run and collect being separate operations? Many QD and functions can be back saved (but not all successfully). Others I use but could live without but do use all the time is dragging into and out of structures, live drag, and remove and adding space with CTRL and Alt modifiers, oh and snapping add/remove space to 1D.

Looking at older IDEs is a bit discouraging when it comes to IDE performance. When I was beta testing NXG I made some comparisons in startup time, opening a simple project, opening a simple VI, and making a basic edit. NXG was something like a couple minutes slower than 2017 for the whole process. I imagine the responsiveness of 2017 to 8.5 is likely just as large a gap in 2017 to NXG. And I remember when first using 8.x versions how it seemed dog slow in comparison to 7.1. Maybe in a few years NXG 1.0 will seem fast.

You cannot target this board with LabVIEW and deploy G code to it. Only NI's FPGAs can be added as targets.

Okay deep breathes everyone. (myself included I took part in this too) I think we all understand where everyone sits. I think Shaun understands that starting in 2017 NI made a change that they deemed was a bug regarding buffer reusing that caused the functionality to differ from what they expected. This is seen as a good thing by some and a bad thing by others. After watching much of the linked video from Linus my option that was far in one direction, swings just a little by closer to what Shaun was suggesting, thank you for that. But I think an important point he made in that video was that the amount of effect a change has should make or break the change. At one point someone asked what version of GCC a distro should use moving forward. And he more or less said, well the people effected by this change now is some what small so "you are off the hook". The most core library in the system effects tons of people and so breaking APIs here needs to be done cautiously. The larger the impact the more likely you should just leave it alone. Do lots of developers use user events? Yup I think so. Do lots of them use it the way Shaun is showing here, well it is hard to say but I would say it is the minority of those that use user events in general. NI has broke other compatibility in the past. Primarily I think of the INI fiasco a few years ago, but at least in that case these were vi.lib functions not on the palette so they assume few would be effected. When possible I do see NI make an effort to preserve functionality. Think about when you are opening an older VI in a newer version, there are times that a small subVI might be inserted automatically to keep the same functionality. I saw this with some TDMS functions where a function wouldn't generate an error in older versions but would in newer, so NI would insert a clear error on that specific error if you opened older code in newer LabVIEW. Most of us work in pretty closed environments when it comes to our own APIs we can break compatibility and just tell the couple people (or update the couple of projects) that things may need a relink, or some tweaking to be fixed. As teams grow our concepts of difficulties given to those using our APIs needs to grow too. NI certainly has a larger user base on their APIs than I do, and then there is the fact that my APIs are free while you are paying NI to make updates that might break your code which can be discouraging.

This is a DVR analogy that represents why the event structure example doesn't work: This is more representative of what you are doing. Yes it worked previously, but it shouldn't have. If this VI worked in 2009, and doesn't in 2017 would you also claim it is a feature an not a bug? EDIT: Also that video sounds interesting so far but is quite long, is there part you find the most relevant. Double Edit: Seems I found it around 9 minutes in.

Right but that isn't what is happening in the event example. Yes you are providing a type, telling the event structure what type to expect, but this isn't happening on just the first iteration of the loop (like the DVR example). You are providing a type, and providing what the event structure expects is a valid refnum that points to to the specific events it should react to. And every iteration of this loop you are providing a null reference. The DVR example works because the new reference is used, the event structure doesn't because that new reference is replaced with a null at the start of the next loop. I agree that there is a type of feedback node internal to the event structure, being able to know what it registered for last time. But by providing a new event to the outside of the event structure, it believes you are telling it to now use that event instead of the last one you told it to.

This isn't the same issue as your event example above. In the DVR case you actually made a method for the next iteration to use the newly created reference. In the event case there is no shift register or feedback node. You register for something, but then the next iteration of the loop has the event structure getting that null refnum again.

So you weren't implying this is a bug that everyone relies on, by quoting someone saying: It appeared to break the rules of data flow. I'd consider that a bug worth fixing, and a feature that shouldn't be relied on.

I agree with the others. This should never have worked, and was clearly a bug that got fixed. In every iteration of the while loop you are passing in the reference to a refnum equal to 0. All design patterns I've seen from others have this as a shift register, usually uninitialized, which gets it's value set on the first chance it can. I tested this in 2015 SP1, and 2016 and both still increment. I only have 2017 SP1, so am not sure if this was a SP1 fix, or a 2017 fix. Still you suggesting that everyone relies on this (based on your quote of Linus) might be a bit exaggerated.

This one I can answer. So the picture data type is really a string. This is a string with instructions on how the image should be rendered. So imagine if the instruction is something like "Draw a rectangle that is 50 by 50 starting at 0,0 and is solid red", then the next instruction is "Draw a rectangle that is 50 by 50 starting at 0,0 and is solid blue". Both instructions will be embedded in the string, one gets drawn, then the other on top. Obviously in this example the red rectangle can't be seen, it will be under the blue one. But the instructions will still draw all the operations, even the ones that won't be seen. Now if this is in a shift register, then this string of instructions will keep getting longer as we concatenate more instructions to the end of the string over and over again. Here is a post over on the dark side talking about it a bit. And here is an awesome post by Norm talking about how the image instructions are stored, and how they can be manipulated (as strings) to perform image translations (repositioning in the X and Y) by changing these string values. As for suggestions. In the past what I often need is a picture control that is built of of several other images. They can be combined with concatenate string in the order you specify. So often times I will keep in memory the pieces of the over all image, so that I can quickly recreate the end image by swapping one out. For instance lets say I have a button, and I have an overlay for when the mouse is over it. I will draw the button, draw the overlay, and then keep them both in some private data. Then concatenate the two when the mouse is over the picture, or just show the button (that I've already drawn) when the mouse isn't. This is what I did in my Toolbar class. Here each button is also it's own image I keep track of, then combine them all to draw the whole result. I don't rerender the whole toolbar.

Yeah don't use them with Subpanels. Either go all out with the Windows API abandoning subpanels, or use subpanels exclusively. I threw a quick example of the Windows only route here showing a somewhat unlimited way of spawning windows. As for a subpanel only route I have the Image Grid, which is subpanels of subpanels.

Yeah if this is using a Windows API with Parent/Child relationships you will run into issues. When using a subpanel there is no HWnd for the inserted VI only for the VI that has the subpanel. More information is needed.

This doesn't belong in this thread, but that being said why do you need to run the VI every time? Why doesn't it configure and save the palette in a way that the settings are retained?

I never liked an actor design that didn't allow for an actor to run without the rest of the application. It just makes it so much easier to be able to develop and troubleshoot an actor when you can run that actor as non-reentrant and have it work without needing the rest of the frame work. I'm sorry that doesn't answer your situation, but in my actor design an actor can just be ran in parallel with the normal code, and it will publish it's data, and subscribe to user events (including quit). It won't have any application wide config information but I just have it default to something if the rest of the application can't be found. In this case actors written for the large application, can be copied to a new project and called like any normal subVI. Modularity and reusability.

Okay another amazing feat thanks to Thomas. I have a reentrant VI running on a Linux RT chassis. Which creates two web pages at run-time (without anything from the host as pre-compile data), one for each reentrant instance of a VI creating two web pages, both that can be interacted with independently. This is something NI's remote front panels cannot do, due to the reentrant VIs not having front panels in RT. But with the embedded UI enabled that doesn't fully seem to be the case. Still lots of work needed to clean this up, and I'm hoping performance doesn't take a big hit, otherwise I'll just revert to sending data about the reentrant states using some other network protocol. Oh and like most things this might just fall apart when attempted to be built into an executable.

That's all the request I need, thread moved.

Where have you been all my life? Seriously though in all the various posts I've made with my "Image Manipulation" code (another thread on LAVA) which leverages .Net and the PictureBox allowing for alpha layer images, and combining layers of alpha images. In none of these threads has BitMan ever been mentioned. I even have used my Image Manipulation code in other projects like the Toolbar Class for things like button overlays on mouse over, but still didn't know this existed. I think somethings probably have better performance on .Net like resizing, but still I likely wouldn't have dove into developing that code if I knew this existed. Oh and the added benefit of being able to have controls on top, or below the image (which PictureBox can't) is awesome.

So I finally got around to putting this up on the code repository. Source version 1.5.0 can be found here. The built installer can be found here. I added support for versions up to 2017, and added the feature to prompt if a VI is configured to run on open. Which allows to just open instead of open and run. And added support for the .VIM file extension.

View File LabVIEW Tray Launcher This application is designed to help manage a system, that has multiple versions of LabVIEW installed. It does this by adding an icon in the system tray for launching any version of LabVIEW installed. This may work with 64-bit versions of LabVIEW but it has never been fully tested. It has several other features which are useful when having multiple versions of LabVIEW installed. Launch any version of LabVIEW installed from the system tray icon. Kill or restart any version of LabVIEW running from the system tray icon. Abort all VIs running in all versions of LabVIEW from the system tray icon. (not asynchronous clones at the moment) Abort all private context VIs from the settings dialog found by double clicking the system tray icon. (not asynchronous clones at the moment) Control what version of LabVIEW is used on opening a VI or LabVIEW file. (File Extension support in the configuration dialog) Configuration can chance the behavior of this but by default it will ask what version of LabVIEW to open a VI in if more than one version can open it. By default a VI set to Run On Open will always ask what version, and if you would like to run it on open or just open it. Shift can be held when opening a VI to always be asked what version to use. CTRL can be used to select the default option which is generally the last version used. By default if only one version of LabVIEW is running, and it can open the VI, then it will be opened in that version. Other file extensions can be selected after the install. Read the Readme Usage for more information on how this works. For this software to function properly, at least one LabVIEW Run-time, or development needs to be installed which is version 2011 or newer. The source includes all versions from 2011 to 2017. The installer includes the builds from all versions 2011 through 2017. An AutoIt script and source are included which selects the right EXE based on what version of the run-time engine are installed. This is why multiple versions are included in the installer. Also for VI Server functions to work properly each version of LabVIEW needs to be configured to have TCP/IP configured and a unique port. This is all done automatically through VIPM so my suggestion is to configure all versions of LabVIEW through VIPM, at which point this tool should work. Some features of this will work without this enabled but not all of them. This is the LabVIEW Tray Launcher, originally discussed and developed in 2009 here. A fully built installer for version 1.5.0 can be found here. Just download the installer and run it. It should add all the needed files to the Program Files directory, and edit the registry if you allow it during the install. Submitter hooovahh Submitted 02/06/2018 Category *Uncertified* LabVIEW Version

I have some nice configuration managing code. Where I define the VI names which are like sections in an INI file, and then the control values themselves are what is read and written to the INI file where each control is a key. There are also methods to tell the VI values have been changed, because maybe other things like tables or trees need to be updated based on the change. This works real well for basic things and adding a checkbox or a debug setting that is then a value that can be read globally in the application is a snap. But as you noticed complicated structured, or large structures cause issues. I use the OpenG Variant INI functions which flattens larger structures into somewhat readable sections in the INI but adds many lines to the file and slows down reading and writing a lot. I added an ability to read or write a key as a binary blob so it will look like Debug=89FJD82JKSKFK2I. Which isn't as useful and thought about re-writing using the MGI INI functions. I've been meaning to transition to SQLite, or possibly TDMS since our test data is in TDMS, and being able to embed the tester configuration, along with the test sequence, and test data into a single file is an attractive idea but just haven't had the time at the moment.

I posted this behavior on the dark side.

Uh...so has anyone noticed VIPM getting uninstalled after upgrading LabVIEW to SP1? Program Files (x86)\JKI\VI Package Manager folder only contained the INI file with an entry for a recent file. The last mod time on the file was right around the time I upgraded to SP1. Seems odd and all I did was reinstall VIPM and I seem good.

Thanks, just downloaded and installed. I installed SP1 then found the F1 patch using the NI Update Service but couldn't find it with a google search. Sure looks like lots of attention on VIMs in that f1 patch. Couldn't find the SP1 release notes yet but the one cool new feature that I need to figure out how to abuse use is the VIM overriding in classes. There are two pretty good examples that explain how this new feature works. <labview>\examples\Malleable VIs\Class Adaptation\Malleable VIs - Class Adaptation.lvproj <labview>\examples\Channels\Replacing The Function At The Heart Of An Algorithm At Run Time\Replacing The Function At The Heart Of An Algorithm At Run Time.lvproj I guess I'm going to struggle a bit with how I should use this feature. I get that this is like dynamic dispatch, except that the inputs/outputs don't have to match in their data types with other classes, and maybe that alone should be a good reason to use it...what I really wouldn't mind seeing is someone doing a plugin architecture, using these VIMs. Maybe combine this with PPLs? Then build classes, that are unrelated, but can be called...or maybe these classes are related so normal dynamic dispatch works for when data types do match (and allow for a UI in the class to be shown or inserted) then VIMs for when they don't? I need to experiment a little more like if classes can be loaded from a file, and then called into a VIM...I think that would work just fine now that I think about it... Edit: Okay plugin architecture could work, but you still need a parent class which has all the closures (wrong term?) defined. Then on loading of the class it needs to be to the parent, and have dynamic dispatch turned on so the child function is loaded. Might seem like a lot of extra work, and empty classes whos purpose is to define things that honestly could be better defined if classes were related. Useful but maybe not where I thought.