hooovahh

I was thinking about it and I wonder if when LabVIEW first introduced event structures, if people had one event structure for each control. Certainly not knowing the intended way to work with a tool is a common way to use it improperly, and generally speaking having multiple event structures is a red flag for this. But when advanced users know what they are doing, powerful things can be done with these tools.

Why are you using that function? The reason I ask is because no program that I have ever written has needed it. Every time I see it used it didn't need to be. I'm not saying it doesn't serve a purpose I am just trying to say you don't need to use it. That function as stated will release memory not being used. How do you know which memory is not being used? The compiler will decide what memory it needs and doesn't and will best optimize itself. So you running that function may do nothing and that would be expected. Or it may do something but what the something is, will likely be unpredictable. My advice is to just trust the compiler and not use that function to release memory, unless someone at NI has said to for some fix to an issue. EDIT: Okay after re-reading the function description I think it could be used and have some benefit in some programs that perform some work seldomly, and you want to discard the data before exiting the application. One reason your code may not work is there is a race condition, where you are requesting a deallocation in parallel with creating your array. Perform one then the other using some data flow or sequence structure.

That's great but doesn't answer my question. Why aren't you just calling the subVI like normal? Drop it on the block diagram using the Select a VI... from the block diagram. If you can show some code, maybe a simplified version of what you are doing it may be easier.

Yeah I've used this technique. Newer versions of LabVIEW have issues with this but I have had some minor success in trying it. More research is needed. At some point it does get a little ridiculous trying to develop in 7.1 when you are used to modern features. And my modern I mean things like Listboxs with the properties and methods you are used to. And of course I'm familiar with the segmenting of the RTE. Very cool stuff I haven't got around to messing with it yet, but is another option for sure for a situation like the one I described.

Lets say you have a set of customers that each have some version of LabVIEW run-time engines installed, but not sure which ones. You can't build a LabVIEW EXE to give to them because you don't know which one they have installed and if you give them a 2013 EXE but they only have 2011 it won't run. You could send them an installer with the 2013 RTE but that is ever growing and can be a pain to download when the customer isn't sure if they need it or not. Well my idea is to use AutoIt to get a list of the LabVIEW versions (development or Run-Time) and then choose to run a EXE built in a version that is compatible with the version installed. This means building your EXE in multiple versions of LabVIEW and for larger applications this may make less sense then just distributing the full RTE for a single version of LabVIEW. Attached is my source. Extract it and you have a Source folder with the project and VI that just reports the LabVIEW version and path. And a Builds folder which has the AutoIt source (au3 file) and the built EXE from the au3. This EXE should run on any version of Windows XP and newer. Then there is a folder of EXEs all built with different versions of LabVIEW but from the same source. When the AutoIt EXE is ran it finds a RTE compatible with an EXE that is included and runs it. In the zip is version 2011, 2012, and 2013 but to add others just add the folder and EXE named the same as the others. I wouldn't be surprised is someone like JKI or Wirebird Labs has done something like this in the past but I thought I would share what I have done anyway. My use for this is with a new and improved version of my LabVIEW Tray Launcher. It is assumed if you are using the tray launcher that you have a version of LabVIEW installed, but which one? I could distribute multiple versions in a single installer, and then have the shortcut launch the AutoIt EXE which decides which LabVIEW EXE to run. I haven't fully tested it but it appears to work properly. EXE Test.zip

I think it is a bug but NI may disagree. The only other thing I have to add is I wanted to see what control LabVIEW though was in focus and found a private method called "Text Focus" using the front panel reference. By the way I think this method should be public if NI is listening. In either case when I went to read the control that has focus it returns a reference with a value of 0 once you enter the Mouse Down? event. So this means that even before the event structure has a chance to discard the mouse change it will already have lost the focus so by the time LabVIEW discards the mouse down it will be too late. I also tried disabling the control and it still would steal focus. FocusLab hooovahh.vi

I'm a little confused? Is there a reason why you don't just call the subVI like normal? What you are doing here is opening a reference to the VI by name. This will only work if the VI is already loaded into memory, and depending on your setup it may not always be, especially if you build it into an EXE. After the open you are closing the front panel. But the front panel was never opened so it will generate an error unless you already have the front panel open for some reason. All you did was open a reference to the VI it was never ran, so the code you are showing will not open the front panel. If you are trying to run the VI asynchronously use the Start Asynchronous Call function is the easiest way.

Is it very reproducable? Can you make it crash every time? If so this makes life a little easier. I'd recommend disabling large parts of the code and see how it effects the crashing. This can help narrow down what code is causing the issue. If I had to guess I would say it is likely a bad DLL call, or a .Net function that isn't being used properly.

Nope, I've never used more then one event structure in a single VI. That being said hearing how others use it it doesn't sound like a horrible situation as long as you know what you are doing. There are pitfalls that new developers will likely get caught in, but I feel like there are plenty of places that LabVIEW allows you to shoot your self in the foot. So while it wouldn't affect my development at the moment, put my vote to "This should probably just stay the way it is"

