A LabVIEW tool suggestion

[Yair]

QUOTE(Val Brown @ Sep 6 2007, 11:48 PM)

...I LOVE the support that we get here ---- [sounds of applause] -- but I don't count on it for distros. I want someone or some entity that is ultimately responsible and actionable if things go south.

...

I want to be able to walk up to ANY system and simply BE ABLE TO USE IT.

...

I'm all for customizability but I do not want to have to rely on it for me to be able to do my work.

NI may be responsible, but I doubt it is actionable. I wouldn't be surprised if the LabVIEW license says NI is not responsible for damages caused to you if LV did not work the way you expect it to.

In any case, you should note that these are not pieces of code - they are edit time tools and you only use them to create your code. Using Ctrl+N changes the functionality which is why I don't like it, but as David said, this is a decision for the individual developer - I definitely don't want anyone walking up to MY system and using it. If they do it without me around and are surprised that Ctrl+N gives them a dialog, that's not something I care about.

I agree that too much customizing can be a bad thing, but this should not prevent you from doing your work - you don't have to install it and even if you do, the original behavior still exists. It would just require another click on Ctrl+N.

David, you should note that NI already provides the option #2 you gave - things like the Tunnel Wiring Wizard do not override existing tools - they extend the IDE in a very simple way. I would like it if we could have done that with keyboard shortcuts (since I don't want to have to click the mouse twice and then start typing), but I think the demo'ed method is reasonable.

IN ANY CASE, this is hijacking the thread. If you want to discuss this more, I suggest you start a new thread.

What I want here is VIs, ideas or suggestions for efficient algorithms for handling the searching.

[JDave]

QUOTE(yen @ Sep 7 2007, 06:20 AM)

David, you should note that NI already provides the option #2 you gave - things like the Tunnel Wiring Wizard do not override existing tools - they extend the IDE in a very simple way. I would like it if we could have done that with keyboard shortcuts (since I don't want to have to click the mouse twice and then start typing), but I think the demo'ed method is reasonable.

Yes, some of the hooks are there. Some of those hooks are private, some more are missing. By option #2, I meant public supported extensibility.

QUOTE(yen @ Sep 7 2007, 06:20 AM)

IN ANY CASE, this is hijacking the thread. If you want to discuss this more, I suggest you start a new thread.

What I want here is VIs, ideas or suggestions for efficient algorithms for handling the searching.

To repent for continuing to hijack the thread (Sorry ) , I offer some thoughts on the true thread topic.

I think that using this type of tool to search for VIs or functions would simply duplicate the Search functionality that already exists. If I were to use a tool like this, it would be to quickly drop my commonly used functions. This would mean that I would want aliases that I could enter and done. If I wanted a for loop, I would type Ctrl+N, f o r, then Enter.

Perhaps you could primarily search in a list of aliases the user has built up. Secondarily if the user wants to search, then you could load the entire list and auto-complete or whatever else would help.

[Darren]

Ok, hopefully this will make things easier. The menu item I hijacked was Tools > Measurement and Automation Explorer. I don't know what version of LabVIEW this option was introduced in. Probably 8.0 if I had to guess. Anyway, I never use this menu option, so it was a good candidate for my prototype. This menu option launches project\max.llb\MAX Launcher.vi. If you replace that VI with your own VI, then whatever key combination is assigned to Tools > Measurement and Automation Explorer will launch your VI instead. In my case, it launches my Quick Drop prototype. I changed the key assignment (with Tools > Options > Menu Shortcuts) to Ctrl-Space which is easy for me to type with my left hand, and isn't currently assigned to anything in LabVIEW on Windows.

Hope that helps,

-D

[JDave]

QUOTE(Darren @ Sep 7 2007, 08:45 PM)

Ok, hopefully this will make things easier. The menu item I hijacked was Tools > Measurement and Automation Explorer. I don't know what version of LabVIEW this option was introduced in. Probably 8.0 if I had to guess. Anyway, I never use this menu option, so it was a good candidate for my prototype. This menu option launches project\max.llb\MAX Launcher.vi. If you replace that VI with your own VI, then whatever key combination is assigned to Tools > Measurement and Automation Explorer will launch your VI instead. In my case, it launches my Quick Drop prototype. I changed the key assignment (with Tools > Options > Menu Shortcuts) to Ctrl-Space which is easy for me to type with my left hand, and isn't currently assigned to anything in LabVIEW on Windows.

