hooovahh

I have no info but wanted to say I won't be there this year, and have made that clear to the other LAVA BBQ organizers. I'm choosing to go to the CLA Summit in Austin instead. If I do hear anything I'll be updating threads here, on the dark side, and twitter.

That is seriously small and would be very annoying. Hope you have custom DPI settings for your mouse.

Oh yeah I wasn't suggesting performing the value change on the booleans. I was suggesting getting the coordinates, then performing a mouse move, and mouse click, sicne I assume squish does the same thing more or less.

Zou is probably right. LabVIEW does a lot of nonstandard things in their UI drawing, likely so they can be more easily crossplatform with Mac and Linux. Have you thought about possibly leveraging a LabVIEW EXE to get information about the position of other controls? I could imagine a LabVIEW EXE that opens an application instance to an already running EXE, and then get reference to VI front panel, then references to the controls themselves. It might be possible at that point to get the position of a control, based on the control label in the VI. Then it might be possible for your tool to get the positioning of a control, based on the name. But at that point one could make the argument to just use LabVIEW to control LabVIEW. Nothing sounds like a good solution.

Just an FYI there is an INI key that can turn this off. It is not exposed in the options but probably should be. Changing work flows can be a good thing. Years ago I thought the best way to keep a record of my source code was to zip up all of my source everyday. I'd have a zip for each day with that days snapshot of code in it. I'm so glad I learned about proper SCC and the workflow changes that came with it. QD and conditional tunnels have likely saved me man months of time and I'm grateful for it. SCC has probably saved me more than that in the amount of times I would have otherwise lost data, or opened the wrong version unintentionally. That being said many improvements you don't like you simply don't need to use.

I think most (if not all) AI DAQ hardware have a single hardware timer inside them for triggering the analog to digital converter. This is why only one task can be running at a time. That single task can be configured to read N channels of course at the same sample rate. So one solution might be to create an asynchronous task that has the sole purpose of reading all the DAQ channels in a single task, and throw them into a global. Then the reentrant VI clones just read from that global. Attached is an update which works with my simulated hardware. It will read the first 8 analog signals on "Dev1" device in a loop at 100hz. 4 times a second it will read 25 samples from each of the 8 channels and then push them to a global that limits the amount of data stored. Then in the reentrant VI instead of randomly generating data it reads it from that global. So now you can display 8 things from up to 8 channels but they could all be from channel 1. Now you can have a graph, and a digital display of channel 1, and maybe graphs of channels 2 through 7. If your hardware only has 4 analog inputs you can change the array subset function to that, and then update the enum for signal selection. Signal Selection Demo 8 Way With DAQ.zip

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.