Yair

QUOTE(jdunham @ Sep 3 2007, 11:37 AM) I'm sorry, but I don't see how this can be used. As mentioned in the original post, you can get hundreds of Value Change events from a simple move of the slide. In your example, if you get a hundred events, it would take 5 seconds before the code finishes executing for all the values which are mid-way, when usually only the last value is needed. That was the point demonstrated in my two methods.

Two new (related?) important points I thought about - Will this work fine across 8.x application instances? If the VI is running in the background, it means that when you close all your other VIs, the getting started window will not appear because there is still a VI in memory, so LabVIEW would just seem to disappear. One way around this is to run this process as a separate executable, but that requires opening VI server access and would cause troubles with multiple concurrent LV versions. Another way is to open and close the VI each time, but since we can't create a permanent menu shortcut, I don't see how to do that other than attempting to include the VI in the top level of the palettes, which would require a few mouse clicks. Does anyone have other suggestions or ways to make these usable?

I haven't read this deeply, and I'm definitely not an LVOOP guru, but it was my understanding that the class data type is private - it can not be used from anywhere outside the class. That would seem to me to be a likely reason why you can't do this.

Stephen, I personally think most of those features are great, except for the snapping to the grid, which I don't like. Maybe I should try using it for a while and see how it works.

QUOTE(NormKirchner @ Sep 2 2007, 09:10 PM) It is the one I linked to earlier from the NI forums. It has a bunch of VIs and a help file.

You should note that the key is here is not opening the VI. That's relatively simple. The key is getting the list of all the VIs and primitives (and controls?) in the palettes. At the moment, I used the list from the New VI Object primitive in LV 7.0, but that is not a solution. To demonstrate this tool more efficiently, here is a better version. As you can see, the polling is not that bad. Instructions: Run the VI. It should auto-hide. From the BD of any other VI, press Shift+Q. That should open it (although it would actually open regardless of where you are. That's one of the problems with this). Start typing the name of function until you get the one you want (e.g. TCP Close). Press Enter to drop the function. Repeat for as many functions as needed. One issue is that when you first run it, it takes a few seconds before it allows you to drop the function, but I don't think that can be worked around. As said, there are many improvements which could be made, but I don't want to do anything before I know I can enumerate the palettes. Can anyone with LV 8.0 try to backsave the palette API linked to in the first post?

Staying until the end of NIWeek has its advantages: At the end of the very last session in the last day, frequent LAVA poster Darren showed a demo of a potential time saving tool he was thinking about for a future LabVIEW version. The tool allows you to use a simple key combo which will cause a small pop up to appear. You type the name (or keyword) of the function you want it use, it uses autocomplete and when you click enter you can immediately drop it in your code. This will allow you to drop any VI from the palettes in your code in a few key clicks without having to dig it out from the palette. The problem is that I was impatient, so I wanted this now. So, while waiting for my flight the next day, I coded up a quick example (7.0) to see how it would work, and it is a very simple example - type the name of a function\VI in the string and press Enter. It will allow you to drop that function\control in the BD\FP of any VI. There are some issues with it, however, and I want opinions. Dropping the function is easy. There is a method for doing that from the palettes. The hardest part is probably parsing the potential names. Different LV versions with different toolkits and modules installed will have different VIs. Also, the user.lib VIs are also part of this list. The most promising solution looks like the palette API, but it remains to be seen whether this can be backsaved to 7.x (which is what I want). Another problem is that parsing this will probably take time. I think that this will need to be a step which the users perform manually when they want to update the list by calling a specific VI which will do this. Another problem is monitoring this. This can't be done using LV events. I was thinking of using polling and trying to load the tool at LV startup and having it run in the background all the time. I believe this is relatively simple using some callbacks which LV has, but I need to check if they work with 8.x. This could obviously interfere with what users do, but I think it's the only viable way. The method used to do this ignores whether or not the VI with focus is in edit mode. It basically allows to drop in any VI which is in edit mode. A nice addition would probably be using autocomplete in the middle of a word and using keywords to stand for VIs, but that would require a more complicated algorithm than this quick example. At the moment, this is relatively similar to the search window. What would be its advantages over it? What do people think about all this? Are there alternative suggestions?

QUOTE(Michael_Aivaliotis @ Sep 1 2007, 09:42 AM) Now I remember why I didn't use this the last time I saw it - it requires .NET callbacks, which aren't supported in LV 7.0.

