hooovahh

Yes this could be done with scripting. Of course if you call the VI in to places on one VI I don't think you'll be able to find one versus the other. This would have to be done with scripting, so you couldn't do this in a built application. Also you would probably want to limit this to only work with a control terminal wired directly to the subVI. For instance if you had a string control, then go to a string concatenate, then to your VI then this function wouldn't work. It sounds too difficult to keep looking up stream to find a control.

I like the idea of this but I think your implementation is a little flawed. I noticed that when selecting the digit to edit using the mouse, that you didn't take into consideration that numbers have different widths. You just took the total width and divided by the number or characters. The attached code should work on all font sizes, and types to try to find the character that the mouse is over, based on the coordinates of the mouse. Attached is an update that I think fixes these issues. Admittedly I haven't tested it on a bunch of controls just the one you provided with different justifications to test they all work. easy_inc Hooovahh Edit.zip

That's a great idea and will bring it up in my next goals meeting. Not to set a goal to get X number of likes/kudos, just another bullet point in growth over the past year. Well my legacy is being Crelf's alter ego for irking people. I'm not even my own person...or am I?

The most glorious link I've seen in a long time. The site seems a little cluttered and unorganized if you go up a few directories but still better then NI's site search.

Found a bug, Current VIs Parents Ref__ogtk.vi, and Current VIs Reference__ogtk.vi should not be inlined. They are index 5 and 6 on the VIs to Modify array and to fix it just turn off Inline for these VIs. They can still be Shared Reentrant.

I never said that an XNode would have better performance then the exact same code in a normal VI. I was comparing my implementation (or Gregs) to the XNode implementation which may or may not use the same technique. I thought I heard of an XNode replace before so I did a quick search. http://labviewwiki.org/ReplaceSelf_(XNode_Ability) Which I assume is what we are talking about, but again my experience with XNodes is quite limited, mostly just using what others have made.

This crossed my mind again recently so I figured, why not make a VI that makes OpenG VIs inlined? So attached is just that. Don't get me wrong it doesn't inline all VIs that'd be crazy. So what I did was opened each OpenG VI, then look at what VIs can, and can't be inlined, and if they are inlined do they have uninitialized shift registers? If so then they should likely have the Preallocate for reentrant clones, instead of Shared. I also modify all OpenG VIs to turn off debugging, and automatic error handling. In the zip is also a VI I used to verify find all broken OpenG VIs. This can be used to see if any new broken VIs are made, after making these inlined changes. For my OpenG setup there are 4 broken VIs that are supposed to be broken, and after running my Modify OpenG VIs.vi I still only have those 4. I don't know if there are other unintended changes but I haven't seen any yet. If you use this and find any issues please mention it. Opening each OpenG VI and looking for what can and can't be inlined I noticed that many of the ones that can't be inlined, are due to using local variables, where a constant (or type def constant) would work for getting the type. I also saw some instances of using the expression node when native math could be used. And I saw a few times where the conditional disable structure could be used instead of a property node. Even so all of the array functions can be inlined. If you do use this I recommend backing up your OpenG library, in case something goes wrong. Or you could just uninstall/reinstall with VIPM I guess. Modify OpenG VIs For Inline.zip

All off, I even have the subVI inlined just as my example in the zip I posted earlier.

I think it partly is a matter of opinion. Right or not, on startup of all of my Actors I put their corresponding "This VI" into each of their own globals. I can then use this to see which Actors have their front panels opened, and allow thing like a Manual Screen Actor which just loads other actors into a single sub panel as needed.

One thing that may help is the VI being inserted can detect if it is in a subpanel. So the top level may not need to tell the sub VI of the state change. Of course that means polling so maybe that isn't the right way to go. http://digital.ni.com/public.nsf/allkb/FB79ED8B6D07257B86256E93006E31FA And starting in 2012, if you have the reference to the subpanel, you can get the reference to the VI that is in the subpanel using a property node.

That is fantastic. I don't use that function often enough. Your comment about it being faster then the XNode isn't true for my test. Many times better then my OpenG version for sure. I had to run 10,000,000 iterations to get anything usable. With that many iterations your version took 1540ms and the XNode version took 1ms. Even so given the XNode limitations (in terms of support) I would probably use your version. I want to believe your statement about using XNodes. Partly for this function, and partly for the OpenG Array tools. What I'd really like to do is package up these tools into our internal reuse library. But that is just something I cannot do until NI endorses using these techniques. Maybe I could make a XNode package and not include it in our base reuse and just have it be experimental. EDIT: And no one has suggested this yet but you should submit this to the Code Repository. There is a category for XNodes.

