hooovahh

That's very interesting. So I would guess (haven't tested yet) that any coding around we have done in past applications to improve performance, will continue to improve performance in 2013, but we may find that these improvements are no longer needed. Thanks.

So I'm sure others have done this too, but when I get this type of AE I will usually wrap the functions into SubVIs so only the important terminals are being shown for that function and then inline the VI. So maybe Init will call the AE 3 times with different methods and using some but not likely all of the connector pane inputs. I'm pretty sure I saw this technique on JKI's blog at one point. I agree with your definitions, but I also agree with Shaun that the need for these different terms might not be necessary. I guess it should be directed to the audience you have. Some may know what a Functional Global is, and no clue what an AE is (Action Engine for those who don't). The different terms don't bother me too much because when talking to others about it, it rarely matters what kind of global is being used (as long as it isn't the native one), it just matters that we understand a non-re-entrant VI with uninitialized shift registers is keeping track of some data between calls. Also I'm curious, has anyone developed a tool to perform a search, for a specific VI, where it has an enum constant wired to a terminal, with a specific value wired to it? I don't think it would be too hard but if I want to find all the places this particular VI has had the "Write Data" method used I either have to find all calls to that VI and look for the constant, or find all places that "Write Data" appears in my code with a string search.

This is great, but I have a home grown one that works with user events, and it works at run time as well. So I have one window that will show me the last N number of user events generated between my Actors, and can then display the data (using the Variant Probe). So if something goes wrong in the application I can see the chain of events that caused it. Neat but I think I will only use this on shutdown. It isn't very often that I find a queue of events pilling up that I would need this but it's nice to have. Neat again, but I don't think I'll need it. Possibly to flush away extra window resize events, as already mentioned but I doubt I'll need it. Finally. I posted on Lava a while ago when I found this "was not implemented". Finally. The ability to zoom a graph with the scroll wheel sounds like a feature that all graphs should have. Also when doing things like having a scrollbar not attached to a control you can now have more flexibility on what happens when a user scrolls on top of a cluster (it can then change the scrollbar value) All neat and I'm sure will help develop code faster. I never ran into this issue.

