hooovahh

I laughed but that could be read a few different ways. Let me clarify I actually made several efforts to use the Actor Framework. So I wasn't trying to say I hate this thing that I've never used. I was trying to say I made an effort and didn't like some things about it. It isn't complete crap, but it over complicates things where I don't need it to be, and doesn't do some of the common things I would like it to. People with different needs may find exactly what they need in the Actor Framework.

Full disclosure I don't use the Actor Framework and am not a fan. That being said, NI apparently did consult with many real world CLA's on how to make the Actor Framework. I don't know who in particular they consulted with, but the intent was to get the opinions of those that would end up using the framework, and try to understand the best way to make it. Also if you are a CLA and have the opinion that the framework is UNREADABLE, then I feel there is something wrong here. Either the framework does need major overhauling, or maybe you need to look at some training on the framework. I'm not trying to suggest you aren't competent please don't read it that way. I just don't know how much you have invested in trying to understand the framework and certainly anyone new to it will feel lost (I know I do). I often fall back into the QMH on a fresh install of LabVIEW, or the JKI state machine if I have a chance to install it. For larger applications I usually spin my own actor type design using user events and variants. I can't get over several things with the Actor Framework like the re-entrant actors, which make debugging difficult. Honestly it might just be how I think about my applications, but there is never a time when I would want to kill just a single actor. The only time an actor should close, is if the global quit was issued. With plugin architectures, and factory designs I can see a need, but that just isn't the world I live in. EDIT: Just saw this crosspost.

It says it was reported on Jan 26 2015. I am looking into a way to get that notice removed. I feel it is the kind of complaint that should be discussed before considering a submission broken. Until then here is what the user complained about.

I sorta agree. I mean on the surface I wonder why do I need a VI for every read/write property? Why can't I just specify what data is public, and if that data is read only, write only, or both. Then have the property node work without needing to write a tons of VIs, even if the majority of it is done through scripting and templates. But having a VI for these actions does add other flexibility. Like if I perform a write I can have that VI do more than just set some data, it can also manipulate the data or perform some other action other than just a bundle by name. That does make we wonder why NI choose to do what they did, and allow public data accessed through a property node, via a VI call.

Okay so here is the VI I came up with which is similar to the one jdunham posted earlier but this has a few improvements. It finds the local decimal separator (discussion here). It only allows one decimal separator. It only allows white space in the beginning or the end. I feel a space between numbers is no longer a number because the String to Number conversions don't work right if there is. I added support for Hex or Decimal strings. Oh and this version supports things like ".1" where the one posted by buckidge would not work correctly. It does not use regular expression but generally regular expression is slower than custom code. I could be wrong so post a version that does this with regular expression and we can compare. Saved in 2013. EDIT: It now support negative numbers as well. Is String A Number.vi

This is nice and all, but I feel like not many users are going to have a need for this. The RCF was a great innovation and I thank JKI for what they did. But as far as I know the RCF hasn't worked in something like the last 4 years of new LabVIEW releases. I might be wrong but I think 2010 was the last version it worked in. Please correct me if I'm mistaken. And while I feel the RCF had a relatively large user base, I'm not aware of many developers using LVS daily. But again I want to state that I both support and like LVS and RCF, I just don't use them, and would rather stick with the native solution of QD, even if it has many limitations that the other alternatives don't. So what versions of LabVIEW do you use? and how much do you use RCF and LVS? Oh and as a possible improvement could you have your tool auto detect what QD plugins are installed and have a drop down of them to choose from, in addition to the VI path control you already have.

It was a very painful thing to watch. We were actually at a movie theater waiting for the show to start and he pulls out his phone and starts coding. The slowest coding you've ever seen.

This is true but I have seen developers remote into a PC from a phone and then write code from their phone. Of course that would drive me more crazy than having to use a touch pad for programming but I've seen it done.

Your second link doesn't work by the way. Yeah it is odd to have a new feature in a SP1 but it looks neat and I hope can help make tracking down those pesky memory issues easier.

