Did something get broken in R18 or am I just being dumb?

Here is the outline, I created a UDF and typed it which stored the .GScript to my ARm folder in "KnowledgeTypesCustom" see GScript Below.

So i now want to consume the new type in a rule so create the rule below and i get "Syntax Error line 10: invalid attribute used ; #__________" when i try and display any of my new feature attributes any standard mechanical feature attributes work.

Madaxe

 

Let MyList(List)

Let MyUDF(MyCylinderFeature)

MyList = `Part2`.Query("MyCylinderFeature",""

For MyUDF inside MyList

{

Message("#MyUDF.Name)

Message("#MyUDF.`BOSS O.D.`)      'BROKEN HERE

} 

---

 

UserDefinedType isa Package

{

MyCylinderFeature isa MechanicalFeature

{

`BOSS HEIGHT` = 0 , Type : `LENGTH` ;

`BOSS O.D.` = 0 , Type : `LENGTH` ;  'THIS ATTRIBURE DOES NOT WORK

`ROTATION ANGLE` = 0 , Type : `ANGLE` ;

`UDF Color` = 0 , Type : `String` ;

`Select Line` = 0 , Type : `Feature` NLSName : `Select Line` ;

`Select Point` = 0 , Type : `Feature` NLSName : `Select Point` ;

}

}

 

Spaces in the published attribute names always causes this kind of trouble for me.

The quoting rules for using parameters with spaces and quotes in the names are not very clear.

If you have to get at some previously written UDF you can use GetAttribute and SetAttribute methods.

udfX->GetAttributeReal("`PARAM WITH SPACES 2.0`")

But if you are designing new UDFs I suggest using underscores instead of spaces in published names. ---> BOSS_O_D

Yeah , i Have had that issue but i just tested that at home same issue see attached image

 

Madaxe

 

catiawidgets.net

Hello,

You have to use double quotes in this case (object."attribute containing forbidden characters").

Forbidden characters are the ones that may raise parsing problems.

Hi Knowledge,

which line are you refering, I ahve single quotes around the object.`attribute` this is a CATSetting, this should not matter?

 

Madaxe

Madaxe,

the name of parameters and objects containing such forbidden characters should be surrounded by backquotes. The name of attributes containing forbidden characters should be surrounded by double quotes if using object.attribute expression.

In any case, for parameters and objects, backquotes are always accepted. In any case, double quotes are accepted for attributes if using object."attribute" expression.

So you can write :

`Real.1` = 10 or Real.1 = 10
but you have write
`Real containing space`= 10

object."realattribute" = 10 or object.realattribute = 10
but you have to write
object."real attribute" = 10

in the CATGScript file, backquotes are used if the setting is activated or if the parameter role contains forbidden characters. They are not taken into account in attribute name computation

Hi,

I had this working in R16, doing the same but I now have to turn off in tools options "Surrounderd By Symbol" and it works fine see images.  Did something get broken in R18?

I understand what you are saying but this used to work or im going crazy.

what do you think?

Thanks for all the help, below this case works!!!

Madaxe

I'm not aware about changes in that part of expression management between R16 and R18. But it is possible that we have modified part of it.

Actually, I'm not sure to understand what worked in R16 and does not work anymore in R18 in your case.

Ok i just ran an experiment, if the

surrounded by symbol option is OFF

Attribute Name Containning Spaces

INCORRECT AND ERROR

For MyUDF inside MyList
{
 MyUDF.BOSS HEIGHT  = 20mm ' ERROR Invalide Attribute Used : Boss

}

CORRECT

For MyUDF inside MyList
{
 MyUDF."BOSS HEIGHT"  = 20mm

}

Attribute NAme Containning Special Characters

INCORRECT AND ERROR

For MyUDF inside MyList
{
 MyUDF.BOSS_O.D. = 20mm ' ERROR Invalide Attribute Used : Boss
}

CORRECT

For MyUDF inside MyList
{
 MyUDF."BOSS_O.D." = 20mm
}

CONCLUSION

It does not matter if the surrounded by symbol option is ON or OFF, as long as when the UDF is created in the parameters tab during the creation of the UDF the designer always changes the name of the parameter to remove the single quotes. Ther name may contain special characters and spaces, but if this UDF is typed then anybody consuming this type must remember to put double quotes around the attribute that contains special characters or spaces within the EKL statement.

Madaxe

 

I just realised that this is all about inhertance, encapsulation and polymorphism.

You encapsulate a UDF
You inherit when you type something
and polymorph during instanciationa and EKL (not sure about the last one)

Madaxe