Class Method Browser

[QueueYueue]

NOTE: THIS TOOL WILL CURRENTLY CRASH LABVIEW

 

Checkout this pseudo code:

 

Class Vehicle{

    Public Methods: Go(), Stop()

}

 

Class Car inherits Vehicle{

    Public Methods: FloorIt(), ReFuel()

}

 

In school, I programmed java with Eclipse. In Eclipse, when you have a variable named myCar with a type "Car" you could type: myCar.  (notice the period). When you typed the period, eclipse would pop up a little dropdown with the following in it: Go(), Stop(), FloorIt(), ReFuel().

 

These are all the methods that i'm allowed to call on the myCar variable. It's a car type, so I cal call all the Car methods, but a car IS A vehicle, so I can also call all the vehicle methods on it. Eclipse would figure this all out for me, and just show me everything.

 

I wanted something like this in labview. I always found it a pain to look at the class I'm working on, then have to find it's parent in the project and find all the methods of it that i'm allowed to call, then go up another layer perhaps. Additionally, I need to remember access scope. So if I have class A that's calling a method on class B, what is it allowed to call? It depends on if the classes are parent/children, or if they're friends.

 

I made a tool that does all of this for you. All you have to do is click on a class wire in a VI, and the tool creates a list of all VIs that you're allowed to call on that wire. It looks at access scope and it traverses the class hierarchy. And it does all this fast.

 

 

(notice the car wire has been selected, and the Class method browser shows all the methods that it can call)

 

Double clicking on a method name in the method browser will place the VI on your mouse so that you can drop it on the block diagram wherever. Shift double clicking on the method name will insert it on the currently selected wire (using a very bad insert algorithm). Hovering over a class name will show the method's description in the context help.

 

HOW THIS TOOL WILL CRASH LABVIEW
I wanted this to be fast. I didn't want there to be a wait every time you selected a new thing on the block diagram. Unfortunately, all of what I'm doing involve VI server calls, which are not super fast. The main culprit is when figuring out what the parent of the class is. So to avoid these slow VI server calls, I cache everything I will need. I make the slow calls once when you boot up the tool, and then every other time I need the info, i just have to look it up in a variant database. Perfect, and blazing fast.

 

Well somewhere along the lines LabVIEW complains. Basically, if open the tool, then change a classes private data, LabVIEW will crash. I've submitted this to NI, but all I've heard back is "This is in CAR....."

 

I wish this didn't happen. If it didn't then I would've spent some more time polishing this up, and then proudly released the tool (with lot of money, fame, cars and houses to follow). But it was not meant to be. So i post it here. In hopes that someone gives me an idea of how to avoid the crash. Or maybe you'll just tell me it's a dumb idea.

mgi_lib_class_method_browser-0.1.0.2.vip

[Jordan Kuehn]

I think it's a great idea.  It can be a pain to switch back and forth between the block diagram and project explorer at times.  I'll download and take a look, but I can't promise any cool tricks to fix your crashes.

[LogMAN]

This tool is nice and will become very useful once the bug is fixed.

 

I tried your code and instantly experienced the bug. However there is a workaround:
Running the main VI directly from disk will prevent the crash.

 

Sadly it will crash the moment you close the UI.

 

I found one issue so far (seem to solve the problem for me):
You store references to each library into a variant attribute that is collected in the Variant 'Reference Lookup List'.
>> Remove all dependencies to that list and fetch the references again in your 'Callable Methods.vi'.

In my case the Browser did not crash anymore...

 

 

However that does not fix the issue with calling the Browser from the Tools menu...

I don't know for sure, but it seems that the instance from the Tools menu compared to starting a
VI directly from disk is somehow different...?

 

Does anybody know more about that?

 

EDIT: Tested in LabVIEW 2013 (32-bit) on Win7 x64

Edited August 17, 2013 by LogMAN

[mje]

I think incorporating this logic into quick drop would be ideal.

[KFadgen]

I like this tool, I'll definitely give it a go once the bugs are worked out.

 

I've also wished that this functionality were built into the Project Explorer.  When a new class is generated and the inheritance assigned, we would see the static parent class method VIs already populated in the child.  The VIs could be grayed or italicized to visually indicate that they are inherited methods.  These wouldn't need to be actual VIs stored on disk, just visual pointers back to the parent methods.  We could also have dynamic dispatch VIs come in as italicized and red font or something to indicate they can be overwritten...

[Yair]

Some relevant links:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Intellisense-support-to-the-property-node/idi-p/1540954

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Quick-Access-to-a-LVOOP-Class-Library-via-the-Right-Click-Menu/idi-p/2256860

 