Were you able to change the menu item text in the Tools menu? I couldn't

[Yair]

QUOTE(dsaunders @ Sep 7 2007, 06:12 PM)

Yes, some of the hooks are there. Some of those hooks are private, some more are missing. By option #2, I meant public supported extensibility.

I agree that it would be nice if NI added a documented interface for this, but I can see why they don't do it (e.g. what happens if some creates a tool called "Code Capture Tool" and then NI comes out a version later with a tool of the same name? One of them will have to stop working. I assume NI would actually have the same problem now with key combos if you can edit them for the LabVIEW environment).

QUOTE

I think that using this type of tool to search for VIs or functions would simply duplicate the Search functionality that already exists. If I were to use a tool like this, it would be to quickly drop my commonly used functions. This would mean that I would want aliases that I could enter and done. If I wanted a for loop, I would type

Ctrl+N

,

f o r

, then

Enter

.

Perhaps you could primarily search in a list of aliases the user has built up. Secondarily if the user wants to search, then you could load the entire list and auto-complete or whatever else would help.

I believe 8.2 and above already has a palette for your favorite VIs. This might actually be more useful in cases where you need to use functions like "First Call?" or "TCP Open". Today, to use TCP Open in LV 8.x, you need to go (roughly) into Programming>Connectivity>Protocols>TCP. With this tool, you just go Ctrl+N->"TC"->Tab->"O"->Enter.

I agree that the most likely usable interface is similar to the search results window, where you get a list of potential options. I believe I even mentioned that this was similar to the search option in the original post and asked for comments on that.

My main problem with the needed algorithm is that I also want (potentially) an option to start with a larger list and remove options from it and to maybe group functions (e.g. tookit VIs) and those would make it significantly more complicated.

QUOTE(Darren @ Sep 8 2007, 06:45 AM)

Ok, hopefully this will make things easier. The menu item I hijacked was Tools > Measurement and Automation Explorer.

Darren, unfortunately I live in the real world where people do use MAX. I sometimes even open it from the Tools menu. In the real world some people also use 7.0 where there are no keyboard shortcuts.

[Yair]

OK, here's a much better version (7.0) which I've been using for a while. I think it's really great and it has been immensly useful when using functions like "First Call?" - dropping it takes me less than two seconds now.

Essentially, it's similar to the way the search function works, but it has a few significant advantages:

1. It remembers your favorites.
   
2. It's easier to open (Ctrl+N anywhere).
   
3. It's easier to use (up\down arrows automatically move through the matches, Enter automatically drops the selected function).
   
4. It allows searching for multiple matches (e.g. "tc pe" will match "TCP Open").
   
