Hi,
A similar expression question was move to the programming forum but I think expression are basic MicroStation functionality.
I really like expressions and what they (sometimes) can do. But I'm having some problems that I would like to have some feedback on.
I cannot get the expression ConfigVar.GetExpandedConfigVar("MY_VARIABLE") to work when used in an ItemType text attribute.I always get the Failure value when inspecting the element using the Property dialog.Missed anything?
If I use the expression this.Lokaliseringskod to the get the value from an other attribute (I will concat with other properties when this works)it works when I define the Item Type and properties in the file. If I export the file and try to import it the import will fail with "Illegal expression...".I wanted to test this since I create import files based on data from another system which works fine except for some expressions.
It seems that the parser sometimes uses the internal attribute name and it might be a conflict when expressions are matched to the displayed property names used in the Excel file.This leads to this kind of obscure syntax when I want to concat some fields (this works in the file but not when imported):this.Lokaliseringskod&this.Tillg__x00E5__ngssystem&this.Komponentkod&this.L__x00F6__pnummer
The following screen dump from an Expression Report also shows these weird internal property names instead of the displayed property names shoed in the Properties dialog.
/Krister
HI Krister,
Krister Surell said:Missed anything?
I think what you missed is that Named Expressions are not Item Types expression.
Whereas Named Expressions can use quite long list of symbols providers, for Item Types, the functions explictly defined in documentation can be used.
Internally Item Types expressions are subset of EC Expressions used in EC schemas. When EC property is defined manually (which is more complicated than to define Item Type property), it's possible to define what symbol providers (libraries) will be used. But I asumme Item Types contains predefined list of basic libraries that cannot be extended (at least now in Technology Preview mode).
With regards,
Jan
P.S. Because Item Types expressions are Technology Preview feature, maybe the best place where to discuss this issue is MicroStation Insiders forum.
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Krister Surell said:It seems that the parser sometimes uses the internal attribute name and it might be a conflict when expressions are matched to the displayed property names used in the Excel file
MicroStation tags have the same kind of problem, because tag names have few restrictions and lead to conflict with Excel naming requirements.
At least for now, choose undecorated US ASCII names. Don't put spaces in names. Don't use European characters. Don't use a hyphen as a word separator. Submit an Idea to permit use of non-US ASCII names, or — better — provide a DisplayLabel in addition to the property Name.
Krister Surell said:The following screen dump from an Expression Report also shows these weird internal property names
That's your property name with a Unicode substituted for characters that it doesn't like — even the hyphen.
It would be useful if an Item Type property were to have both a Name and a DisplayLabel, like most other EC objects. Then we could assign a Name restricted to US ASCII characters that is also Excel-compatible, and use whatever we like for the DisplayLabel.
I've proposed an Idea on this topic.
Regards, Jon Summers LA Solutions
Krister Surell said:It seems that the parser sometimes uses the internal attribute name and it might be a conflict when expressions are matched to the displayed property
Item Type properties, unlike other ECSchema objects, don't have a DisplayLabel. The problem arises because you want a Name that contains non-ASCII characters and MicroStation converts them to an internal name with Unicodes replacing those characters. Normally that doesn't matter because a user doesn't see that internal name. You've discovered a situation where the internal name is exposed to the user interface.
If Item Type properties were to have a Name and a DisplayLabel (like all other EC objects) then the problem could be made to disappear. The Name would be subject to constraints and the DisplayLabel could be whatever you like.
Jan, while waiting for being accepted in the Insiders forum I'll continuing the discussion here.
I looked in the list of expressions in the Tech Preview section (should have done this before!) and I found functions for getting cfg variabled. Great but why change the name of them? Also, I couldn't get several of to work either, eq MSTNvariable.GetVariable("MS_CELL").
Jon, I think Bentley really has to get this to work with the rest of the world as well. I'm trying to setup a BIM dataset and there are requirement on what properties should be named. Let hope for some quick progress!
Owner consultant at Surell Consulting AB
Eventhough I've done quite a bit of coding for Item Types I'm still a bit confused. I actually thought they had both internal name and display name. When you add a property to and ItemSet object (C#) using itemType.AddProperty() you get a CustomProperty back. That object has both a Name and an InternalName. Also in my example above what is displayed in the Properties dialog is a display name, not the internal name shown in the Expressions Report.