Extend class representation in project explorer

[Daklu]

Currently the project explorer window only displays class methods that have explicitly been created.  I propose a view where classes in the PE window display all the valid methods that can be called on that class.  For example, when creating a new ClassB and making it inherit from ClassA, in the project explorer window ClassB is immediately populated with 'shortcuts' to the ClassA methods it can use.  These shortcuts are simply a convenience and help with clarity; they don't have any real representation on disk.  Dragging a shortcut to a block diagram drops the parent method that shortcut refers to.

Shortcuts need to be distinguishable from real methods in the PE window, so they should be represented by italics or perhaps a unique icon.  When ClassB overrides the parent method the shortcut is replaced with the overriding vi.  If the parent class has methods that must be overridden the shortcut could be presented in red text or an exclamation point can be laid over the top of the icon in the PE window.  Shortcuts to protected methods should include the protected icon.

Classes already contain one "virtual" member--the class .ctl doesn't have a unique representation on disk.  In some ways this is an extension of that idea.  This also opens the door for desired future extensions to LVOOP, such as traits.

[Daklu]

Link to idea for Traits.

[Mr.Mike]

This sounds like a Class Explorer, not a Project Explorer.  Maybe a new window?

[AristosQueue (NI)]

Mike: Whether or not this is appropriate for a Project Explorer probably depends upon how you use the Project Explorer.

To me, it's a big always-pinned palette of my current application. Personally, I wouldn't want a separate Class Explorer window because that wouldn't have all my non-class VIs in it. That would be useless. Adding the shortcuts so I can drop things faster seems kind of useful. (Yes, Darren, I know I should just use Quick Drop.)

To others, who see the Project Explorer as an organization window for files, having a file listed in two places, even by shortcut, might be somewhat distasteful.

Not sure what the right answer is, but I chipped in my Kudos on this one.

[Daklu]

I use PE the same way AQ does.

For those that use PE as an organization window for files, there's always the files tab.  I wouldn't expect shortcuts to show up there.

[tst]

One problem with this is that it creates noise. I generally don't use the PE as a palette, so having every single class show every method from all its parent classes sounds quite distateful. I certainly agree that it would be useful to easily see all the methods a class can use, just like the property node allows it, but I don't think this is it.

[Mark_Yedinak]

I like the idea but if implemented I think the user should have the ability to hide or show the shortcuts. I use the project in much the same way as AQ but I can see times where it would be noise andI would like to turn it off. Anyway, I kudoed the idea.

[AristosQueue (NI)]

I think you also run head-long into the "how do you autobuild a palette" problem. Do you arrange them in the same virtual folders as the parent version? Do you put the shortcuts before the actual methods? What about overrides -- there shouldn't be shortcuts to the parent version because that would just be weird, but do they then get sorted into the middle of the parent versions?

[kegghead]

I also use the PE as my palette and would love this feature. Other language IDEs do this and I find it very useful.

[Daklu]

AQ,

"Do you arrange them in the same virtual folders as the parent version?"

No.  I'd say just drop them in the class root and let the child class author move the shortcuts to where they want them.  Virtual folders provide a logical organization.  What's logical for the parent class might not be logical for the child class.  (I suppose you could put them in the same virtual folder when the inheritance is first set.)

"Do you put the shortcuts before the actual methods?"

I'd expect a shortcut in the PE window acts just like a regular method for the most part--you can move it around, you can drag it to a block diagram, you can double click to open the target vi, etc.  I wouldn't expect to be able to change things like scope or the method's name via the shortcut.  Right clicking a shortcut could offer things like 'Find Target' and 'Override this VI.'

"What about overrides -- there shouldn't be shortcuts to the parent version because that would just be weird, but do they then get sorted into the middle of the parent versions?"

I'm not sure I understand the question.  Once a parent method has been overridden the shortcut is replaced by the overriding method in the child class.  The shortcut isn't sorted anywhere because it doesn't exist anymore.

[AristosQueue (NI)]

> I'd expect a shortcut in the PE window acts just like a regular method for the most part--you

> can move it around, you can drag it to a block diagram, you can double click to open the

> target vi, etc.  I wouldn't expect to be able to change things like scope or the method's name

> via the shortcut.  Right clicking a shortcut could offer things like 'Find Target' and 'Override this VI.'

Yeah, but when you added a new method to the parent, it gets auto added to all the children. The children might not even have been in memory when the method was added. Or renamed. So LV is going to have to just stick these shortcuts in somewhere on the children. Where?