Object Parameters in Labels

[James Murray]

[Pardon the length of this. I'm posting it in chunks to reduce fatigue. I hope answering is easier than asking!]

The big topic is having a label display an object parameter's value. The specific goal is labeling a structure member in section. Here goes...

Structure member documentation Requirements:
• Display in plan with descriptive text
• Model in 3D to proper dimension based on size/specification and unit quantity.
• List by descriptive text
• ID is used to key in calculations.
• Label in section.


Current solution:

parameters:
mem_typ (ABC, Name of the shape)
qty (Int, Number of members)

The object contains dimension data for various shapes.

The plan is no problem. The member can be drawn as a line, or as a rectangle of the proper width, calculated from unit quantity x unit width. The descriptive text is a string, built from the quantity and specification/shape. It is not a Label element.

The 3D model is also finished, it's merely the right number of shapes of the right size.

To list the members, a parameter is needed, "desList". (In my libraries, "des" means "designation". I use this for any object that has to assemble its own description.) This parameter is filled by a PARAMETERS statement: PARAMETERS desList='('+STR(qty,1,0)+')'+mem_typ. It is simply the parameterization of the descriptive text string in the 2D symbol.

The ID is put in manually. It rarely changes. The ID number refers to a specific instance of a member, not to a configuration of size/quantity. The size/quantity may change, but the ID will stay the same.

Labeling in section is done manually. In the past we used a text block, now we use a text label. This the problem area. Every member has to be labeled in every section. Change management becomes prohibitive and risky. I can't use the ID, since not every member has one, but they all need to be called out. This leads to the new requirement...

[James Murray]

New Labeling Requirement for Section:

A Label to read the "desList" parameter out of the member object, to be placed in section. The Label would automatically update when the "qty" or "mem_typ" is changed.



Trials and results:

My investigations lead me to believe that there are two methods in GDL for passing parameter values from an object to a label: the Free Users' Globals, and REQUEST("ASSOCLP_PARVALUE").

I have written a simple label based on one the GS labels, and tried writing text based on both methods. In testing the two methods, I spend a lot of time tripping over oddities in the label tool itself. (The subtle difference between placed labels and associated labels. Only associated labels can display ID. Why? Sometimes checking the 'Label Elements' box does nothing. The 'Label Settings' button is ALWAYS greyed out except for default settings, so the only way to get the settings of an associated label is to select the label itself. The label subtype seems to take care of drawing the arrow, since there's no code for it, but sometimes the arrow is not drawn, for no apparent reason. The LABEL_POSITION array is absolutely mystical. Shouldn't it contain the three points clicked when placing the label? I guess not.)

Globals:

There is virtually no documentation of user globals, other than the list of their names. So I just jump in. In the member object's master script, I have the statement: GLOB_USER_15=desList. In the label's 2D script, I have the statement: TEXT2 0, 0, GLOB_USER_15.

(I also tried naming a parameter in the object GLOB_USER_15, and then writing GLOB_USER_15=desList : PARAMETERS GLOB_USER_15=GLOB_USER_15. This didn't solve any of the issues described below.)

This works a small fraction of the time, and I have exhausted myself trying to trace the permutations of various settings to figure out what exactly causes the fraction to work.

These three cases refer to the plan.

1. Associated label on a placed object, i.e., select the object and check the label box: The label displays some default value from the beginning of my experiments, which bears no relationship to the placed object. Rebuild & regenerate does not correct the data. The only way to make the label correct is to change the object then do the R&R.

2. Placing a labeled object, i.e., setting up the label in the default settings, checking the box, then placing the object: The label is correct, but the arrow does not draw. Changes to the object are not reflected in the label until R&R.

3. Placing a label with the label tool: The label contains a different, default, unrelated value. R&R does not fix it. Changing the object followed by R&R fixes the label.

In the section, which is, remember, the goal, the results are even worse. Updating of associated labels is erratic, and sometimes fails even after changing the object/R&R. Updating of placed labels ALWAYS fails.

Summary: In the plan, updating is very burdensome, but not impossible. In the section, updating fails utterly in many cases. From a user standpoint, the technique is a complete failure. Requiring an R&R means human error. Requiring fiddling with the object is insane. The differences between placed and associated Labels are confusing and inconsistent. Any reasonable person would run screaming back to the dumb text-Label solution.

REQUEST("ASSOCLP_PARVALUE"):

This is easier to describe because I simply could not get it to work at all.

I have the REQUEST statement itself working, insofar as I don't get an error. I have tried the following in various scripts. The 2D code is TEXT2 0, 0, desList:

1. xx=REQUEST("ASSOCLP_PARVALUE", "desList", nameVar, typeVar, flagsVar, dim1Var, dim2Var, desList)

I read somewhere that the label has to contain the parameter being read, so:

2.!create a parameter desList, to match that in the object
xx=REQUEST("ASSOCLP_PARVALUE", "desList", nameVar, typeVar, flagsVar, dim1Var, dim2Var, desList)

2a. !as above, then:
PARAMETERS desList=desList

I tried using a temporary variable, different from the parameter name:

3. xx=REQUEST("ASSOCLP_PARVALUE", "desList", nameVar, typeVar, flagsVar, dim1Var, dim2Var, newName)
2D: TEXT2 0, 0, newName

For all cases, the displayed value is null, empty. In the words of someone, it isn't right, it isn't even wrong.

I also tried reading other, ordinary parameters such as "A". No go. I tried reading other returned values, for example, if I try to get the parameter type, it always returns zero, which isn't a type.

I tried some GS labels that contain the REQUEST, and they don't work either, so I know it's not just me.

[James Murray]

I have found limited discussion of this issue here and in GDL Talk, which is the only way I could get as far as I have. That the discussion is so limited means either that it's hopeless or that it's so easy that everyone else has figured it out. If anyone counts themselves in the second group, I'd really appreciate some tips on REQUEST("ASSOCLP_PARVALUE"). The globals are deeply twisted and I'm inclined to abandon them.

Finally, I can't resist a mini-rant. The label tool is just awful. What I'm trying to do here is basic Virtual Building. AC should be able to this standing on its head, with no gymnastics from the user. The tool isn't good enough to "just work", and the documentation isn't good enough for a GDL-experienced user to customize a solution after a day of trying. Both problems need serious development attention. Something so simple shouldn't be so complicated.

Thanks for listening,

[Anonymous]

James wrote:
Finally, I can't resist a mini-rant. The label tool is just awful. What I'm trying to do here is basic Virtual Building. AC should be able to this standing on its head, with no gymnastics from the user. The tool isn't good enough to "just work", and the documentation isn't good enough for a GDL-experienced user to customize a solution after a day of trying. Both problems need serious development attention. Something so simple shouldn't be so complicated.

Thanks for listening,

Hi James, what a hard work! I feel your pain.
I did some experiments with the label tool, and i had to stop.
All worked fine in 6.5 and 7. With AC 8.1, it was the nightmare.
The label did not reacted correctly with rotations (for XY location label), this is a minor point,
but what is worth, clicking into the user interface caused a crash, always.

I have found that puting all the content of the parameter script into a master.gdl script solved the problem.
Don't ask me why an how this solution works, i don't have any tech support.
Mac or PC or AC feature, i still don't know.

Since i stop to use the label tool into scripts. Examples are avaible in the library below.
Just to say this tool is too much "versatile" for me, and sorry if this does'nt solve your problem.

[Frank Beister]

Hello James,

I will say nothing about the GDL documentation. I think there is every thing written down here and on many other places. ;(

First: I do not understand all your problems. So it would help, if you could send a small stripped off PLA with the testing object(s). I will deal confidential with it.

To the REQUEST("ASSOCLP_PARVALUE"). As far as I understand you try to transfer a requested value from an 'sender' object into a parameter (of the parameter list) of the label. I would try to avoid this, because (not only label-objects) do not have the full GLOB-Parameters information available, as they have, when 'run' in the plan. I don't remember which GLOB-Parameters do not work in label tool, but during programming a window label I found some lacks. I told it to GS. I don't know, if they have fixed it.

Maybe you can post some code to give more precise help.

[James Murray]

F. wrote:
To the REQUEST("ASSOCLP_PARVALUE"). As far as I understand you try to transfer a requested value from an 'sender' object into a parameter (of the parameter list) of the label.

Either way. I tried it with a matching parameter, and with a simple variable. I can't get anything but an empty result.

Here's what I'm doing:

For a wood beam, the user selects the member (e.g., 2x10) and the quantity (e.g., 2). The name of the member is a string parameter, "mem_typ". The quantity is an integer, "qty".

For listing, these two values need to be put together with some other text to build the description of the beam, e.g., (2)2x10. This string is put in the parameter "desList". This is done in the master script with

PARAMETERS desList='('+STR(qty,1,0)+')'+mem_typ

which is just the quantity in parentheses plus the member name. There's no problem listing this.

This is the data I would like to express in the section. Image attached of current method, using a text label.

I would like a label to read the "desList" parameter from the beam object, so when the quantity or the member type is changed (thus changing "desList") the labels in the sections update automatically.

ASSOCLP_PARVALUE seems like the way to go, but so far, no good.

Thanks for your help,

[Miquel Garcia]

Hello James

I am following the same way that you and with the same success: nothing. I have made a search and I have found your comments. Do you have further information about the use of ASSOCLP_PARVALUE?

I am a medium experienced GDL programmer, but this seems to be more than I can understand.

Thanks!

James wrote:

I would like a label to read the "desList" parameter from the beam object, so when the quantity or the member type is changed (thus changing "desList") the labels in the sections update automatically.

ASSOCLP_PARVALUE seems like the way to go, but so far, no good.

[Anonymous]

Hmm. I'm stumped. Your third example is the way I've used it in the past.

3. xx=REQUEST("ASSOCLP_PARVALUE", "desList", nameVar, typeVar, flagsVar, dim1Var, dim2Var, newName)
2D: TEXT2 0, 0, newName

I wrote the following quickie label to test the Request function in a label as I've only used it for property scripts in the past:

uValue = ""
n=Request ("ASSOCLP_PARVALUE", "gs_list_heattransfer", index, type, flags, dim1, dim2, uValue)

TEXT2 0,0,uValue

Where "gs_list_heattransfer" is a parameter from a window and uValue is my temporary parameter. It worked fine in the plan window and section window.

gs_list_heattransfer is declared in the variable list as a string, but it also worked for me returning "A" and another variable that was an integer number.

So in short it's working for me which isn't very helpful. I'd say that your PARAMETERS statement isn't being run but you've tried other simple variables so you should be getting something back from those. BTW I'd try to find a way around using the PARAMETERS function to set my value because I think it only runs when the library dialogue is open. Maybe the statement uValue = "" which declares the variable as a string? I don't think that's it. I assume your code is in the Master Script or 2D Script. Are you using your temporary variable someplace else?

[Miquel Garcia]

Now it works ! I have had a very stupid typing mistake. Thanks for your help.

[Anonymous]

Hi James
Did you ever get this all going? Ive just been doing it here and seems to work well (actually 1 bug? with editable hotspots getting their values from accociated objects).
Cheers
Mark