A question about the dynamic widgets such as the fill-in or labels ,
where are they stored in the icfdb? In which style are they stored?
Is there a runtime widget tree of a container , or other implemention of them?
Thanks so much for your help!
A very generic question...
Did you look at the Repository Managers reference? The ICFDB Reference?
Each object (object controller, DynView, Datafield (FILL-IN), etc.) is stored as an object (gsc_smartobect).
Each instance of an object is stored in the ryc_object_instance table.
Attributes of classes, objects or instances are storer as ryc_attribute_value records.
What do you want to do? When you try to read access information you should try to use the repository manager apis, for changing the information look for the repository design manager apis.
At runtime (in GUI) the widgets are realized as normal Progress widgets. One should, however, typically try to avoid using the widget-tree as a way to access these widgets, as it may not necessarily be aligned with the object’s own view of things; The physical name of the widget may not match the logical name (CLOBs). Field level objects may be objects in their own right in which case they have their own frame with their own widgets. There is no safe way to identify who owns a frame that is encountered in the widget tree (The INSTANTIATING-PROCEDURE attribute does not provide a solution for this, as one cannot rely on a particular instantiation procedure.). You will also encounter all fields’ labels in the same widget-tree as the fields themselves.
The ADM2 do provide a name based API for runtime field level manipulation, allowing visualization logic to be separated from the physical manipulation implementation, insulating future changes to the physical implementation from the visual logic. These functions allow the widget name to be qualified with object name or data-source name and can reach any widget within the same container, both from the container itself and from a sibling. The functions of this API are as follows; assignFocusedWidget, assignWidgetValue, assignWidgetValueList, blankWidget, clearWidget disableRadioButton, disableWidget, enableRadioButton, enableWidget, formattedWidgetValue, formattedWidgetValueList, hideWidget, highlightWidget, resetWidgetValue, toggleWidget, viewWidget, widgetHandle, widgetLongcharValue, widgetIsBlank, widgetIsFocused, widgetIsModified, widgetIsTrue, widgetValue and widgetValueList.
You will still need access to the physical widget handle for more layout oriented manipulation as the above mentioned API do not support changes to layout, format or captioning. The ADM2 provides a set of comma separated list properties, with corresponding getters, that can assist in widget walking and widget lookup for such tasks; AllFieldNames and AllFieldHandles, the first list contains the names and the second contains the corresponding handles. Note that it is necessary to check the TYPE of the handle found in these lists before manipulating them, since field level objects (SmartDataFields) will be represented by their procedure handle.
Keep in mind that code that directly accesses widgets is exposing the implementation, and may require changes if for example a widget type is changed or if one decides to change the implementation to use non-native widgets (ActiveX), so one should avoid direct handle access in mass produced code like object instances, and rather implement such routines as generic methods in custom super procedures, libraries or similar.
The DataVisual class (or datavis.p) which the SmartViewers and -Browsers inherits from, also provides comma separated list properties that split these into data bound widgets; DisplayedFields, FieldHandles and non data bound widgets; EnabledObjFlds and EnabledObjHdls. The subset of data bound widgets that are to be enabled/editable are also found in the EnabledFields and EnabledHandles properties.
All these properties can be used consistently against both dynamic and static SmartObjects in Dynamics as well as in pure ADM2 applications, but past versions have had some inconsistency in how the AllField* properties were populated, both in general and between static and dynamic objects. Some objects added labels to its lists while other added contained SmartObjects.
The final rule is as follows:
- All field level widgets are added to these lists (also fields on pure containers from 10.1B).
- Widget labels are not added to these lists.
- Rectangles and images are not added to these lists. (This could possibly change in the future, in particular images, which very well could be data bound).
- Contained SmartObjects are not in these lists, UNLESS they are of ObjectType “SmartDataField”.
The one possibly remaining issue with the AllField* properties is the fact that SmartBrowsers do NOT add its columns to them, so one would need to use the above mentioned DataVisual properties to access the browser’s fields.
related info
The physical frame of a visual component is found in the ContainerHandle property, except when the component is a window container, whose ContainerHandle is the Window handle in which case a dedicated WindowFrameHandle property is used for the frame, if it has one.
related info
The contained SmartObject instances are found in ContainerTarget (singular name, but comma separated list), with the corresponding names in the InstanceNames property. Note that the Viewer’s SDFs are thus found both in the ContainerTarget and in the AllFieldHandles properties.