hooovahh

This is the only thing I can think of that would work as well but it probably is very error prone. Lets say your control size is 100px high according to the Housing Size property. That will likely include the borders, and any small spaces around the slider, and possibly things like the label/caption and digital display. These things will need to be taken into account and the range from min to max on the control and may not be very accurate.

Just ran into this one personally. Not sure what the offending VI is but replacing the one in the vi.lib with the one you posted fixed it. Can't wait until SP1.

Please do not double post. If you are unhappy with your first post you are welcome to edit it, or us the Report to Moderator button to get posts edited or deleted. On topic could you post some code of what you have. It's still a little difficult knowing what you want. You are saying what method can you use to move an item that the user selects up or down? Okay so I think I found what you were talking about, and I think I have a solution. I don't know if there is a better way of using it, but what it will do is find the parent of the current tag, then find all children under that parent. Then find within that list of children, where does our current tag exist. Then move that position. Alternatively you could allow the user to click and drag to move items around, but I admit that getting this to work the way you want can be a pain. Tree Move Item Up.vi

A user complained that these links are dead. I don't have the original VI but I implemented some code that is similar in functionality. You click cells in a Table, or Multicolumn Listbox and the color changes. There is also a Clear Color button that changes all cells back to white. Saved in 2011. This cannot be done with an array control because the only thing that can be different between elements of an array is the value. If you try to set the background color it will set it for all elements in the array not just the one cell. Color Cells Mouse Click.vi

I don't fully understand the situation. You have a listbox that the user can edit and you want to know when they make an entry that is already an entry and prevent it? OpenG array tools has Remove Duplicates from 1D array and this can help determine if there are duplicates. If you can post a simplified version of what you are doing and I think we can help.

If taskkill doesn't work you have bigger problems. I'm guessing you aren't performing a taskkill but instead are politely asking the application to exit. And if it isn't responding it won't exit. In task manager go to the Processes tab, find your application and click End Process. This is a taskkill and will remove the application from memory. If you are on the Applications tab and try End Task this does not perform a taskkill but instead tries to close the application more gracefully and may take longer or not work at all. Again as discussed in this thread task killing an application is not something to be taken lightly, and under the right circumstances may have no ill effects. Generally this is only used when an application isn't responding and you don't want to reboot your computer to get back to a usable state.

I agree, I was just trying to give the most complete answer.

This is true, and I would also recommend an actual database, but that doesn't mean you can't do it with TDMS. I've seen someone use TDMS as their configuration file format, replacing INI files. Of course that was crazy and it didn't catch on but it could be done.

The shortcuts are in the LabVIEW.ini (as you have discovered) and are under the key QuickDropDiagramShortcuts and QuickDropPanelShortcuts. Copying just these items to the new LabVIEW.ini will bring along the shortcuts. Internally we have a package with added quickdrop functions. Packages can have a PostInstall VI called and my post install VI will add these lines to the current LabVIEW.ini.

The original post can clarify but I think the complaint is that when the VI from the tools menu is ran from the project explorer, the App.MenuLaunchApp doesn't return the application instance that the project is using.

Please do not make duplicate posts. If you make a post and want it moved, use the Report to Moderator button. Sorry I don't have anything to add to the issue you are having.

The first method that comes to mind is using Windows DLL calls to set the parent window as the LabVIEW front panel, and the child window as your C# application. This will work but looks a little ugly because you will have the title bar of your C# program inside your front panel and looks unnatural. I did a quick search and found this post that I think has some code on setting parent/child windows. http://forums.ni.com/t5/LabVIEW/Set-Parent-window-using-User32-at-lv7-1/td-p/1950469 To do this you'd need the HWND of both the parent and child windows. I'm betting there is a nicer way to do this and I hope someone else answers because admittedly this feels like a hack method.

I'm not a DataFinder expert so what I say may not be accurate. DataFinder does not index the values of signals. At least with TDMS data you cannot perform a search on if a channel has a value that is in some range. You can only perform searches on the properties of the data. In TDMS this is easy because the file, groups, and channels have properties and searching based on if a property of a file is in range is easy. I assume for DataFinder to index the properties of a CSV file you must write a data plugin which allows DataFinder to know what properties are. Let say your first row of a CSV is property names, and the second row is the values. This is something that DataFinder just can't know without you telling it and you do that by making your own plugin. I've never made a plugin and wouldn't know where to start but my guess is this is the only way for DataFinder to allow you to find information on the file. I think the only exception to this is the file name, path, and date. This appears to be something that DataFinder infers without needing a custom plugin being made.

I had something similar happen. Before today I have never ran a tools menu item from the project window not that I think it is a bad idea. I have a tool that takes an array of string and makes an enum based on it. It will make it in the application instance that the VI calling it is in. When I run it from a VI it works as expected making it part of the project that VI is in. But similar to your issue when I run it on the project window it makes the enum not putting it in the project instance. Not sure if this is expected or not just wanted to let you know you aren't crazy. By the way I see this in 2012 SP1.

Please do not create duplicate posts asking the same thing. If this was a mistake then don't worry about it. Please contact NI directly with this type of question. We do not have the tools to help understand what happened but NI does.

