Custom Cluster Indicator and Control Descriptions in Context help?

[jsweet]

---

@RavensFan wrote:

This might be a place where you just put the descriptions as a comment on the block diagram.

Or create the list in Word, print it out, and keep it by your computer while you are doing the programming to refer to.

---

I do have a Word document in this application that is tied to the context menu help of that cluster. This will be fine for now and that's why I've done it that way, but if someone else is developing on my code it would be a pain to have to always print out hard copies of documentation as well as they don't update when points are added/edited or renamed

[Prince17 · Accepted solution]

Instead of wiriting in each element's description or tip strip, write every element's detail in the description of the cluster itself. Then you can see the details of every element of the cluster in the context help. 

[jsweet]

---

@Prince17 wrote:

Instead of wiriting in each element's description or tip strip, write every element's detail in the description of the cluster itself. Then you can see the details of every element of the cluster in the context help. 

---

I've thought about just going this route. This would help when selecting a cluster indicator/control, but doesn't show up in wire context help and doesn't really get at the root of what I want to do. For example on the Obtain Notifier vi shown below I'm on the error out terminal which is a cluster terminal. There is no description of each of the individual elements of that cluster except for the data type. What I think would be really helpful is if I could insert some kind of description there instead of the datatype.

I hesitate to mark this answer as a solution, but if there is no other way to modify that then that's what I'll do. I just thought that since LabVIEW is placing text there (the data type definition) that there could be some way to change it or add to it?

[Prince17]

I don't think what you are saying can be done. 

Correct me if I'm wrong.

Kudos are welcome

[jsweet]

---

@Prince17 wrote:

I don't think what you are saying can be done. 

Correct me if I'm wrong.

Kudos are welcome

---

I just think if it can't be done something should be implemented. I noticed too that when using an unbundle by name context help just shows the context help for unbundle by name which makes sense because I'm really hovering over a terminal so the only context help it can give is wire context help. I just think that this shouldn't be too big of an issue to implement.

[RavensFan]

No.  It doesn't seem like it can't be done.  And I don't think it is that easy to just to change something in LabVIEW and make it happen.  Here is why.

Some things are part of the definition of a data type.  Namely the label.  They exist for controls, indicators, constants, and wires of that datatype and will show up in all of those locations within context help.

Other things are not part of the definition, for example, captions and documentation.  If you notice, you can put extra info in the caption of a control or indicator.  But turn it into a constant, the caption no longer exists in the property dialog box.  Why?  No need for it.  Caption is a property for visual appearance to the user of the front panel and wasn't intended for anything only seen on the back end such as constants in a block diagram.  In addition, with regular type defs, you can have two different controls or indicators with different captions (a property of that instance of the front panel object).  But what should the caption be, if it existed, for a wire on the block diagram?

If an architecture is complicated enough that you need additional information while programming with it, then having comments in block diagrams is perfectly valid.  Or having a separate sheet printed out that a programmer can refer to while working is also perfectly acceptable.  If it is so important that they need this information, then making them take a few minutes to print out a sheet, or go find a block diagram comment should not be a problem.

If it is so critical to have easily identifiable names always right in front of them while programming, then labelling the controls with the fully descriptive name should not be a problem.  If that is too much information for the end user looking at the front panel, then you hide the front panel label, show the caption, and set the caption to be the "user-friendly" label.

[jsweet]

Just to clarify, I think you meant:

---

@RavensFan wrote:

No.  It doesn't seem like it CAN be done.  And I don't think it is that easy to just to change something in LabVIEW and make it happen.  Here is why.

---

I posed this question mostly so someone with greater labview knowledge than myself may help me find out if there was a solution out there for what I was looking for. I think your complete response is a great description of why there isn't a solution yet. I do disagree however that BD comments are a good means of keeping track of cluster information especially during development with typedef clusters in a large complex application. Since they all update when the typedef is changed the comments could become incorrect as could printed out copies.

Really the architecture is too complicated, but it's that we have a cluster of data that have so many points that are very closely related. The data point definitions are pretty hard to describe and because of this we've written up a specification for the definitions of the terms we use. Which is the document I've mentioned, that completely defines each term. This document is something that we will use when we deploy the application in it's entirety. This document though isn't for the development process because it is constantly being revised, changed, and updated.

I don't think my project is 'dependent' on the functionality I'm looking for, but I just thought that there may be a solution out there. I think based on your answer the functionality I'm looking for doesn't exist currently. The best solution to my issue is going to be what Prince referenced. (Putting the description in the cluster context help.) This will change everywhere the cluster is used and I only have to update the documentation in the cluster once.

In conclusion I'm going to mark this answer as solved, but I do have a follow up question. If I need to make a new thread I can, but in the mean time...

So I think it makes sense now that the datatype definitions cannot be changed/modified because they are something very deep in LabVIEW (or C really.) Is there any reason that the cluster definition don't show up for a wire's context help? This would be great because (for my issue) I can put all the numeric descriptions embedded inside the cluster's context help menu and still see the cluster's context help without having to actually have the cluster's control/indicator. I mean I can always just quickdrop the custom control, but I just didn't know if there's a specific reason why LabVIEW does that or not?

