hooovahh

My example isn't quite right. I just meant if you were handling other events, in addition to setting a timeout to be very large, that the result may not be what you expected.

You probably know this already, but the 15,000ms timer would get reset every time any event is handled. So if I had a Mouse Move event on the panel and continually moved the mouse, the timeout case would never get handled. Because of this I would often have a small timeout like 100ms, with an elapsed timer inside to see if 15s have passed. That being said I think Gregs answer is the better then this.

That's a pretty good list. As mentioned before 2013 had a big improvement in these types of controls as mentioned here. http://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/page-2#entry104672

I didn't know about this, but haven't had a need to yet. Also XBMC Plugins? You must be doing some cool stuff.

I'm not sure I fully understand the problem. Is there something wrong with the VIs I posted other then the output of the subVI should be the reference instead of the value? Is the issue that you want to do this for multiple VIs at once? That will get tricky. I'm not sure how a subVI can know which instance on another VI it is responsible for. Feel free to attach a zip. You'll need to click More Reply Options, and from there can attach files.

The subVI I made has a connector pane with only 2 terminals. I did that for simplicity because I didn't know which would be input and output this way I could know index 0 was output, index 1 was input. Disconnect the variant output from the connector pane, and connect the Control Reference control to it. I made an indicator in the subVI for the reference itself. EDIT: And yeah I can't think of anyway to do this without scripting. Besides this needs the block diagram to be available and EXEs generally strip those out.

Okay a couple quick VIs later I have a working version but there are likely better ways to do it. Run Main VI with a control connected to the input terminal. The output is a variant value of that control, getting the value by reference, by looking at the control connected to it. Get Control Ref Test.zip

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.