I sure hope not. Have you used XNodes? They have all the functionality of generics and a ton more. Heck I'm sure the original question could be solved with a simple XNode. I want type adaption that is better than polymorphics. But I also want custom help, icons, growable nodes, custom right click menus, and edit time scripting. The good news is this technology has been developed and used by NI for quite some time. The bad news is they aren't ready to support it as a product. When scripting was official I was ecstatic. If / When XNodes are supported as a product I will likely drop all other work I'm doing and focus my work on supporting and releasing tools that I've wanted to write and make official for years. Few things could NI do today that would make me happier.

Please don't generalize. The testers I use, are I think the feeling around here, is test systems can fall apart for any number of seemingly insignificant reasons. And if my tester blue screens after a Windows update, I'm going to blame the update. And if my program was working fine on F1 patch and then it auto updates to an F2 patch and all of the sudden things stop working, my boss and customer aren't going to give a hoot what cause the problem they just want it to not happen again. Having as much control over that environment as possible helps me ensure I can do my job. I see automatic Windows updates, automatic driver updates, automatic patches, anti-virus, and firewall programs and ways of me loosing control over my environment.

There are several discussions on LAVA about what references should and shouldn't be closed. The statement that I think holds true about 90% of the time is "If I did something to open a reference in my code, then I need to close that reference". Did I use OpenVI reference? Then I need to close it. Did I use a reference tied to a control? Or the ThisVI reference? Then I don't need to. It starts to get a little confusing with things like an invoke node that can give you a reference to an already open thing. But throwing close references around shouldn't cause any problems. LabVIEW will try to close that reference, and realize it can't for some reason, like the VI that owns a control is still in memory and it won't do anything. I've often wrote a simple VI that is just a while loop that runs forever, which will perform some kind of operation that I think might be making new references, over and over without closing. Then I'll look at the memory usage in the Task Manager. If it doesn't go up, then that reference doesn't need to be closed, if it does then I need to close it.

This isn't too difficult. Once you have the read data as an array, go into an auto indexing for loop and process each row one at a time. Then concatenate the sum to the end, and rebuild your 2D array before writing it again. Attach the code you've tried.

Thanks for this, I always assumed it was NI just putting resources into making something that users didn't want. Now I actually know it is the users fault for asking for something that they shouldn't need.

Are you talking about the NI Service Updater thing? Yeah I have never used that to update any PC, and never will. I have a hard time trying to convince it to stop bothering me. I don't upgrade software, drivers, operating systems or anything in the PC ecosystem unless there is a good reason. It just adds new risk changing the environment from what you've been using. So unless you are in an academic environment, or just playing around and not making production level applications, why would I ever want you updating a thing?

So the app.allcontext property node is a private method. It is something NI uses, but doesn't fully document, doesn't support, and I'm sure they'd prefer if no one other than NI used it due to it's possible non-completeness. You see if NI is playing around with some new property nodes that are private, they can change the behavior between LabVIEW versions without needing to update the public, or worry about backwards compatibility. Because they should be the only ones using it. But if us pee-ons start using these functions, and then they change how they work between versions, now all the sudden users of LabVIEW complain to NI about how some obscure private method broke their production code. That being said many private methods have useful functions, that appear more or less stable. Over the years NI has tried opening up more private functions, to be public and to that I thank them. But I'm not sure this function will be made public any time soon. With it you can screw around with the inner workings of LabVIEW. But if you are the adventurous type, you can enable these private methods. Here is a thread where I made a tool for enabling and disabling these methods. https://lavag.org/topic/16612-enabledisable-private-methods/ But please be aware that code that uses private methods can be dangerous, can change functionality at any time, is undocumented, and can break things. You also won't get the support you might want from NI.

I quite like SVN. Yeah I know there are times when it has problems and you need to do some manual fixing, but those are generally times when I screwed up. So I just try to not do what I just did again. The problem comes when every person using SVN needs to learn those lessons one at a time. You can say "Don't create orphan locks" but until you learn it and fight to fix some SVN screw up you won't remember it. I could probably get used to some other SCC but it does what I need.

