Let's say I have this form with fields X, Y and Z, where

- X is a data field

- Y is symbolic and dependent on X

- Z is symbolic and dependent on Y.

Let's say I have a programmatic process that changes the content of X. Then I know I might have to send a CALCULATE message to Y and Z to get their visible contents to reflect the changes.

But is the order important? Must I send CALCULATE to Y before Z? I assume so. But I'd like it verified.

The reason I ask is I'd like to make a general function to update calculated fields in a form. The function can easily find out which calculated fields are present in the form, and which controls and edit table columns are involved. But if I just let my function go ahead and send a CALCULATE to each field in turn it might do it in the wrong order.

It's tempting to make the function run through the fields two or three times instead of just once. (In the above example with X, Y and Z, Z might fail the first time if done before Y, but not the second time.) Unless there are long chains of dependencies that should take care of the problem. But it's a bit crude.

Comments, anyone?

- Oystein -

Oystein ..

AREV offers symbolic recalculation based on dependencies as an option. I found this problematic and sometimes unreliable, but nonetheless it WAS attempted. I don't think this option is available in OI, though. FYI, I try to avoid dependent symbolic recalculation at all costs, if possible since it's possible to get stuck in a recursive loop. You could develop a general function that would send a recalculate to a form in the order provided by the programmer:

FUNCTION RECALC_SYMBOLICS(FIELDS)

Where FIELDS is a @FM delimited list of Fields to be recalculated and the order to perform the recalc. I think it could then update a form properly and return a flag for success or failure or somesuch. In fact it could probably return a null without harm.

The trick would be to get access to the form, but getting the properties of Parent should do that.

Don't know how efficient it might be. It is also possible that your form will do its own recalculation too. If you are setting the value of a field programatically you might be able to avoid recalculation by avoiding setting the DEFPROP or INVALUE property.

Don M.

Don,

FUNCTION RECALC_SYMBOLICS(FIELDS) Where FIELDS is a @FM delimited list of Fields to be recalculated and the order to perform the recalc.

My first thought after reading your reply was that this means a lot of lists to set up. There are not so many tables, but some tables have very many fields, and for some tables there are very many windows (child windows containing various subsets of the table's fields), and I might add more windows later (variations on the existing ones). So there will be a lot of windows to make lists for.

But of course I don't need more than one list per table. It doesn't matter if the list contains fields that aren't in the window. That's probably what you meant.

Hmmm……..

- Oystein -

Oystein ..

The problem isn't symbolics, per-se. It's the order in which the recalculation has to be done and possibly recalculating symbolics which are NOT on the form, but that need to be recalculated prior to some that ARE on the form (that's a real bear, IMO). Obviously, you can the the attributes of the fields in a template (or parent, if need be) and isolate the symbolics. The problem is the one of dependency and I don't know a way around this one except brute force.

Don M.

Don,

The problem isn't symbolics, per-se. It's the order in which the recalculation has to be done and possibly recalculating symbolics which are NOT on the form, but that need to be recalculated prior to some that ARE on the form (that's a real bear, IMO).

I have cases like that. My solution is to put all the relevant fields on the form, but some of them hidden from the user.

- Oystein -

View this thread on the forum...