Stefan.

dealing with Dynamics for years I think this is nice for readability - but worst for performance. It will call the method over and over and this will slow down the grid to much.

If one is not shure what the dynamics are doing, one should not use those property editor but strings or even better TEXT TO

TEXT TO allows some structured way to create the statement and one can eleminate unused signs (CR LF Space) from it.

I avoid THIS[FORM] in the dynamics I simply rewrite the dynamics if THIS.property changes. If you put the change of the dynamics in some method of the grid and eventbind it to the property its very fine to use.
(this keeps the dynamics short, what is the best idea anyway)

Agnes
>>As someone said, the problem may lie in the fact you're using this in your expression. What this is referring to?
>
>My statement was ambiguous, sorry.
>What I meant was that readibility of an IIF()/iCASE() expression inside a property is worse than a multi-line method anyway.
>And that additionally the fact that "This" inside a grid.Column.Dynamic* expression refers to the grid, as opposed to the Column, is not extremely obvious.
>
>So I believe it might be safer and easier for the OP to reduce the .Dynamic* expression to something like "goApp.something()" or "This[form].myMethod()".
>In that method he could care for availability of object references and might also get rid of any Public/"private" variables.
>
>
>
>Regards
>-Stefan