Ok. I figured it out and I can live with it, but a "for" loop to handle lists would be nice.
My script uses FieldNames(), ValueCount() and a loop.
"I do not want a long list of "set fields" in my init script. "
Every 'object' field which should be 0 can be reset to 0 without running through the fields. Create a global number, maybe called gUpdateTrigger (in your globals table). Since you have ONE record in globals, you can set this one global number and it can force update all fields which reference it.
Set up each 'object' field as Auto-Enter by calculation (REPLACE) and only put the gUpdateTrigger in the calculation result. Then in your startup script, go to layout based upon Globals and set gUpdateTrigger to 0. All 'object' fields will change to 0.
Added line in blue and struck out going to layout ... since gUpdateTrigger is global, it can be set from anywhere as all globals can.
Interesting idea, but I must be missing something. Each of the fields represents the dynamic state of an object. When an object comes into existance, the field is one. When it is destroyed, the field becomes zero.
In order to do this programmatically a script must be able to change the appropriate field from 1s to zeros and back when appropriate. If the fields are changed by auto calculation, how are they changed during run time? I understand what you mean by using this feature to zero the fields, but what about during run time when they have be be modifiable in unpredictable ways. My understanding is that calculation fields can only be changed by virtue of the content of other fields they depend on - right?
"Each of the fields represents the dynamic state of an object. When an object comes into existance, the field is one. When it is destroyed, the field becomes zero."
I am sorry, but I have no idea what you are talking about.
"If the fields are changed by auto calculation, how are they changed during run time? "
gUpdateTrigger is only used at start-up to set all fields to 0. It is not used again during the User session. Each object field should be type number (with auto-enter REPLACE calc) and not a calculation. If you do not change the data in gUpdateTrigger during that log-in session, the values will remain whatever you set them during the session. So set gUpdateTrigger to 0 at startup (which resets all object fields to 0) then set each field individually to 1 and even back to 0 throughout the session in your normal way and as you wish.
Added: Using an update trigger in Preferences is pretty standard practice; they are used to refresh global calculations as well. Also, you can set this gUpdateTrigger from any table occurrence in your solution - you do not need to go to a layout based upon Globals table. Since gUpdateTrigger is global, it can be set from anywhere as all globals can.