https://decibel.ni.com/content/docs/DOC-6771

 

 

I don't know if the last one has a QD replacement.

[QueueYueue]

I thought of a quickdrop tool at first as well. The problem with that is you'd have to select the wire, the do a ctrl+space. This would bring up a generic quickdrop. Now you'd need to do what? If you start typing, it just does default quickdrop search. It's not possible (as far as I know) to use a plugin to change what is searched. So maybe instead of typing you hit a quickddrop shortcut. Ok, now we have a list of methods, how do I display them? Can you just populate the quickdrop combobox? I could never figure out a happy way to make the plugin work, so i ditched quickdrop all together.

[hooovahh]

So maybe instead of typing you hit a quickddrop shortcut. Ok, now we have a list of methods, how do I display them? Can you just populate the quickdrop combobox? I could never figure out a happy way to make the plugin work, so i ditched quickdrop all together.

I'm no quick drop expert but this is how I'd do it.  Say CTRL+Space then CTRL+C (maybe that is semi-reserved) this brings up a new dialog window that shows the options, and you pick the one you want which then adds the code to the block diagram.  Closing this window does nothing, and calling another CTRL+C brings this window back to the front with new settings if it was never closed before.  Not ideal no but I think it could be used this way.

[QueueYueue]

This tool is nice and will become very useful once the bug is fixed.

 

I tried your code and instantly experienced the bug. However there is a workaround:

Running the main VI directly from disk will prevent the crash.

 

Sadly it will crash the moment you close the UI.

 

I found one issue so far (seem to solve the problem for me):

You store references to each library into a variant attribute that is collected in the Variant 'Reference Lookup List'.

>> Remove all dependencies to that list and fetch the references again in your 'Callable Methods.vi'.

In my case the Browser did not crash anymore...

 

Callable Methods.vi.png

 

However that does not fix the issue with calling the Browser from the Tools menu...

I don't know for sure, but it seems that the instance from the Tools menu compared to starting a

VI directly from disk is somehow different...?

 

Does anybody know more about that?

 

EDIT: Tested in LabVIEW 2013 (32-bit) on Win7 x64

 I took a look into this. I noticed the crash when running in the tools menu. I didn't test the non-tools menu version because, well... It's slow now. There is a noticeable delay when clicking a wire. I NEED SPEED!! 

I'm no quick drop expert but this is how I'd do it.  Say CTRL+Space then CTRL+C (maybe that is semi-reserved) this brings up a new dialog window that shows the options, and you pick the one you want which then adds the code to the block diagram.  Closing this window does nothing, and calling another CTRL+C brings this window back to the front with new settings if it was never closed before.  Not ideal no but I think it could be used this way.

Yeah, this is similar to what I was describing. The problem is then the QD is basically just a separate way to launch the same tool (vs the tools menu). Which i could add, but it's still not a QD only solution.

QD feels like a "Every problem is a nail...." situation to me.

[hooovahh]

Yeah, this is similar to what I was describing. The problem is then the QD is basically just a separate way to launch the same tool (vs the tools menu). Which i could add, but it's still not a QD only solution.

QD feels like a "Every problem is a nail...." situation to me.

I agree.  I have found myself developing a tools menu item, and then changing it to a quick drop item instead.  When developing I find two shortcut combos is faster then navigating the tools menu.  Especially on a system where the items and order of the things in the tools menu potentially changes after installing something from VIPM.

[mje]

QD feels like a "Every problem is a nail...." situation to me.

 

I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

[QueueYueue]

I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

I like the context specific idea. Like some sort of pop up when you click a class wire. Wouldn't be that hard of a modification since I've got all of the logic. It may be a bit of a challenge to keep it on the useful side of things and not slide into the annoying side.

[ShaunR]

I completely agree. Don't get me wrong, I love QD, but I don't care for the collection of arcane keystrokes that are used to bend it to one's will. Ideally what I'd like is not so much to have a floating window open at all times, but a tool like yours come up due to some context like quick-drop does.

 

I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages. I've also wanted dockable palettes so that the "favourites" could be docked to the top of the screen. I think it's very limited use of the screen space to have the floating windows (urrgghhh. The probe window!). The same could be applied to "quickdrop". Just dock it to the top of the screen and have a single text entry like the chrome address bar that drops down when you type stuff into it and goes away when it loses focus.

Edited August 19, 2013 by ShaunR

[JamesMc86]

I don't use quickdrop but I've always wanted a palette that shows (say 10 of) the "most used" VIs similar to how chrome shows the most visited web pages.

There is something on NI.com/labs that claims to do the most visited palette, not tried it yet but might be worth a look.