I'm definitely not the most appropriate person to respond to this as I haven't done any LVOOP either and I never really had to deal with indexed images, so I don't really understand the need for this. A couple of notes I will make, however: It would make it easier to understand which class is which if they had different icons. As it is, when all the VIs have the same icon, you just get the feeling you're opening the same VI over and over. Did you save this on a different drive than your C drive? It looks for the 8.2 vi.lib, which means it did not save it as a logical path and I believe that's the usual reason for that.

QUOTE(JeffPhillips @ Aug 31 2007, 10:31 PM) Hey, some of these look nice and I haven't seen them before (e.g. the data types one). Thanks, Jeff. P.S. Welcome to LAVA, how about trying to convince some more NI personnel to post here?

Here are two efficient methods: http://forums.lavag.org/index.php?act=attach&type=post&id=6827 The value change event in the bottom loop sets the timeout to something (let's say 50 ms). When the last event happens, the timeout expires and you can execute your code. The top one relies on the terminal having the updated value immediately.

QUOTE(dsaunders @ Aug 31 2007, 05:56 PM) Well, I still use LV 7.0 (which is great), so my reasons in this are slightly more egotistical, because I could potentially use this functionality for something specific.

QUOTE(Ben @ Aug 31 2007, 04:18 PM) And Dave had to go and ruin our streak.

No, I can't justify that "two versions" number, especially when drivers don't always come out sync'ed to a new LV version, but that's the number I seem to remember. Examples - LV 8.0 included Fieldpoint 5 which removed support for LV 6.1. DAQmx 8.3 (I think) and above (as you mentioned) can only be used with LV 7.1 and above. I don't know about VISA.

QUOTE(Q^Q @ Aug 31 2007, 10:37 AM) I understand you created it, so you would probably be the best person to ask - will it work in LV 7.x (which is what the original posted seems to have)? I don't have 8.0, so I can't try to open it and backsave.

In the past I used an ActiveX object NI built using CVI for doing the tray icon thing. The ZIP archive here includes some VIs for interacting with this object.

Just to make it clear - I also have it on, but I just don't snap to it. I think it's much better to have it on then off because it also allows you to distinguish between locked\running VIs and idle VIs and because it shows you the 0 lines. By the way, for those who don't know it, holding shift down while dragging with the mouse moves the object in a straight line. Holding shift down while using the arrow keys moves the objects in larger increments.

I like the fact that you were able to work around this. :thumbup: The two main issues I can see with this approach is that you would need to parse all the diagrams in the VI in order to find the subVI, not just the main diagram, and that it relies on the name, which could be duplicate (although in most cases people would probably not use duplicate names).

The easiest way to check the IP address is to use String to IP followed by IP to String, both from the TCP palette. Run in it a loop until you get the address. I'm not sure what will happen when the cable is disconnected, but you will probably get an empty string, 127.0.0.1 or 0.0.0.0. I suggest you try and see if that helps.

QUOTE(alfa @ Aug 30 2007, 11:22 AM) OK, I know I'm going to regret this, but I have to ask - what is alfa's third law of Evolution? Does it state that after living for 12 years in one country, your older country will look different?

From the past I can tell you that NI usually supports 2 versions back with its hardware drivers (that would be 8.2 and 8.0). Since you can only have one version of a hardware driver at any given point, installing the new one removes support for the old LV version. I saw this with FieldPoint and DAQmx. The solution would probably be to have a dedicated machine for the old LV version or to use virtual machines. Another option is to remain with the old version of the hardware driver, which I believe should work with 8.5.

It's happening again (IE 6.1).

I personally can't stand the default snap to grid option. I much prefer using the align and distribute menus after I placed my control on the FP.

QUOTE(Aristos Queue @ Aug 29 2007, 04:24 AM) What happened to Alice? Did she finally retire? http://xkcd.com/177/' target="_blank">

I was thinking of SCC as well, although that doesn't conform to the exact specs and it requires some overhead. However, if this is for your own code, you should definitely use it. We also use SVN with TSVN for the interface and the greatest benefit so far is the ease of synchronization. Getting the changes other developers made requires two (yes, two) mouse clicks and waiting a few seconds. QUOTE(Aristos Queue @ Aug 29 2007, 04:50 PM) It probably would, but it would depend on what your target audience is. I'm fairly sure Brian Powell's presentation about NI's software engineering practices and Jim Kring's presentation about commercial software apps discussed this topic (I'm sure Jim can correct me if I'm wrong).