Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

document typedef control

Solved!
Go to solution

hello,

 

if I document a typdef control, I can see the new description when I hover the mouse cursor above it in the project lister, but I see the info: "no description available" when I do the same in a subVI where I droip the same control in the BD.

 

Is this a bug? LV2012 full version.

0 Kudos
Message 1 of 12
(8,403 Views)

@Blokk wrote:

hello,

 

if I document a typdef control, I can see the new description when I hover the mouse cursor above it in the project lister, but I see the info: "no description available" when I do the same in a subVI where I droip the same control in the BD.

 

Is this a bug? LV2012 full version.


That is going to need an examle demo to verify.  BUT, the wire should show the datatype not just the constant!  Are you using VI Documentation or Tip-strips and discriptions on the control type def?


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 12
(8,391 Views)

Hello. So what I play with, is a simple typdef enum control with two states (attached, LV2012 version).

I started to experiment with this behaviour:

 

1.

I have the typdef ctrl created, and dropped on a subVI. If I click on "open type Def." to open the editor ctrl window, and right click on the enum control itself, I can set two properties in documentation:

"Description" & "Tip strip". If I set some text in these fields, the context help gives me the proper info, and also the tip strip is active, but ONLY when I am in the typedef window editor mode. After saving these text fields, and close the typdef editor window, the dropped typedef control in the subVI does NOT give any description or tip strip.

 

I also tried to save it as strict type, does not change this behaviour.

 

2.

What is interesting, I can get a slightly different menu settings, if I do not click on the enum in the opened tydef window, but I go to the top menu, "File --> control properties--> Documentation", here I see these fields: "VI description", "Help tag", "help path". I also fill this text field, which looks independent to the above "Description" field.

 

Same result: with all the text fields filled, the dropped instance of the enum typdef inside the subVI does not give any doc info with the mouse above it (neither on FP, neither on BD)

 

3.

If I right click on the individual enum typdef inside the subVI, and there I set the documentation field, It starts to "work" however...

 

So as I see, if we create a typdef (strict or not) control, and we use its copies in subVIs, the typdef does NOT carry the documentation data with itself. Is this intentional behaviour? I can imagine that the programmer want to set different docu text to the same enum typdef used at different locations in subVIs...so maybe this should work this way? But at least the strict type should carry ALL the data with itself, also documentation, but it does not...

0 Kudos
Message 3 of 12
(8,385 Views)

OK I think I see what you are seeing.  a BD constant does not have documentation.  Create a control or indicator and your documentatoin is applied. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 12
(8,373 Views)

@JÞB wrote:

OK I think I see what you are seeing.  a BD constant does not have documentation.  Create a control or indicator and your documentatoin is applied. 


No, I tested a typdef enum control, not a constant! Did you read what I wrote? 🙂

As I wrote it, I CAN set documentation for the typdef control, but the typdef does not carry over the info when I drop an instance on the BD.

 

EDIT1: I try to simplify my description:

 

1. Create a enum control, make it a typdef. Save it into your project. Start to use it multiple places in your main VI / subVis. After a while, you decide, you want to set documentation info (description) to this typdef control. You open your typdef, and write a description. You save your typdef ctrl, and close it.

 

2. You go to your BD, and check the dropped CONTROL instances of your typdef enum with the context help turned on. Nothing, you do not see any description...

0 Kudos
Message 5 of 12
(8,368 Views)

I see what Blokk is saying.  If I drop this on the BD I get a control with the description and without the tip-strip.  The tip-strip is visible on the FP, however.  If I convert the control to a constant, the description and tip-strip are lost.  If I right-click and select "Description and Tip...", I can set these and see the description, but not the tip.  If I access the constant's documentation via the Properties window, I can set both but neither are visible on the BD.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 6 of 12
(8,361 Views)

but try to reproduce my problem following my points 1-2. So first create a typdef without any description. Pull this control typdef on your BD.

Go to your typedef and set description an either way. This description will not appear, the info is not updated on the already dropped typdef enum controls on the BD. Even if the typdef is a strict typedef...

 

So, if someone wants to document his/her typdefs, he/her must do it ONE by ONE in the whole project. I think this is silly. Setting doc info for a typedef should update ALL BD instances (controls). At least if we use strict tpydef. but either I use strict or normal typdef, this just does not happen...

0 Kudos
Message 7 of 12
(8,357 Views)
Solution
Accepted by topic author Blokk

Hi Blokk,

 

I tried to reproduce your steps 1-2 in LabVIEW 2014. Here's what I've found:

 

If I use the type def a few times on the front panel and block diagram, then edit the TD description and save it as a Strict type def, all control/indicator instances update to have the new description and tip strip.

Constants on the block diagram do not update to include the new description and tip strip. 

 

If I do the same process but save it as a regular type def, I don't see the description and tip strip update anywhere. However, new control/indicator instances of the type def do include the description and tip strip.

 

Let me look deeper and see if this is expected behavior.


Daniel

Daniel Hays | Test Software Business Manager
Message 8 of 12
(8,349 Views)

hello,

 

I confirm it, if you write the documentation to the typedef (via rightclick on the opened typdef enum control, and click on properties), and set it to strict typedef, it will update all the controls. The doc info stays with the controls even if you set back to normal typdef, so I think this is OK, at least for me 🙂

 

Strange that I did not get this desired behaviour with strict typdef, I guess I did the steps in the wrong order...But now it works 🙂

Thanks,

Regards,

0 Kudos
Message 9 of 12
(8,342 Views)

P


@Blokk wrote:

hello,

 

I confirm it, if you write the documentation to the typedef (via rightclick on the opened typdef enum control, and click on properties), and set it to strict typedef, it will update all the controls. The doc info stays with the controls even if you set back to normal typdef, so I think this is OK, at least for me 🙂

 

Strange that I did not get this desired behaviour with strict typdef, I guess I did the steps in the wrong order...But now it works 🙂

Thanks,

Regards,edit for" feedback on the forums" hit the quote key and the keyboard will come up.

 

Break

 

I'm sorry for having to go off topic on that I needed to make a note to self strict type definitions are handled as controls on the block diagram strict type definitions contain lots of properties that are not applicable to the block diagram like tip strips.

 

this is expected behavior and reading the documentation help file will help you understand it.

 

On the other hand strict type definitions on the front panel contain all of the properties of the strict type definition a non strict type definition will also include VI documentation and description but not tip strip. Tip strips are intended to tell the user how this implementation of that type definition will affect the behavior of this VI. Expected behavior I would not expect to see a bug report.

 

 

 

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 12
(8,329 Views)