Getting typedef comments using VI scripting

[BertMcMahan]

I'm writing some code to programmatically read all FP and BD comments on a VI. This works fine on my test VI, but doesn't work on typedefs. For whatever reason, Traverse for GObjects doesn't see the comment on the FP of the typedef:

Additionally, calling the property VI.Panel.AllObjects doesn't return any references to a comment on the "front panel" of the typedef.

Is there another method I should be using for a .ctl? This method seems to get everything else on the "front panel", so it seems like it "should" work, but it clearly isn't doing what I think it is.

Example code attached, backsaved to 2021.

[paul_a_cardinale]

Strangely, that comment is owned not by the front panel, but by the numeric control.

But knowing that hasn't helped me figure out how to get a reference to the comment.

[aeastet]

I'm not sure what you are hoping to do with this info, but there is a mechanism that NI has to find comments in your code. They are call bookmarks. If you put a comment on you code and you place a # sign in front it will leave a bookmark. You can then call the bookmark manger and go to those comment later.

Here is how to get to the bookmark manager:

It will open this window so you can navigate back to these later:

not sure if this helps or not but there is a built in mechanism.

[BertMcMahan]

Thanks, Tim. I'm actually trying to automate some documentation on some code I inherited, not anything that I made. I'm trying to pull in all text on all front panels and block diagrams to scan for some key information, so the bookmark manager isn't the right tool here. I'm basically making a tool to scrape all labels, comments, bookmarks, VI descriptions, help tip strips, string control default values, etc. and make a giant list of all of the data given on the VI's.

My task is conceptually similar to looking for any and all copyright or license claims that may be on some VI's. It's not exactly that but it's very close. There are hundreds (maybe thousands) of VI's to look through and they could've put this information in a number of different places, so automating it is the way to go. So far I think I can scrape everything I need, EXCEPT for comments on typedefs, and those I can just do manually if I can't find a scripting tool that works.

[Kyle97330]

I've only been able to get a reference to it one way and it's not very helpful...

I find that if I make a "Quick Drop" plug-in using the template, and select just the comment label on the typedef's front panel, then the output of the "SelList[]" property does indeed contain a reference to the Text object.

However, attempting to repeat this in a context other than QuickDrop never results in returning that reference.

Best hypothesis I have is that since a "legal" type definition can only have one top-level object on its FP, LabVIEW hides anything else from the execution system when it runs in a normal context.  But when running in the "editor" context that QuickDrop runs in, it allows the extra objects to be seen.

[paul_a_cardinale]

Here's a kludgy idea:

1. Get the Total Bounds Rect of the control on the typedef's FP.
2. Divide that area into blocks (maybe 20x20 pixels for each block).
3. For each block:
   1. Simulate a mouse click on the block.
   2. Check the selection list for a text object.
4. Filter out references to labels and captions.

What's left should be references to floating text.

[Yamaeda]

Using a normal Front panel Get all Objects[] or Decorations[] doesn't return the comment (in my test .ctl), so i guess it's not classified as a GObj?

[raphschru]

---

@Yamaeda wrote:

Using a normal Front panel Get all Objects[] or Decorations[] doesn't return the comment (in my test .ctl), so i guess it's not classified as a GObj?

---

It actually is a perfectly "legal" GObject. If you find its UID (e.g. using a right-click plugin), you can open it using "UID to GObject Reference.vi" and cast it to a Text refnum.

For a .ctl, it appears any free decoration is owned by the firstly created top-level control, instead of the front panel itself.

I guess this allows to have a single object to update when LabVIEW applies the type definition to the instances.

The downside is that the refnum of such decorations is not (easily) accessible, unless you decipher how LabVIEW assigns UIDs to newly created GObjects in the ctl...

Regards,

Raphaël.

[Yamaeda]

---

@raphschru wrote:

---

@Yamaeda wrote:

Using a normal Front panel Get all Objects[] or Decorations[] doesn't return the comment (in my test .ctl), so i guess it's not classified as a GObj?

---

It actually is a perfectly "legal" GObject. If you find its UID (e.g. using a right-click plugin), you can open it using "UID to GObject Reference.vi" and cast it to a Text refnum.

For a .ctl, it appears any free decoration is owned by the firstly created top-level control, instead of the front panel itself.

I guess this allows to have a single object to update when LabVIEW applies the type definition to the instances.

The downside is that the refnum of such decorations is not (easily) accessible, unless you decipher how LabVIEW assigns UIDs to newly created GObjects in the ctl...

Regards,

Raphaël.

---

Well, using Traverse for GObject in the .ctl didn't find the Text either.