Create anchors and shortcuts inside LabVIEW code for documentation/navigation.

[TCPlomp]

I would want the option to create anchors in LabVIEW code, these anchors could be used to

• navigate inside LabVIEW code between different parts of the code
• Easy jump to specific section
• Connect different states as a documentation tool

These anchors wouldn't change the execution of the code, they are only meant for documentation and should be named. For starters they would only be global in their own VI block diagram, but that could be expanded.

In a document describing the code, you could refer to a specific section (loop, case structure), or you could create a note in the code 'this code starts the following case structure' etc.

Ton

[altenbach]

Ton,

This is an excellent suggestion, but I thought it has been proposed before. Not sure where, though.

[JackDunaway]

Related Ideas:

Bookmarks

BD Shortcuts/Links

Hyperlink in Floating Comments

Tabbed Comments

Pop-up Comment

Tip-like Comments

Saving Space with Comments

In my mind, these all constitue a monolithic project that supports hyperlinking to websites/folders/other places in code, "pop-up" style comments (maybe hovering shows the full comment in Context Help), a manager that allows quick perusal of these bookmarks, etc... As such, none of the Ideas classify as duplicates per se, just pieces of the puzzle of this new documentation feature.

+1 for reviving. I would encourage others to Kudos above links as well.

[TCPlomp]

Yes, I missed those, however I searched for 'Anchors' and shortcuts...

[JackDunaway]

---

@TCPlomp wrote:

...I searched for 'Anchors' and shortcuts...

---

Although I knew a few existed, I couldn't find them at first either (I thought 'Bookmarks' was a winner). 'Comments' turned out to be the key word. 😉

[David_L]

I feel like this could be a good idea, but also think it could make it easier for people to make larger and larger block diagrams.  I feel that if your code is large enough to require an anchor or link to another part, it's better to try to find ways to modularize it and make your block diagram smaller.  Then you won't need this idea 🙂

[TCPlomp]

Hi David,

that sure goes a long way. However consider the following use-case:

A state machine (I pick JKI's state machine as an example).

It would be very usefull if I could state:

'This state is called from 'State A, State B and State C', and that those references were actually hyperlinks.

[PhillipBrooks]

How about this case:

VI Server is used to run a 'daemon' vi that services a queue.

Various VIs submit data to the queue, but there is no wire or sub-vi that directly takes us to the 'daemon' vi.

A Shortcut / Bookmark / Portal placed by the original programmer allows others to move between the origin and destination of the data without knowing the whole architecture of the application.

( I seem to recall Aristos liked the game 'Portal' )

[Ray.R]

I like your suggestion.  At the moment, I place my own text in the code, such as "RR - Mod", or "RR - doThis".

Then I search text and find every location in the code that matches the search keyword.  Having a built-in anchor would be great as it would allow to jump to other sections of code more efficiently.

[Daklu]

I like the idea of code bookmarks for a project... I'm not convinced hyperlinking to bookmarks is a good extension of the concept.  I have to agree with David in that it feels like a dev environment patch to support code that should really be refactored.

Large block diagrams are universally accepted as "bad" because they are hard to follow.  Large state machines (many states) often are just as hard or harder to follow.  When a state machine becomes large or complex enough that it isn't relatively easy to ctrl-scroll through the cases to trace backwards through the code, that's an indicator to me that the requirements are outgrowing the current design and it's time to refactor.

[Ray.R]

Good comment Daklu.

However, I wasn't seeing this to help locate items within a block diagram.  I was seeing this as finding items (or related items) spread accross several VI's within a large project.  Especially a LVOOP project.  Having tags within VI's would help to narrow down a search for specific object or a specific group of objects; thus making life easier when scaling up the software or debugging it.

R