[Ben]

Another approach...

nsntead of a normal cluster, use a LVOOP class and create accessors for reach value. The accessors can have the documentation for each value that I belive will show up when you are using propery nodes to invoke the accessors.

Not a solution to your original Q, but it would allow docuementation for each field.

Done with my distraction,

Ben

[RavensFan]

---

@jsweet wrote:

Just to clarify, I think you meant:

---

@RavensFan wrote:

No.  It doesn't seem like it CAN be done.  And I don't think it is that easy to just to change something in LabVIEW and make it happen.  Here is why.

You're right.  I think I switched the thinking in my mind of the sentence structure in the middle of typing and wound up with an unintentional sort of double negative. 

---

I do disagree however that BD comments are a good means of keeping track of cluster information especially during development with typedef clusters in a large complex application.

I'll agree with you on that point.  It creates a potential revision control problem.  I think if you create the comments in one place where things are first defined, and are sure to update the comments when making changes, you'll probably be fine.  If you wind up needing to scatter multiple copies all over, then you run the risk of something being stale when the change is made elsewhere.  One possibility is that I think the bookmark feature has the ability to hyperlink added to it.  If so, you can scatter hyperlinks all over that point to the version controlled document.

Since they all update when the typedef is changed the comments could become incorrect as could printed out copies. Printed copies should always be considered as potentially obsolete.  That is one of the tenets of revision control.  You can print out something one second only to have someone revise the electronic "master" document a second later.  It doesn't stop people from printing out drawing to refer to, or keeping a spreadsheet or parts list in front of them so they can easily look between their work on screen and their reference material.  They just have to aware of the potential obsolescence and its risk for what they are doing, then be sure to check on the version control status if the risk is great enough that a revision has occurred.)

Really the architecture is too complicated, but it's that we have a cluster of data that have so many points that are very closely related. The data point definitions are pretty hard to describe and because of this we've written up a specification for the definitions of the terms we use. Which is the document I've mentioned, that completely defines each term. This document is something that we will use when we deploy the application in it's entirety. This document though isn't for the development process because it is constantly being revised, changed, and updated.

I think that document, or at least the relevant portion of that document needs to be part of the development process.  You have an original copy you start from when working.  As you working, you are making changes, you need to keep that up to date while developing.  At the end of the project, you need to make sure all of those changes get added back into the final document that gets used during final deployment.

I don't think my project is 'dependent' on the functionality I'm looking for, but I just thought that there may be a solution out there. I think based on your answer the functionality I'm looking for doesn't exist currently. The best solution to my issue is going to be what Prince referenced. (Putting the description in the cluster context help.) This will change everywhere the cluster is used and I only have to update the documentation in the cluster once.

In conclusion I'm going to mark this answer as solved, but I do have a follow up question. If I need to make a new thread I can, but in the mean time...

So I think it makes sense now that the datatype definitions cannot be changed/modified because they are something very deep in LabVIEW (or C really.) Is there any reason that the cluster definition don't show up for a wire's context help? This would be great because (for my issue) I can put all the numeric descriptions embedded inside the cluster's context help menu and still see the cluster's context help without having to actually have the cluster's control/indicator. I mean I can always just quickdrop the custom control, but I just didn't know if there's a specific reason why LabVIEW does that or not?

---

It depends on what you mean exactly by "cluster definition".  The definition of the cluster does show up in the wire's context help.  Captions are visual properties that don't apply to the definition.  The other documentation properties such as VI or CTL documentation, or description, or tip strip seem to fall into that same category.  Plus with regular controls and type def controls, those items can be changed for individual controls and indicators without changing all the other instances.  That will then create a situation just like we were talking about earlier.  With strict type definitions, those properties do get updated.  But I would assume when those parts of LabVIEW were created, no one thought that information would need to be extended to a wire.  Also, there is such a thing as too much information in the context help window.  Even now, the context help window can get pretty crowded with type definion information on more complicated clusters.  So adding additional information to help make sense of more complicated structures winds up compounding the problem and getting lost in the screenful of information.

Just to be clear, I'm not trying to argue with you or say what you are asking for shouldn't be done.  I'm just trying to speculate on your questions as to why something might not have been done or perhaps can't be done.  I appreciate you asking these questions and excercising my mind a bit to discuss the philosophy on them.

[jsweet]

Haha, No problem! I really like learning more in depth labVIEW 'things' or philosophy as well.

It appears that I also seemed to change my text without thinking. I meant "Really the architecture ISN'T too complicated."

I was talking with a coworker and he didn't like the idea of me not using the document either. I think I'm kind of in agreement with both of you now. His stance was that there's no reason to change two different sources of documentation and doing so is just asking for more problems.

Also we were talking about the context help for a wire and think it's sort of a object oriented thing. Like maybe the wire context help is just showing the wire's class? When you have an indicator or control now you have an object and thus have a context menu with descriptions. I'm not sure, that's just my brain's way of looking at it.

I think what I was really after is a solution to me not having to do documentation. It'd be really great if LabVIEW could just automatically document all of my code... HA!

I also like ben's idea of doing it in an LVOOP way. I hadn't thought of that before.