You can't put IIF(Atest.qty > 1, 255, 0) directly into the forecolor property of anything displayed in the grid, as it's not a DynamicXYZ property, only the dynamic properties are evaluated dynamically during grid refresh/draw repeatedly. Every other property will only be evaluate once at init and that's not enough. The IIF will be evaluated as one of it's two alternative values and that'd be set once and for all rows. The backstyle_access just coincidentally is one of the event like methods you can use because the grid itself calls into it, when it exists, When it not exists, the grid does read the backstyle property, which in itself is not dynamic (so the trick actually is, that any read property can be used as event by defining an access method, if you know it's read). You can't make Forecolor dynamic in the same way, when you define a Forecolor_access method, because the grid only accesses the backstyle, it doesn't access the forecolor of grid column controls, the Draw method must do it, because of cause the forecolor of things must be used for drawing them, still not every read has the same event driven nature, if a property is not seen as dynamic, reading it once is enough to know it, isn't it? So we can assume many things are only read once and then known as what they are. We don't really have that much insight into all things happening behind the scenes, but when trying forecolor_access and not succeeding you can make the assumption it's not read for every row drawing, as simple as that.
That backstyle_access works is kind of a hack or leak of info from the VFP team (RIP) and/or a discovery of simply trying it out. So it has become one additional quasi dynamic property, but of course any dynamic behaviour depends on what the grid itself natively does, you can't force anything upon it, just by setting properties to IIF expressions. Any normal property just evaluates such expressions (everything starting with = indeed, not only IIFs) but only once at initialsation. Such expressions are not working as dynamic as - giving another example - filter expression do, so the dynamic properties are an exception to the rule, just like the expressions you set on a workarea via SET FILTER are an exception, you also can't SET FIELDS TO IIF(....) and expect a browse to show differing fields per row depending on conditions per certain field values.
And in regard to the Dynamic Properties, you can also make a call to a method in there, it doesn't need to be IIF or ICASE, those are just the simplest expressions, which can evaluate to different results dynamically. You could also set DynamicForecolor to a certain constant RGB value, but then you may also simply set the normal forecolor to that value. This all is mainly controlled by the dynamic nature of dynamic functions and backstyle_access is kind of a ´black sheep of this family. It's that, which is causing the dynamic reevaluation, not the IIF function, not having any expression. If you want to do the same with any other property, you would need to define an extra property for the expression and at runtime, when needed set [tt]object.property=evaluate(object.expressionproperty)[/tt], that would be all code needed to replicate this behaviour, but you need any kind of trigger for this code, any event happening or at least a timer. Dynamic properties are triggered by drawing the grid rows, that's simply their base behavior. What we can't do in VFP is define such base behaviour, we can only react to events, not define/declare and cause them. Even the backstyle_sccess usage is just a hooking into the already existing events and things happening, it's making use of the grid reading that property not only once, but everytime a grid row is drawn.
Bye, Olaf.
