VisClass: 3.2 VisClass Instance Data: VI_typeFlags

VI_typeFlags, MSG_VIS_SET_TYPE_FLAGS, MSG_VIS_GET_TYPE_FLAGS

The VI_typeFlags field is a bitfield record containing eight flags. These flags determine the type of the visible object and are used primarily by the UI and the windowing system. When used at all, these flags are typically set in the object's definition or when the object is first created, and they are rarely changed dynamically by an application. The eight flags in this record are listed below. The record is of type VisTypeFlags .

VTF_IS_COMPOSITE: This flag is set if the object is of VisCompClass rather than VisClass . This flag indicates the object may have children (normal VisClass objects can not have children). Because this is not the only difference between these classes, changing this flag can have unpredictable results.
VTF_IS_WINDOW: This flag is set if the object creates a window via the window system in order to display itself and its children. This flag implies the object must also have VTF_IS_COMPOSITE set, meaning the object must actually be of VisCompClass and not VisClass . If this flag is set, the UI will assume that the VI_bounds field of the object represents the current size of the window. Objects with the VTF_IS_WINDOW flag set are skipped by the normal input and output messages such as MSG_VIS_DRAW and MSG_META_START_SELECT ; these messages will be passed directly to the object's appropriate child. VTF_IS_WINDOW and VTF_IS_PORTAL are mutually exclusive.
VTF_IS_PORTAL: This flag is set if the object is a portal. A portal is an object that has its own window and appears in its parent's window. A portal differs from a window (VTF_IS_WINDOW) in that the window has no part of itself drawn in its parent window. This flag implies that the VTF_IS_COMPOSITE flag must also be set indicating the object may have visible children. All visible children of a portal will appear in the portal's associated window if VTF_CHILDREN_OUTSIDE_PORTAL_WIN is set. The object itself may display portions of itself within its parent's window, though; an example of this is the UI's implementation of the GenDisplayControl object, which manages several child windows within its own window area. Its border is drawn in the parent window, then its window is defined to be one pixel inside this border. VTF_IS_PORTAL and VTF_IS_WINDOW are mutually exclusive.
VTF_IS_WIN_GROUP: This flag is set for the top visible object in a visible branch which makes that branch a realizable entity. This flag implies that both VTF_IS_COMPOSITE and VTF_IS_WINDOW must be set as well. An example would be the specific UI's implementation of a GenPrimary object--if the primary is not visible, none of its children may be visible (with some exceptions).
VTF_IS_CONTENT: This flag is set if the object is the output of a window object. Typically, this will be set only if the object is of VisContentClass (not for VisClass or VisCompClass ). Note that if this is set, both VTF_IS_WINDOW and VTF_IS_WIN_GROUP must also be set.
VTF_IS_INPUT_NODE: This flag is an optimization bit. It is set if the object controls input flow (such as a VisContent) or is a target or focus node that is not a window group (VTF_IS_WIN_GROUP). MSG_VIS_VUP_ALTER_INPUT_FLOW is sent directly to objects with this bit set unless there is a need for them to actually use the VUP mechanism, as is the case with mouse grabs in a 32-bit content. Similarly, MSG_META_MUP_ALTER_FTVMC_EXCL , MSG_VIS_FUP_QUERY_FOCUS_EXCL , and MSG_VIS_VUP_QUERY_FOCUS_EXCL are sent to the first visible object up the tree that either is a window group or has this bit set.
VTF_IS_GEN: This flag is set if the visible object is the specific UI counterpart to a generic object. This flag must be set for the object to handle messages that begin MSG_SPEC . The only objects that will ever have this flag set are those in Specific UI libraries.
VTF_CHILDREN_OUTSIDE_PORTAL_WIN: This flag is set if children of a portal object may appear in the object's parent window rather than in the portal's specially-created window. The VTF_IS_PORTAL flag must also be set for this object. An example of this is the specific UI's representation of a GenView object and its children; the view's children appear along the edges of the view window rather than inside it. The GenDisplayControl, by contrast, has all its children appearing within its window; thus, it does not have this flag set.

Although the VI_typeFlags record will rarely be changed at run-time, you can set new values by sending MSG_VIS_SET_TYPE_FLAGS to the visible object while it is realized. To retrieve the current type flags, send the object a MSG_VIS_GET_TYPE_FLAGS .

MSG_VIS_SET_TYPE_FLAGS

void	MSG_VIS_SET_TYPE_FLAGS(
        VisTypeFlags		flagsToSet,
        VisTypeFlags		flagsToClear);

This message causes the object to set its VI_typeFlags field to the values passed. The flagsToSet parameter will be OR-ed with VI_typeFlags , and the flagsToClear parameter will be logically inverted and then AND-ed with the field. The clear operation will occur after the set. Therefore a flag set in both parameters will be cleared by this message.

Source: Unrestricted.

Destination: Any visible object; however, the object must not be realized when it receives the object.

Parameters: flagsToSet A record of VisTypeFlags indicating which flags are to be set for the object.

flagsToClear: A record of VisTypeFlags indicating which flags are to be cleared for the object (a flag set in flagsToClear will be cleared in VI_typeFlags ).

Return: Nothing.

Interception: Unlikely.

MSG_VIS_GET_TYPE_FLAGS

VisTypeFlags MSG_VIS_GET_TYPE_FLAGS();

This message returns a visible object's current VI_typeFlags field.

Source: Unrestricted.

Destination: Any visible object.

Parameters: None.

Return: A byte of VisTypeFlags representing the object's current VI_typeFlags field.

Interception: Unlikely.

GEOS SDK TechDocs |

3.1 VI_bounds | Next:

3.3 VI_attrs