'Find all instances' doesn't work with dynamic VIs

[Will Keogh]

I have started using LVOOP and have stumbled on an annoying limitation - the 'Find all instances' search doesn't work for dynamic VIs. It just returns 'none found'. This is really annoying - I often use this command to see where else a VI is called. Does anyone know how to fix this, or maybe a workaround?

Thanks,

Will

[crelf]

I have started using LVOOP and have stumbled on an annoying limitation - the 'Find all instances' search doesn't work for dynamic VIs. It just returns 'none found'. This is really annoying - I often use this command to see where else a VI is called. Does anyone know how to fix this, or maybe a workaround?

Thanks,

Will

That doesn't surpise me since they're dynamic - that's sort of the point The only way I can think of is to search for the text of the VI's name and hope that it comes up in an array/constant/path somewhere before the dynamic call...

[Aristos Queue]

There are several aspects of the editor that will need work over time. The find/replace system is one. At this time, there are many places in the editor, like the Hierarchy Window, that do not know to take dynamic calls into account.

Regarding crelf's comment that such finding would have to be based on name: we can do the find better than that. The classes do know their inheritance relationships, so when you search for X.lvlib:Y.vi, we can differentiate which Y.vi calls might possibly invoke X.lvlib:Y.vi specificaly.

It's just going to take time to find all of these places that want special treatment for dynamics. Some of them are going to need UI tweaks, since it is equally possible in some cases that you want to treat dynamic nodes as possible calls to a set of VIs, and other cases where you're going to want to talk about just the specific VI.

[Will Keogh]

Thanks for your thoughts. I can see that its not trival to define how 'find all instances' should work with dynamic vis, and I'm glad to hear its being worked on. Guess I'll have to be patient.

It would be much nicer if 'find all instances' at least said 'this function doesn't work with dynamic vis' rather than just going beep 'none found'. At first I thought 'find all instances' was seriously broken in 8.20, and it took me a while to figure out that the problem was only with dynamic vis.

Will

[i2dx]

Thanks for your thoughts. I can see that its not trival to define how 'find all instances' should work with dynamic vis, and I'm glad to hear its being worked on. Guess I'll have to be patient.

It would be much nicer if 'find all instances' at least said 'this function doesn't work with dynamic vis' rather than just going beep 'none found'. At first I thought 'find all instances' was seriously broken in 8.20, and it took me a while to figure out that the problem was only with dynamic vis.

Will

I had the same issue with dynamic VIs in Lv 7.1 and I used the following workaround:

create a new VI, put all dynamic VIs into it, drag a disable structure around it, put that VI into your main vi - and voila - all dynamic VIs are in the hierarchy.

The second advantage is: if you use typedefs, etc in your main VIs hierarchy, wich are also used in the dynamic VIs, the typedefs in the dynamic VIs are automatically updated, if you change your typedef. The same happens, if you save a SubVI with "save as ..." because all VIs are in memory and are changed automatically ....

cheers,

CB

[Aristos Queue]

I had the same issue with dynamic VIs in Lv 7.1 and I used the following workaround:

create a new VI, put all dynamic VIs into it, drag a disable structure around it, put that VI into your main vi - and voila - all dynamic VIs are in the hierarchy.

The second advantage is: if you use typedefs, etc in your main VIs hierarchy, wich are also used in the dynamic VIs, the typedefs in the dynamic VIs are automatically updated, if you change your typedef. The same happens, if you save a SubVI with "save as ..." because all VIs are in memory and are changed automatically ....

cheers,

CB

Um... dynamic subVIs didn't exist prior to LV8.2. You're talking about a subVI that is called dynamically. The post was (I think) about dynamic subVIs (as in in LV8.2, right click on the conpane terminal of an LVClass type and select "This terminal is>>Dynamic Input (Required)"

[Mike Ashe]

There are several aspects of the editor that will need work over time. The find/replace system ... the Hierarchy Window, ...

Glad to know these two are on your radar. Another thing that would be really nice is if the Hierarchy window would optionally show shared libraries, the function called and path.

It would be great to be able to save the text of a Find filtering.

[i2dx]

Um... dynamic subVIs didn't exist prior to LV8.2. You're talking about a subVI that is called dynamically. The post was (I think) about dynamic subVIs (as in in LV8.2, right click on the conpane terminal of an LVClass type and select "This terminal is>>Dynamic Input (Required)"

for(int i=0;i++;i<100) {

printf("I shall read the posts carefully, before I push the answer button!\r\n");

}

seems you're completely right

cheers,

CB

[crelf]

for(int i=0;i++;i<100) {

printf("I shall read the posts carefully, before I push the answer button!\r\n");

}

Hey - where's the ASCII-art attempt at doing this in LabVIEW?!?

[i2dx]

Hey - where's the ASCII-art attempt at doing this in LabVIEW?!?

it was painfull enough to code that in C. I was searching for over 30 minutes to find that %&"

[Yair]

Hey - where's the ASCII-art attempt at doing this in LabVIEW?!?

Download File:post-1431-1159300632.html

For those wondering, those are a CRLF, a Concatenate and a one button dialog.

[Robbie Gehbauer]

It would be great to be able to save the text of a Find filtering.

Hit Ctrl-C with the Search Results window active, and it will format all the entries in the listbox and you can paste/save it however you want. This was broken in 8.0, but worked before 8.0 and works again in 8.2. Is this what you mean?

[Mike Ashe]

Hit Ctrl-C with the Search Results window active, and it will format all the entries in the listbox and you can paste/save it however you want. This was broken in 8.0, but worked before 8.0 and works again in 8.2. Is this what you mean?

15 years at this and you learn something new every post! Gosh I love this forum.

Well, this is close, on one aspect of the request. I should have been a little more specific. I asked for the text sort of as a, "gee, if we can't have "X" then could we at least have "Y" please?".

I have to admit that what I'm really after is programmatic access to the Find functionality. Yes, I know we can do a lot of this now with scripting, but that cookie jar got moved to a higher shelf recently. The Find API, even just the DLL functions might be a step in the right direction, but what I'd really like is a few VIs that let me search for items, put them and their paths in my own listbox, do my own followup queries/tests, etc.

Where this request comes from is that I have had several recent projects where the client's code is an archeology dig that really needs an enormous cleanup along with the extra functions they've asked for. Programmatic FIND would help in this effort. Could you or someone else pull back the curtain a little and expose more of Mr. Oz?

[crelf]

I know we can do a lot of this now with scripting, but that cookie jar got moved to a higher shelf recently

You just need either longer arms or the behave when your mother's watching