Global key expression builder vs legacy

Technical Support & Bugs
1

I apologize if this is already a know bug/issue (feature…), but I just noticed that a global key command written in the old style as follows:

Matching Properties: CurrentZone=$Dummy$

is parsing for Dummy the value of a variable with the same name on the piece where the global key is (source).

However, when using:

Matching Properties: {CurrentZone==Dummy}

it looks like Dummy is parsed from the target piece.

That’s really confusing because {CurrentZone==Dummy} is exactly how CurrentZone=$Dummy$ gets translated in automatic from the Expression Builder and one would expect identical behaviour.

I tried

Matching Properties: {CurrentZone==GetProperty(Dummy)}

but that seemed to match nothing at all (neither reading Dummy from source nor from target).

2

Hi.

First up, GetProperty() requires a string argument, so {CurrentZone==GetProperty(Dummy)} should be {CurrentZone==GetProperty(“Dummy”)} which should then return the same results as your first two options.

There is a bit of an oversight in the GKC handling. Any $property$ references are always evaluated before an expression is sent to the target piece for evaluation, but there is no way to force this in the {} notation except by continuing to use $property$.

So, I believe what you need is

{CurrentZone=="$Dummy$"}

Regards,
Brent.

3

Thanks Brent.

It’s not mission critical to me now (as the legacy CurrentZone=$Dummy$ works perfectly), but take note that I just tried and {CurrentZone=="$Dummy$"} does not seem to work either.

P.S. More precisely what I am actually using is something like

Class=Card && CurrentZone=$Dummy$ Market (legacy, working)

vs

{(Class==“Card”) && (CurrentZone=="$Dummy$"+" Market")} (not working)