I stick with the top level handling who gets load and unloaded. That doesn't mean you have to do it that way of course. You could be in a loop attempting to insert your self into the subpanel continuing to try until no error is see (or time out). For me I find it easier to have my sub VIs not deal with the subpanel for a couple of reasons. The less code in my sub VIs is better because I assume I'll need the same code in each child VI and copying the same code means more places to fix it if I find a bug. But also I some times may want to run just my child VI as the top level and debug things.

Thanks for the tips AQ, what about Automatic Error Handling, and Debugging? Shouldn't those be turned off too? In either case I just re-ran the timing test from above and it isn't a surprise that the XNode is still much much faster. I ran with the changes you suggested 100000 loops and the XNode registered 0ms, and my version with OpenG was 8724ms. I inlined the OpenG VIs out of curiosity and it went down to 8413ms. I'm torn because I like this XNode, but won't add it to my reuse tools due to the fact that it is an XNode. Which is why I tried implementing a solution just as easy to use but with OpenG. Attached is my benchmark saved in 2012. Selector Speed Test.zip

Very true I was thinking this would be used in a finite sample type of situation but yes if you are doing this continuously you'll need some extra work. It was just meant as an example anyway.

Using the transitions output would probably be easier but for my test I created the analog and digital data. I think it works but you'll want to check my work of course. I don't have 8.0 (which your profile says you use) so I attached an image as well as the VI saved in 2011. Integrate Analog Digital Values.vi

Saved in 2010 Get Image Data From PictureBox 2010.vi

If you are interested in getting your image back into a LabVIEW data type you can use the VI I attached. Provide the Image from the PictureBox and you'll get the Image Data back out in PNG format. From here you can perform a save and I believe transparency will be kept. If you try to display the this image in a 2D Picture the transparency will be lost. Using this PNG to Stream or Stream to PNG dance you can go to and from the picturebox and system drawing tools, to the LabVIEW tools and back. Get Image Data From PictureBox.vi

Are the Analog and Digital samples driven from the same clock? Are they sampled at the same rate? Are they started at the same time? If you answer yes to any of these your life can get a little easier. Saying no to all of these questions means lots of manual code searching for times that match up and will likely take much more time but still do able.

There are other members on the forums with more experience then I. But what I do know is that LabVIEW doesn't really support transparency. It does support the data, but not displaying the alpha layers. http://digital.ni.com/public.nsf/allkb/00736861C29ADFB786256D120079D119 Because of this there are many tricks people have come up with to get around this like reading the color of the background, then merging color of the background with the alpha layer to come up with a pretend color that looks semi transparent. Other trick involve using the Windows .NET PictureBox control which does support alpha layer information. I've had success with using this in the past but only to display already made images that had alpha characteristics.

Personally my activity on LAVA (and NI) has increased a lot in the last "several years". Recently I've crossed over the 1000 post count on both forums. I never plan on attaining any status like Crelf here, or Altenbach on NI but I wanted to be more active. My current employer even made it a goal of mine last year to be more active on LAVA. Bonuses and pay raises are based on how well you work toward your goals so you could say I have added incentive.

Now NI will sue the pants off of them. See what I did there? Because their a clothing store? /crickets

First the original question. It sounds like you don't have DAQmx installed. This is a driver add-on that also adds functions to you palette. It is a rather large download and the latest has no support for 2009 so you'll want to check the release notes for the right version. As for integrating a zip. What is in this zip? How was it made? I'm guessing someone just zipped the user.lib but without knowing what's in it it is impossible to say how it should be used.

The Draw Flattened Pixmap doesn't accept an array or output an array. If want more information about a function open the context help by pressing CTRL + H, or clicking on the help button then mousing over the function. From here you can click Detailed Help for even more information.

Sorry to hear this I'm sending Michael a message to see if he has a fix. In the mean time what you can do is go to the user who posted the spam, and report them instead of reporting the single post.

This is not typical of a LabVIEW built EXE and I have only ever seen it in programs that have issues finding some component of the EXE that is external like .Net assemblies, DLL calls, or dynamic VI calls. I'd suggest building an EXE with debugging turned on, and then when it loads it might give a reason like expected loading location of a component was different from the expected location.