5. It does it cleverly (a match at the beginning of a word is prefered and earlier words are prefered as well, so "bun" will get you "bundle by name" first even if you used "unbundle by name" more.
   
6. It allows using aliases (e.g. you can use "mod" or "qnr" instead of "Quotient & Remainder"). I added a couple of these aliases manually to the files I uploaded, which include an incomplete list of primitives and OpenG VIs.
   

The code is ugly and the preference algorithm sucks, but this demo'es this very nicely.

What I want is feedback and some ideas:

The main problem for me is that to handle the aliases we need to give each function an ID. This means we need to manage the IDs somehow.

To be honest, I have no idea how to do this. We could use GUIDs, but I don't really like the idea.

The most practical idea I had was setting up a web server which would assign you with a range of IDs for your company when you create the IDs file, but that would require a web server.

Other than that, it would probably need to have different files and store the settings for different LV versions separately.

It would also need a UI to allow easily adding and removing aliases, but I'm not at that stage yet.

[Chris Davis]

I'm going to reccomend this tool for a friend at work who is learning LabVIEW. He is a big fan of keyboard shortcuts, for physical reasons, and LabVIEWs (mostly) mouse driven is difficult for him to manage.

[Yair]

I'm actually not sure whether this will be useful for new users. You basically have to know the function names (or configured aliases) to use this tool. I think it's actually much more useful for exprienced users who want to save quite a few mouse clicks and quite a bit of time.

[crelf]

So when are you sbumitting this to the LAVAcr?

[Yair]

I didn't see any great positive reaction or helpful suggestions, and I've been quite busy, so I put it aside for a while.

I still use this all the time and it's great, but as I said, it has some issues.

The single biggest issue is managing the names and aliases and it has several sub-issues:

• Getting the item names in versions below 8. At the moment I can think of four options:
  Build them manually (not really an option).
  Hack the mnu files. I gave it a quick look and it doesn't look easy for primitives.
  Do the palettes in 8.x and find a way to change whatever needs changing.
  See if the palette API can handle mnu files from 7.x.
  
• How to generate unique and consistent IDs for functions?
  If the IDs are not unique, some of the functions will be in the list, but selecting them will drop the other function.
  We could generate a unique list for each computer, but then the lists will not be exportable between computers, unless we come up with a way of preparing them for export. That might actually be the most practical idea.
  
• One option I thought about was using namespaced strings instead of I32, but I'm not sure how that will affect performance and it's still not guranteed to be unique and consistent.
  
• How to manage function names which change between versions. I don't have an example off hand, but I have seen NI VIs and primitives which had their name changed. This will only need to be changed in one place (where the ID is), but the key would be identifying it. Maybe scan the entire previous list when upgrading and display all entries which don't match?
  
• And speaking of the previous version list, I still haven't thought about a useful structure for managing different versions and toolkits. We will probably need a hierarchy of separate files and folders.
  
• I haven't thought about a useful UI for managing the aliases (adding, changing, deleting).
  

[LAVA 1.0 Content]

QUOTE(Yen @ Nov 8 2007, 07:06 PM)

I didn't see any great positive reaction or helpful suggestions, and I've been quite busy, so I put it aside for a while.

I still use this all the time and it's great, but as I said, it has some issues.

The single biggest issue is managing the names and aliases and it has several sub-issues:

• Getting the item names in versions below 8. At the moment I can think of four options:
  Build them manually (not really an option).
  Hack the mnu files. I gave it a quick look and it doesn't look easy for primitives.
  Do the palettes in 8.x and find a way to change whatever needs changing.
  See if the palette API can handle mnu files from 7.x.
  
• How to generate unique and consistent IDs for functions?
  If the IDs are not unique, some of the functions will be in the list, but selecting them will drop the other function.
  We could generate a unique list for each computer, but then the lists will not be exportable between computers, unless we come up with a way of preparing them for export. That might actually be the most practical idea.
  
• One option I thought about was using namespaced strings instead of I32, but I'm not sure how that will affect performance and it's still not guranteed to be unique and consistent.
  
• How to manage function names which change between versions. I don't have an example off hand, but I have seen NI VIs and primitives which had their name changed. This will only need to be changed in one place (where the ID is), but the key would be identifying it. Maybe scan the entire previous list when upgrading and display all entries which don't match?
  
• And speaking of the previous version list, I still haven't thought about a useful structure for managing different versions and toolkits. We will probably need a hierarchy of separate files and folders.
  
• I haven't thought about a useful UI for managing the aliases (adding, changing, deleting).
  

Hi Yen,

I will install your tool and test it "roar", I mean without looking into the code, it probably the most appropriate way to give a feedback on "does it help ?"

I'll let you know in this thread after christmas.

Thanks for sharing this tool.

[Yair]

I did get back to this recently and finally found a decent way of handling the aliases issue. I also cleaned up the code so that it looks much better now and started working on the UI for handling aliases. Hopefully I'll post a better version soon.

[Rolf Kalbermatter]

QUOTE(Yen @ Nov 8 2007, 01:06 PM)

I didn't see any great positive reaction or helpful suggestions, and I've been quite busy, so I put it aside for a while.

I still use this all the time and it's great, but as I said, it has some issues.

The single biggest issue is managing the names and aliases and it has several sub-issues:

• Getting the item names in versions below 8. At the moment I can think of four options:
  Build them manually (not really an option).
  Hack the mnu files. I gave it a quick look and it doesn't look easy for primitives.
  Do the palettes in 8.x and find a way to change whatever needs changing.
  See if the palette API can handle mnu files from 7.x
  

If I only had more time! I hacked once into these files and once you understand the Macintosh like resource format basics (same as used for VIs, LLBs and most other pre-XML LabVIEW file formats) it's not that difficult to get at the info. Problem is my hacks were never really getting out of proof of concept state with the exception of the VI Library shell extension, but that was entirely written in C.

But it reminds me that LabVIEW itself exports a Resource Manager API and it should be not to difficult to target that one with a small VI library. I think it is in fact what the palette API does too. From there figuring out the structure of the palette resources won't be to difficult anymore.

Rolf Kalbermatter

[Yair]

My brief look at those seemed to indicate that the mnu links to primitive by pointing to some resource (i.e. the name of the primitive is not found in the mnu file). Since this is not at all my area of expertise I didn't look any further.

QUOTE(rolfk @ Dec 19 2007, 02:06 PM)

But it reminds me that LabVIEW itself exports a Resource Manager API and it should be not to difficult to target that one with a small VI library. I think it is in fact what the palette API does too. From there figuring out the structure of the palette resources won't be to difficult anymore.

Since I've made that post I have had a chance to look at the palette API and unfortunately even that does not return the data for most primitives in the palettes. There are a few which seem to have an explicit name set for exporting, which is shown in the palette API, but most are simply not named.

Luckily, the new VI object ring holds the names for most primitives and the rest could be added by hand, but I would like a way to be able to easily parse palettes for VIs and unfortunately, the palette API can't be backsaved from 8.0. Does the resource manager API you mentioned work before 8.x? Can you provide some pointers (functions and their definition). The only thing I really need is to recursively list palettes and the titles of the VIs they call.

At the moment, I figured that as a workaround this could be done by parsing the actual directories, but that's a really bad solution.

[Rolf Kalbermatter]

QUOTE(Yen @ Dec 19 2007, 03:15 PM)

Luckily, the new VI object ring holds the names for most primitives and the rest could be added by hand, but I would like a way to be able to easily parse palettes for VIs and unfortunately, the palette API can't be backsaved from 8.0. Does the resource manager API you mentioned work before 8.x? Can you provide some pointers (functions and their definition). The only thing I really need is to recursively list palettes and the titles of the VIs they call.

At the moment, I figured that as a workaround this could be done by parsing the actual directories, but that's a really bad solution.

Well, yen, I think you might be right that the built in nodes may not really have a string name in the palette menu, but only a resource identifier, that points back into LabVIEW (or one of the .rsc files in the resources directory). It's a long time since I looked into this. I'll see what I can do in terms of getting the resource information in a more user friendly way into LabVIEW. But I need to search that stuff and most probably clean it up a bit.

Rolf Kalbermatter

[Yair]

Thanks. Don't bother cleaning it up too much unless it's really necessary. I will probably make some modifications to match my needs.

[Jim Kring]

Yen,

Here are some suggestions:

First, I wouldn't override the File>>New VI operation. This is annoying, in my opinion. I would add an option to the Tools menu to start up the tool and have it run behind the scenes waiting on a configurable key combination.

Second, I would take a look at Launchy, a really cool keystroke app launcher for Windows. It's very well designed and doesn't get into the way.

After you press the magic key combo to activate it, you see a text input box.

As you type, it shows you the one item that it guesses you want to launch.

If you pause your typing for longer than some threshold (a few seconds), it shows you a list of the top matches.

It's pretty cool.

You can scroll through this list and double-click on the item you want.

Cheers,

-Jim

[Yair]

Thanks for the suggestions

QUOTE(Jim Kring @ Feb 14 2008, 10:21 PM)

First, I wouldn't override the File>>New VI operation. This is annoying, in my opinion.

Can you elaborate on that? I actually find it quite convenient, since if I want the original functionality all I have to do is take my finger off the N key and then click it again.

QUOTE

I would add an option to the

Tools

menu to start up the tool and have it run behind the scenes waiting on a configurable key combination.

This will probably improve performance (although at the moment I don't see a need to), but the main problem with this is that the tool will then stay in memory even when all other VIs are closed. I was considering using the Set Close if Lonely property, but I haven't looked into it yet.

What I actually need now are ideas on how to build a viable system for scanning, exporting and importing aliases so that people can relatively easily create files for new toolkits and versions and distribute those files to other people who will then be able to easily integrate them into their existing setup.

Essentially, my current plan is having a configuration style file for each toolkit which will define transformations between versions and I already have the basic format. The real problem is creating this file - the user who creates that file needs some reasonably easy interface which will allow specifying for each VI whether it is new, renamed, deleted or any other option.

I'm open to suggestions.

[Jim Kring]

By the way, you can get a list of the object names and IDs used in the palettes inside the objectnames.js file that's inside the LabVIEW help (chm) file. Type this into the address bar of Internet Explorer to extract the javascript file (IE will ask you if you want to save the file to disk):

mk:@MSITStore:C:\Program%20Files\National%20Instruments\LabVIEW%208.5\help\lvhowto.chm::/objectnames.js

(you can replace the "8.5" above with the LabVIEW version of interest)

I have attached these files, here:

Download File:post-17-1203021794.txt

Download File:post-17-1203021800.txt

Download File:post-17-1203021807.txt

Download File:post-17-1203021814.txt

Also, you'll need to un-URL-escape the names (e.g., convert "%20" into space characters), but all this can be automated, very easily.

Cheers,

[Yair]

Thanks. Unlike the new VI object ring, this doesn't include controls (I guess most don't have help topics), but it's definitely a good list.

I will post the version I'm currently using tomorrow, along with some files, just so that we have a common baseline to talk about.

[Yair]

OK. So here's the version I've been using for the last 3 or 4 months, along with some files I created. Extract it somewhere and read the readme file.

I would especially recommend this to anyone using 8.x. The little experience I had with 8.x seems to suggest that accessing the palettes is very annoying and this gets around that.

Important note - the code is not meant to be pretty or clever. It was put together over some time partially as a proof of concept in coding sessions which were usually done at night, so don't expect quality code here. It works just fine and if the issues described in the rest of this post are overcome, will probably also be cleaned up. In case you're wondering, the main design criteria which led to this structure was the wish to avoid memory allocations of the large string array, but I haven't been too zealous about actually doing it so far, since I didn't run into performance issues.

The list files attached here are not the files I actually use (they don't have preference values or aliases) but they should work. However, they also demonstrate the problem I currently have nicely. A lot of things change over time. For example, the dialog controls in 7.x are now called system controls in 8.x.

I have a basic design (and code) for how to run files which will automatically upgrade the relevant names, but the problem is with creating a usable interface for creating those files. To be honest, I haven't put too much thought into it so far, so I wouldn't mind hearing suggestions.

Essentially, what is needed is a method of recursively scanning a directory or a set of palettes and generating a list and then comparing that list to a previous version and letting the user decide what to do with the names which are different.

I already have code for scanning a folder hierarchy and then to attempt dropping those functions. All those which can't be dropped are discarded. This is what I used to generate the lists attached to this post. I also have some code which uses the palette API, but it didn't seem to play nicely with the primitives and with older LabVIEW versions, so I didn't look seriously into it.

[Yair]

P.S.

Known issues:

• In LabVIEW 7.0, the first call to the dropping method after starting LabVIEW takes several seconds and sometimes changes the focus to another LV window when it's done. This doesn't happen in 7.1 and above.
  
• On very rare occasions, I have seen some issue with the call to the top-level VI. I don't remember the specifics (it's been a while since I've last seen it), but I think it wouldn't let me close windows. The solution, once you know it, is simple - opening the hierarchy window allows access to the proxy caller, which can then be aborted.
  
• I didn't make the delete\rename a proper dialog, so it still has the menus, scroll bars and tool bar. The change is simple.
  
• The files I attached are not fully compatible with 8.x. Some of the names have been changed in 8.x, so you can just add them as they come or rename them.
  

[Yair]

So NI released their version of this tool in LabVIEW 8.6, and now that it's out, I would advise people to try playing with my tool a bit. The reason is that it has a couple of features which are implemented differently than in QD (better, IMO) and if other people think so as well (and tell NI about it), then NI will hopefully spend the time implementing something similar.

Specifically,

1. The selection is done differently. QD uses a combobox with autocomplete and only moves to the listbox if you use the arrow keys. DI uses a string control and always has an element selected in the listbox. This changes where your focus is. Both methods have merit, but I believe mine has advantages because of the following point.
   
2. When you have more that one match, and you do want to use the listbox, you have to shift your attention there. If many of the things you drop are like that, you might find that you always look at the listbox instead of the combobox and thus miss the autocomplete. Since I have used my version a lot and I haven't used QD much, I can't say for sure.
   
3. My version uses a more intelligent sort algorithm, making the result feel (IMO) much more natural. Again, this matters less if you're using shortcuts all the time, but I have a feeling many people won't use them much of the time.
   Two specific differences in this algorithm are that DI uses a preference algorithm, so that when you use a specific name more often, it's more likely to be selected and that it gives preference to a match which is in the beginning of a word and\or close to the beginning of the name.