Recently, (while uncovering a browse related bug) I ran into the following scenario:
You can set object properties on a "stand-alone" browse (created in the CP browse tab), and the properties (USUALLY) "propagate" into the form where the browse object is placed. ~ And when editing the form, some of these (SAME) settings are available on the browse objects properties.
I noticed that when certain object properties are set at the browse level, this information is "respected" once the object has been embedded into the form, when it is "run."
However: Upon viewing the object's properties (on the form itself) many of the same browse object option settings are available for editing/changing. But, the setting options shown do not "reflect" the objects actual settings. (So to see the actual properties settings of the browse object, you have to edit & view the browse itself from the CP browse tab.)
Seems to me these object properties should:
This is not the case whatsoever. There is no consistency or pattern that I can see.
The other associated problem here is: After you make changes to many of the properties (when you're editing the browse object properties from within the form) the settings are l"ost." (Change a setting, and save. Then go back and look for the setting. It was not saved.) ~ One would think that if the setting is editable, any changes should should be saved. (If you try to change the browse object's settings from the form object on the form itself, the settings "do not take.")
Note: In other parts of the a5 program (such as when dealing with tables/sets), "object inheritance" is respected.... When you make changes at the set level, the changes do "propagate" to the table itself. (This is what happens when you're editing field rules via a set. Although in this instance, I believe it's not actually "propagation." ~ You're actually making changes to the table settings through the set.)
You can set object properties on a "stand-alone" browse (created in the CP browse tab), and the properties (USUALLY) "propagate" into the form where the browse object is placed. ~ And when editing the form, some of these (SAME) settings are available on the browse objects properties.
I noticed that when certain object properties are set at the browse level, this information is "respected" once the object has been embedded into the form, when it is "run."
However: Upon viewing the object's properties (on the form itself) many of the same browse object option settings are available for editing/changing. But, the setting options shown do not "reflect" the objects actual settings. (So to see the actual properties settings of the browse object, you have to edit & view the browse itself from the CP browse tab.)
Seems to me these object properties should:
- Propagate (and show the current settings correctly since they are inherited) correctly from the browse itself to the browse object on the form, AND......
- Either not be editable (in which case the properties would have to be set on the browse object itself from the CP, OR be editable (so that the settings can be overridden).
This is not the case whatsoever. There is no consistency or pattern that I can see.
The other associated problem here is: After you make changes to many of the properties (when you're editing the browse object properties from within the form) the settings are l"ost." (Change a setting, and save. Then go back and look for the setting. It was not saved.) ~ One would think that if the setting is editable, any changes should should be saved. (If you try to change the browse object's settings from the form object on the form itself, the settings "do not take.")
Note: In other parts of the a5 program (such as when dealing with tables/sets), "object inheritance" is respected.... When you make changes at the set level, the changes do "propagate" to the table itself. (This is what happens when you're editing field rules via a set. Although in this instance, I believe it's not actually "propagation." ~ You're actually making changes to the table settings through the set.)
Comment