I'm trying to create automatically prop with expression from an addon. I checked the examples and which is able to CONCAT strings. I would like to use values form AC is it possible to indicate AC params in Expression over the code.

What I found out is that simple copy paste of values gives:
{Property:Zone/Zone Category}
xml export gives guid:
{Property:C55E9728-EB60-40A2-AA76-77B061FA4ADA}

I would appreciate the suggestion for this problem. Our expressions are growing and it's hard to manage them with builtin editor - especially that it doesn't save editing info like enter, tab etc.

In attachment one of longest definitions so you can see how problematic it can be. We decided to make it as property expression not script because it used to be easier for other team members to modify simple stuff.

Sorry for low resolution but there is sensitive info for the project so I'm obliged to make it unreadable. If anyone is interested in what it does and how it works I'm happy to make and share the modified neutral version. Let me know.

I agree that you just demonstrated the fallacy of inventing a new language over using a script language like -- Python for expressions. But more of a problem is the limitation of data access in expressions and the restriction of expressions to only one element and one return data value..

However, there are two approaches to mitigate your long Expressions. You might try breaking up the expressions into smaller ones which calculate only parts of the formula. Then bring them together using one or two final expressions using those smaller Expressions. Expressions can reference Expressions. The downside is that the applicable element must reference all expression parts whether there needed or not, which can become cumbersome. But they can all be grouped into one grouping. Also, It may be possible to use the sequence feature in the expression, whereby the program selects the applicable Expression based on element type. if you were more definitive in your problem, you would get more suggestions. Using the addon API to create expressions would be counter- productive. The problem there is that Expressions and properties contain a unique GUID embedded,which Graphisoft has not chosen to reveal the format, at least, not yet. IMHO.

On a side note, you can use a external editor and copy/paste the result by including the directory path of the properties. The Expression editor, upon reading it will automatically choose the correct property and GUID.

That's true I suppose it's some safety reasons for it . Still, it's better to have expressions than before. We used to do even simple CONCAT with addon .

I would also add lack of support for list and tag type properties.

poco2013 wrote:try breaking up the expressions into smaller ones

This is what we actually do. We are trying to encapsulate some functionalities in numerous properties Espattialy for conversions, text manipulations etc . This example, however, is one big IF statement choosing different categories based on element names and other properties.

What we actually do for editing this stuff we use Notepad++ and copy paste expression. This helps to track closing functions.
The reason I would like to know how it works and how property is referenced is Idea for a custom editor for expression so we can prepare our own tool for building up and edit more complex logic.

Hi Akos, Yes I have checked both examples in AC22 DevKit. As I mentioned in the first post I have tried to use this kind of referencing property in function based on SimpleTestPropertiesWithExpressions().

It didn't work out. Without referencing property it was working. If you are asking I suppose that it should work with this syntax {Property:Property_Test Add-On Group/Property2}
I will double check that then. Thanks.

Hi Akos, Yes I have checked both examples in AC22 DevKit. As I mentioned in the first post I have tried to use this kind of referencing property in function based on SimpleTestPropertiesWithExpressions().

It didn't work out. Without referencing property it was working. If you are asking I suppose that it should work with this syntax {Property:Property_Test Add-On Group/Property2}
I will double check that then. Thanks.

Thanks, I figured, just to be on the safe side

The original plan was to make it simple, so theoretically it should work with the readable expressions. Tell me if it fails...

We added to functions that may help: ACAPI_Goodies (APIAny_CheckPropertyExpressionStringID, ...) and ACAPI_Goodies (APIAny_GetPropertyExprReferenceStringID, ...).