I don't know if I fully understand what you are talking about. You have a look up table so I get the feeling you aren't reading an analog channel but instead are using that table as an output but your topic clearly states "measurement" Please also try to use terms that are more appropriate. The "Refresh Rate" can mean many things. If instead you said your output rate, or sampling rate then it would be more clear what is going on. We will need more information to understand what you are doing. Post some code of what you are doing as well if you can.

XControls are wonkey at best. Every time I try to make one I find my self coding around issues with them. I'm not saying this is one or not I just haven't had good experience with them. One time I remember having a system Ring control that I had some difficulty with for updating items, and allowing a right click menu. I can't remember what didn't work about it but as soon as I replaced it with a classic Ring it all worked fine. I posted this issue at NI when I had it but it didn't go anywhere.

Did you mean to attach something to that post?

I agree but there has to be a limit right? When LabVIEW was first developed maybe 32x32 was a good size. Maybe they didn't have very complex sub VIs needing a bunch of inputs and outputs. If you do want another way to view a subVI you can right click it and choose to un-check View as Icon. Then you can resize the subVI (dragging down) and your terminals will be displayed in a larger manner.

I believe the built in function mje was referring to is the graph cursors. Right click the graph go to Visible Items and choose cursors. Then you can make a cursor that will snap to existing points. There are several examples if you search the example finder. One is called Programatically Control Cursors but I have seen some other's that work better and can and and and point out the maximum value of a graph. Again if these functions don't meet your needs you can just draw a picture and put it on top of the plot using the property nodes of the graph it self.

How about keeping track of which database connections have been made. Then when a Mouse Down event happens on the string control disconnect any database connections that are open. If none are open then do nothing. If one was open from the last session then close it.

I like how you actually handle window resize properly where a very large majority of the custom probes do not. I also like the ms timer column. Have you ever thought about having a dt column? Or replacing the ms timer with a dt column? I only ask because it isn't too important to me that case A was handled at 3946013 and case B was handled at 3959319. What is useful is how much time went between the two cases, which can tell me how long it took to execute case A. I can of course get that information if I do math but it would be nicer if the probe did it for me. At the moment I'm using VIBox Probes by SAPHIR which has a History Probe for strings. This has a few features yours doesn't like being able to set the history length to a number (not window size), and being able to pause based on the string value. One feature neither you nor the History Probe has that I've thought about is the ability to Pause the probe. I haven't needed to use this feature yet so maybe it is stupid, but I wonder if it would be useful if you could press a button and then have it no longer update the probe with new values but have the VI run like normal. My use case is what if my VI is running like normal, and then I see some case happen that wasn't expected. The probe will overwrite its values if the VI keeps running and handling cases but I may want to see a snapshot of the cases that were handled to figure out what led up to going into that case.

Yup that was what I was thinking. Possibly a ring with the string values in a look up table or something so you don't need to read the string values with a property node every time you want to know which item was selected. Although that gets me thinking. So with an Enum we can read what all the possible values are using the OpenG Get Strings from Enum function. Is it not possible to read the string values of a ring control the same way because that information is not contained in the wire, only the numeric representation is?

When ever I think comedy and LabVIEW/Technology, the LAVA Lounge is a good place for it. Over at NI they have the Break Point board: http://forums.ni.com/t5/BreakPoint/bd-p/BreakPoint

Yup, I'd say this is one of those "Everyone makes that mistake the first time" type is situations. I just want to know if my number is NaN so I wire it to an equal and put a constant of NaN right? Nope use the primitive under the comparison palette "Not a Number/Path/Refnum"

I have not used it on a real project yet, but what work I have done with it appears to show it as being stable. I also agree that we probably won't be using it on large projects until the SP1 release. We also have some Veristand guys and we try to all upgrade at once. Veristand 2013 came out a few weeks ago so hopefully we can all just wait until the SP1 release of LabVIEW and upgrade together.

Okay maybe this mythical cluster never really existed and it was a dream. I must have been thinking of the Left and Top cluster I already posted, and can be found in the thread you linked to.

Nope, also 1px on each border.

This is still not the borderless one posted by AQ years ago. This is also a 1px border. If you put a numeric in the cluster then the cluster in an array, the size of the array will be 2 pixels larger in width and height when compared to just an array of the numeric. The cluster I posted will be 1 pixel larger in height and width. The one originally posted would be the exact same size because it was truly borerless.

I don't remember if there were other ways to select the cluster and move it. You may have been able to double click it from the block diagram, get its selection, then use the arrow keys to move around I don't remember if that worked or not. Even if it did work any engineer taking over a project would get quite frustrated when they couldn't find out a simple thing like "Is this an array or a cluster?" and "how do I select the stupid thing?"

Okay so I don't have the original post of the 0px cluster. But to me it was a little useless because it was 0px and you couldn't actually click it to select it. This broke work flow every time you needed to move it on the front panel. But what I do have that I don't see here is a 0.5px cluster. It has 1px on the left and top border, but 0px on the right and bottom. This means you cannot select the cluster by clicking the right or bottom, only on the left and top. Top Left Border Only Cluster.ctl