Not specifically LabVIEW but I'm a fan of DisplayFusion. I've seen alot of LabVIEW developers use multi-monitor setups and having quick shortcuts to moves windows between monitors is nice along with multi-taskbars. Custom Quick Drop items. Several of the more popular ones. Custom scripting functions that I put in the Tools menu. Simple things like Array to Enum, and Configure SVN with my settings, or setup LabVIEW.ini a specific way. I don't think I've ever had just a single version of LabVIEW installed on my main development machine. Things like the custom LabVIEW icons help differentiate between versions. Abort All VIs function. Variant Probe. WinAPI functions. How much time has been lost by accidentally opening a 2011 project in 2012, and clicking save all, only to realize it later. SCC helps but it can still be a problem. I use a updated program similar to my old LabVIEW Tray Launcher which high jacks the execution of .vi files. Also adds an Abort All VIs, Launch LabVIEW (version specific), and Kill LabVIEW (version specific).

Some prefer one development style over the other. Some see right click menus a break in the development flow slowing down the developer. If I know the function names I want to use, traversing through the palette takes alot longer then it does just typing it in quick drop. I did use the RCF and know it can be used for things that seem clunky in QD. Honestly I don't know which I prefer. I think I can adapt to either given enough time. But when it comes down to it using an official feature that isn't quite perfect, is better in my opinion, then using a more cumbersome method with more flexibility. Often times I see NI develop some new thing that obviously gets inspiration from the community (the Icon Editor is one). When the NI method gets good enough we as a community start to abandon the older way of doing stuff, with the knowledge that we no longer need to support and maintain a project, and instead NI has sorta taken over it. This then helps the community focus on other cool new projects that NI hasn't tackled yet. And so the cycle of ever improving software development continues.

For the data to be usable you have to know what it is at some point. Sure you can say you have a variant but if I'm going to get an average of a variant I need to know how to interpret the data. Should this be a string, that is then transformed into a numeric? Or is it a boolean and should be treated as a bit? Or is this an enum which corresponds to some value? If you don't know what the data type is just yet, but you know that in two places the data type is the same, I highly recommend a type def. Using the OpenG Write Key (Variant) and Read Key (Variant) under the Variant Configuration palette I can write and read any thing to a file. Quite nice but at some point I'm going to need to turn that variant into a usable data type. Variants are great for a transport layer where we don't really care what the data is we just send it and then the place that receives it needs to convert the variant back to something usable. The Write and Read Key can be thought of as the transport layer where we send some data as a variant to a file, then we receive it back when we read it. For it to work properly ideally the write and read have the same data type. If these are both linked to the same type def, then that means updating the one type def will update both the write and the read to use the new data type. We may not know that data at design time, but we know what ever we write, we are also going to want to read and the data had better be the same. I've seen variants used in Queues, User Events, TCPIP, File I/O, FIFO, and several other transport layers. These all work great because they don't care what they are given they just send the bytes and who ever gets the bytes is responsible for getting usable data out of it. If you aren't dealing with a transport layer, and instead are just passing data around a VI but don't know what it is yet, there isn't really a need to use a variant, just stick with the type def and update it when needed.

Often times I find myself being distracted by the thoughts that the work I am doing would be faster if I just did it instead of spending time scripting it. There are a few times where I spent a long time working on some scripting tools that I figured would never be used or only be used once or twice. I was quite delighted to find that not only I had been using these tools, but other developers have been. Now these tools are part of my companies application building process and saving tons of time. They aren't all like this of course but I know now that my intuition on if a scripting function is worth it or not can be incorrect at first. Only time will tell if it is worth it.

This isn't a working solution but it might help. I would use 7-zip if the other native zip utilities don't like .GZ. .GZ is not a zip but many zipping tools support it. http://lavag.org/topic/16513-can-we-prevent-zlib-compress-dir-from-replacing-accented-characters/#entry101116 There someone asked about zipping a folder of files in a way that wasn't supported so I suggested using 7-zip in a command line to get the function needed. You can look at the code and modify it to extract the .GZ to a temp location and then you can read the files from there.

Post some code. I can't be sure the data type you are working with, or what you are trying based on your description but I think I know a way to go from the LabVIEW image data type to a system stream image in .NET.

I don't know why that idea doesn't have more kudos. Are people not using more quick drop items then what comes with LabVIEW? As soon as you start installing some of the ones posted on NI's site, or making your own, you realize quickly that QD only works well if you have very few functions. As soon as you have more then say 5 you start to run out of shortcuts, and only having one modifier key (the shift key) is also quite limiting. If QD is going to grow it needs to be overhauled. Not necessarily in the way TST suggested but in some way.

Do a repair install of LabVEW (or DSC). Go to Add Remove Programs, choose NI and modify it. Then a menu will come up with all the NI software installed. Choose LabVIEW and click repair. This will reinstall all the files needed to run LabVIEW. Note that you will need the LabVIEW CD/DVD as a source.

Curious what issues you've seen. I'd say we inline 80% or so of our reuse library and haven't seen issues in 2011, 2012, or 2013 as a result. What issues should we look for?

Let me save you the time. At the moment there is no easy way to do what you want. Well there is and it is keeping track of it the way you suggested. I've seen some test VI somewhere, where it took a print screen of the block diagram, then did vision checking to determine if the run button was running, or reserved to be running. That is the methods people have tried, in an attempt to do what you want programatically. Sorry.