This is very well possible (that I don't fully understand). If what you are saying is true then maybe the real reason I have a difficulty knowing the difference is I've never used a QMH the way you describe. Sometimes I start with a QMH template, but by the end I have what you described as an Actor. So I guess what I'm saying is I'm not sure I've ever used a QMH in an application, only an Actor.

Semantics aside a FGV can have race conditions, just like a normal global. But a FGV gives me the ability to perform other functions, other then just read and write. Because I don't know how my applications needs will change in the future I never use native globals, and only FGV. Lets say I'm storing an array of values, well I can have my method on the FGV "Read" "Write" and "Average" a native global can't do this without extra code which isn't that big of a deal but I prefer this method. Other functionality that can be done is stuff like WORM. Where a global can only be written to once then it will generate an error if it is written to again. Many of the pitfalls of a native global exist in these other VIs, but allowing added functionality, and also adding other debugging tools helps to make sure you don't shoot your self in the foot. But it can still happen.

Thank you for the clarification I knew there was some bug fix regarding how this was handled but I wasn't sure the specifics because I personally have that issue.

This is by far my favorite too. I missed your presentation because it was the same time as another and a tough decision was made. While web services are slick but I don't know if I will use them any time soon. And what about MyRIO? I know this is a new features of LabVIEW thread but why is a FPGA and dual core arm running linux real-time, with built in WiFi, and USB host for $500 not getting lots of attention (price was mentioned by NI but not confirmed yet)

What if you want to reset the graph when the user resizes the window? Or right clicks on a control? Or. Double presses the escape key? How would you handle this without the event structure? The code you described is very common using the timeout case. The only thing I would do different (but isn't needed) is to set the timeout to 1ms, then use elapsed time to only update every 100ms. Any event generated will reset that timer so if a user spams the keyboard where the event structure handles key down, the timeout may never happen. This functionality slightly changed in 2013. I haven't tried it but I heard the timeout isn't reset with dynamic events anymore.

Thank you so very much. Would you mind going into detail a little about what is done for the improvement? Mostly just curious and if your answer is "It's complicated" then that's fine with me. We were just guessing at the Lava BBQ and we assumed that it was doing behind the scenes, what we were doing as work arounds. Things like only updating cells you can see in the control, and only loading data for the cells you can see (so a table only has 10 rows show so it loads those 10 rows at a time with a fake scrollbar)

I'd be glad to give detailed feedback. But I will hold off a detailed response until after I see slides or the video. I can't remember all the things said but one of those things will help jog my memory.But know I left that session convinced I won't use the Actor Framework. Again I can give details later but I kept having this feeling that NI's AF had many restrictions, steep learning curve, restricted debugging, and didn't add much over other Actor/Asynchronous Engine designs.Another big turn off was the semantics between an Actor and QMH. I realize it is a heated topic, but I don't see the big deal and to be honest this could be my own opinion because I haven't had 1-on-1 discussions to hash out the and understand the topic fully.Ok one more thing. Other diagrams would help but I don't remember having a problem with what you had.

Don't get me wrong I think a discussion about alternatives other then NI solutions is great. But I have seen too many recent threads (mostly on the NI forums) where someone will post a question with their first post for a very specific thing. Then a new member makes their first post promoting some other (usually software) solution which is shareware. If this is not the case I apologize for jumping to conclusions.

If I was a betting man I would say this os spam. A user with one post, then another user answers it who also has one post promotting another company.That being said I don't know if MyDAQ is a good solution if you need it to be rugged. But any DAQmx hardware is extremely easy to use. Start MAX and start using the hardware in seconds. Then open LabVIEW and an example or express vi to use the hardware. It can't be more simple.

That is really neat and I will want to do some tests to compare results with OpenG, and MGI options too. My original thout was replacing the save to panel and load but that will happen seldomly and a better use case is as you said, constantly updating a UI.

Very cool Norm. Just saw the presentation by Nancy and I can't wait to try this out.

I had this issue just yesterday. I built an EXE and and installer and put it on a new PC which complained about missing a DLL. Lots of searching later I found it was an XNet DLL, so I searched for all XNet functions until I found one place where it was never being called. I have yet to call support for this issue but I have spent alot of my own time trying to figure it out. EDIT: A few that caught my eye. Scripting the event structure. More control over events like queues (flush priority and size) Email with security Tasks/Todo lists built in (I was just about to make a tool for that) Better build errors (hopefully we won't see a blank details again) Control value by index seems neat but I think there are other ways to do the same thing

Don't get me wrong, I can't wait to try it out and see what other features 2013 is going to have. So generally LabVIEW releases are hit and miss. They will have a stability build, then a feature build, where the feature build will be great but usually rough around the edges. Since having a service pack mid-way through the year this seems to make sure all released versions are solid. For this reason I have no fear about using a SP1 version of LabVIEW. But I am still apprehensive about switching to a new version before this SP1. This could probably be made into a new topic, but do you believe you will switch to 2013 as soon as possible? Or are you going to wait a bit and test the waters before diving in? The idea of using new awesome stuff both frightens and excites me. My colleges usually wait until SP1 because it lines up with the Veristand release so if I did go 2013 I would be the one finding all the issues first.

WOO HOO!!! (sorry for the caps) It looks like (pending any major issues) that I will be going to NI Week for the first time. Not fully sure what to expect but I'm excited and can't wait to meet more LabVIEW nerds, and see what NI has to offer. I know there are a few here that owe me a beer, and a few that I owe to, so I hope we can square away some of that debt.

This almost worries me. You see for years the Tree control, multicolumn listbox, and table have been dog slow at doing individual cell updates when there are many. So to get around this I have several coding techniques that will improve performance. Things like only updating the cells visible, only showing a subset of the data then load the other data when you scroll, and defer front panel updates. So my worry is that my performance from older applications will actually be slower then the native implementation, and now I'm going to end up removing all that hard work I did to get around LabVIEW's issues.

Man I remember how excited I was when I got a Nintendo GameCube for Christmas. Many hours were spent playing All-Star Baseball 2002, and Star Wars Rogue Squadron II. If someone around the office said something like that I would be concerned. It was bad enough when I was working with people born after 1990. Something about working with someone from another decade messes with my head. In 5 short years it is possible I could work with someone born after 2000.

Wow a little large? I was thinking this could be a bench top DMM and the case I had with LCD was even a little large for that at 9.5'' x 8'' x 3''. Your box is 17 x 12 x 10 (I assume inches). Still re purposing hardware in this way to make a dedicated machine is a neat idea. Oh and it might look cool if you add front banana jacks for connecting to the DMM.

This will work just fine as a stand alone DMM, if you don't mind the extra cost of a motherboard, Processor, Hard Drive, RAM, Power Supply, case, and software. Depending on how slick you want it to look I would recommend a PCI riser of some kind. some thing that gives a flexible ribbon cable, or possibly just a 90 degree bend, so the DMM sits parallel to the motherboard to save space. Then you'll probably need a custom case to house it. I've never used any of these cases but here are a few that might work http://www.circotech.com/istar-s-21-mini-itx-box-computer-case.html?gclid=CPq7jqur17gCFUXNOgodTDYAPw http://www.ebay.com/itm/Morex-2766-Mini-ITX-case-w-Dual-PCI-Bays-60W-PS-/130747941410#vi-content If it were PCI-Express you could fit it in the a very tiny case, and thin motherboard, and external power, using something like this. http://www.mini-box.com/I-O-shield-and-riser-card-for-DN2800MT EDIT: I changed my mind this would look awesome with the LCD read out if you can control it. http://www.mini-box.com/M300-LCD-Enclosure

I do see this issue in Windows 7 x64, but this reminded me of LVMark. https://code.google.com/p/lvmark/ http://lavag.org/topic/14700-lvmark-format-markup-for-string-controls/ And oddly enough I couldn't make its indicators break like yours.

Just wanted to post to let you know you are not alone. I have seen this and was confused so I ended up taking a finite amount of data (100 points or so) then averaged them.

There is a "Minimum Panel Size" on the VI that is in the sub panel, but there is also "Minimum Pane Size" on the panel that the sub panel is in. This way you can prevent the window from being too small, by keeping the panel from being too small. You will want to do some testing however. I remember a time where I would set the Minimum Pane Size so my right pane wouldn't get too small, as I made the window smaller I hit the limit of the right pane, but not the left so the left pane stated to get smaller which was the pane I wanted to not change size. Just experiment a while and all these Minimum controls will keep it from getting too small.

If you are missing the lvapp.rsc from LabVIEW you likely need to perform a repair on the install of the development environment, or run-time engine (or both).