Some have asked for the Variant Repository VIs to be available as non-XNodes. So I wrote some scripting code to make polymorphic instances, edit VI icons, and make the polymorphic VIs. But what I hope this illustrates is just how useful XNodes are. The Non-XNodes version is 252 VIs and one control. That's a lot of VIs to have to load into memory when using these polymorphic instances. That's 60 normal VIs inside each of the 4 polymorphic VIs. And it doesn't even support all of the features the XNode counter parts do. From a reusability stand point polymorphic VIs have many things that make using and maintaining them difficult. From the number of files loaded, to custom help, icons, and terminals from each instance, along with supporting more types than the polymorphic could. Don't get me started on when a bug is found and it isn't something you can easily fix with scripting. So then you need to open up each of the polymorphic types and make changes to each one. Oh and ever try to use the polymorphic editor with 60 instances? Yeah I've stopped trying and use a combination of tools so I never need to. Some day, hopefully NI will be able to invest the time needed to make XNodes an official feature. But until then I'll likely need to support many polymorphic types, when XNodes aren't trusted. Variant Repository Non-XNode.zip

Is there a reason you are re-inventing the wheel? If there is a good reason like trying to understand how to communicate with a DLL then go right ahead. But if you are doing this for some fear of using NI-VISA I'd highly recommend you confront your fear.

Topic moved. Also have you contacted NI about this? If this is a real problem they will want to make a CAR for it so it can be fixed.

No problem. I know the stigma around express VIs very well. To be honest I only use two express VIs in a very large amount of my own code. The Elapsed Timer, and the File Dialog. When I do use them, I try to always view them as a normal subVI and remove the label. Still for these two functions, the simple stuff just works. Sure it doesn't have a pause resume feature, but when I need that I'll start with the Express VI, convert it to a normal VI, and then add that funcion. I try to use the native functions first, then OpenG, then other 3rd party tools, then I'll write my own if none of these options fit my needs. I'm sure others prefer similar chain of tools. There are goofy times that maybe the native solution works, but only for half the cases in which I need to remember what ones work in what cases and what ones don't. Like it is nice that there is now a native "Get File Extension" under File I/O. Too bad it only supports the path data type, and not the string like OpenG. In this case a path to string conversion can fix it but there are several examples of this type of partial overlap in functionality.

Oh yes that is a nice little trick to use. Be sure and share that nugget when you find others that don't know that is how it works.

So I know this is a few years old, but I wanted to update it. I stumbled across Altenbach's post here, about converting a 2D to a 1D array. So I combined his code to the code in this post and made two polymorphic VIs that support a few more features. From the 2D to 1D it has several more polymorphic types, and supports concatenating by rows or columns. From the 1D to 2D it has several more polymorphic types, supports specifying the number of rows, or number of columns to make, and supports iterating over rows, or columns when splitting. I wanted to make individual icons for each polymorphic type but didn't get around to it. I also pulled these out of the LLB but admittedly that was just so it was easier to work on, on disk. 1D to 2D Array.zip 2D to 1D Array.zip

Is there a reason you are using this function and not the native "Elapsed Timer" express VI? I've never used the OpenG function and wasn't sure where one would be better suited than the other.

Here is a quick solution that just looks at the value change seeing if the string changed value and if it did read the value of the boolean. A better solution might be to look at the Mouse Down event, and find which index the mouse has entered then read the boolean value and do something else like force key focus off of that control so the user has no way of even entering a string. The way it is right now is sorta strange where you are allowed to enter text in the control, and then it revers back. I feel like a better user experience would be to prevent them from entering the control in the first place. EDIT: Okay another quick and dirty solution, poll the key focus of the string and if it is true then read the value of the boolean, and if it is false, then remove the key focus. I did it this way because with the mouse down event you could still tab into the control, and edit the string control. This way is less efficient because you are checking for key focus but it prevents this edge case. Editable Disable Array.vi Editable Disable Array Poll Keyfocus.vi