好吧，我想我们错怪了这棵树，很抱歉。
需要说明的是，您在AttributeCreator中，正在创作一个条件值，而这个条件值必须是数值条件值。那么您已经选择了算术编辑器。你也要在里面创建一个条件值，使用?:语法。>
Takashi是100%正确的，我们的算术编辑器的文档参考了C手册，这不是我们应该做的。我们使用Tcl的expr来计算上述表达式。因此，我们应该更新我们的文档，将操作符定义改为引用Tcl expr。我们将为更新提交一份PR。
也就是说，自动引用的问题是一个很有趣的问题。 Because FME is NOT a strongly typed environment, in general we do not know what we're going to get when we access the value of an attribute. This lack of strong typing is part of the power of FME, because it enables such flexibility.
But there is a cost to that flexibility and power, and that is that, for more complicated situations such as this, the quoting burden is put upon the workspace author. Our job, which we are striving to do better at, is to provide the best possible documentation to guide such an author so they know how things will be parsed and interpreted.
Short answer -- I can't see how we ever could safely inject { } around Value( ) calls, but I'll ask the team. (Would there be any harm in always doing it? That is what we'll figure out).
And I have to rush off now to an interview for an additional technical writer for our team to help us do an ever better job of relating the ins and outs of these dark corners of FME. (Yes, I'm serious!)
Thanks for pointing this out @gio .
Dale
您好，没有我没有指的是
我指的是解析错误。
使用可变字符串作为操作数可导致章第解析错误在TCL，最常见的，当有字符串中specialcharacters。采用双qoutes aleviates当有字符串中的某些字符以外的问题。（所以在这一点u能在在正则表达式...所使用的属性仍HEVE的regexp）使用括号告诉了reg引擎使用一切内部为一个字符串。
上面的逻辑查询，现在将失败除非你强迫它看到变量的内容作为一个字符串，即使用大括号。（前fme2015这会工作不括号）
如果在上述表达式中@Value（区域）= A，则表达式将产生起始A == A中的表达式字符串||等等。没有括号的第一个A没有被识别为一个字符串，：结果错误无效裸词“A”。。一个解析错误
下面有一个例子错误日志
AttributeCreator_2：无法评估的算术表达式“（B2 == {A} ||（{B2} == {} B1 && {FASE3} == {FASE1}））300：200'
AttributeCreator_2：TCL错误消息：
无效裸词 “B2”
在表达式“（B2 == {A} ||（{B2} == {} B1 && {。..“;
应为 ”$ B2“ 或 ”{} B2“ 或 ”B2（...）“ 或...
AttributeCreator_2：未能评估函数 '（B2 == {A} ||（{B2} == {} B1 && {FASE3} == {FASE1}））300：200'
无法评估数值表达式“（B2 == {A} ||（{B2} == {} B1 && {FASE3} == {FASE1}））300？：200' 。结果被设置为空。
...我除去在第一操作数中的括号以迫使上述错误。
你 can see all variables (operands) enclosed in braces do not yield this error.
This is not a matter of regengine flavors.
Fme should know the content of the variable is a string, so one should not have to enclose the variable name like {@Value(ZONE)} or "@Value(ZONE)"...or so i think.
Different regengines is more of a nuiscance then a real problem. Parsing errors are a more serious problem.
@ Takashi: "==" is not a math operator, it is a logical operator.
And why is that the best answer?? I'm confused...;)
喜吉奥，可能你指的是FME使用在不同的地方不同的正则表达式引擎的事实。它是在发展的计划，以巩固这些。我们会通知您，当工作完成。