Interface & class highlighted hierarchy context help

[FixedWire]

If one had to explain the architecture of a larger project to a new person that implements classes & interfaces without referring to a top level UML diagram, the eyes could quickly start to glaze. Adding simple functionality may prove to not be so simple.

Perhaps adding to the context help when hovering on the wire showing the hierarchy would be helpful as outlined below.

Note: Kudos to Piotr for making the code available. Thank you!

VIWeek 2020/Functional programming inspired object-oriented template in LabVIEW + SOLID

[AristosQueue (NI)]

My personal opinion: Context help windows aren't typically that big... the class hierarchy for any single class can get quite deep. I can see a right-click on a wire to show the hierarchy window for a particular class, but I'm having a hard time seeing the CH as a good way to do that.

As LV R&D: It would be unusual to have something that potentially large in the CH, but not unheard of (large clusters can unroll a lot of content into the window). Maybe worth considering, but it seems to me like considerable work for R&D for little gain to users. Not saying "no," but I am saying, "seems unlikely."

Having said that -- the problem that the idea seeks to solve (of faster way to explore the hierarchy information of a wire) seems like a valid problem. We should probably explore more options for elevating that information *somehow*. If the CH turns out to be the best way to do it, so be it.

[fabric]

Just showing the direct ancestors of the selected class would be good enough for me. I don't see any need to show the entire hierarchy...

[FixedWire]

"faster way to explore the hierarchy information of a wire" nails it.

The CH does have its limitations and there are likely better alternatives.

The original thought was how do I make sense of a "stack" of classes in the project when looking at code that now has more functionality. It was a simple thought of how do you leverage what exists to make life easier now as opposed to implementing a UML diagram editor. Was it GOOP that tried to do this? Either way it certainly didn't become a go to. Keeping documentation in sync with code tends to be low on the priority list once project deadlines loom and then it falls by the way side. That's the real danger. That's when code maintenance becomes expensive. That's the business case in the long run.

Let's keep the ideas moving! Thanks everyone.