/MEng/System/CQC/Runtime/CQCFldDef

Class Information:

ClassPath:	MEng.System.CQC.Runtime.CQCFldDef
Parent ClassPath:	MEng.Object
Copyable:	Yes
Final:	Yes

MEng.System.CQC.Runtime.CQCFldDef describes the attribute of a driver field to CQC. A driver must fill in a vector of these objects and register them with CQC in order to indicate what fields it wants the outside world to see, what data types those fields are, their names, etc... See also the driver class MEng.System.CQC.Runtime.CQCDriverBase.

 

Nested Types:

Enum=CQCFldTypes
    Boolean     : "Boolean";
    Card        : "Card";
    Float       : "Float";
    Int         : "Int";
    String      : "String";
    StringList  : "StringList";
    Time        : "Time";
EndEnum;

This enumerated type indicates the data type that the field should. Fields have a restricted set of data types, for simplicity.

Enum=CQCFldAccess
    Read       : "Readable";
    Write      : "Writeable";
    ReadWrite  : "Readable/Writeable";
EndEnum;

This enumerated type indicates the types of access that CQC should allow for this field. Readable fields can be queried by CQC client applications, and writeable fields can be written to by them.

 

Constructors:

Constructor();
Constructor
(
    [In] MEng.String FldName
    , [In] CQCFldTypes FldType
    , [In] CQCFldAccess FldAccess
);
Constructor
(
    [In] MEng.String FldName
    , [In] CQCFldTypes FldType
    , [In] CQCFldAccess FldAccess
    , [In] MEng.String Limits
);

The default constructor just creates an empty object for later setup. It will not be an acceptable object if passed in for registration. The other two constructors will create fully initialized objects, with the last one taking a limits field, if you wish the field to have limits.

 

Final, Const Methods:

GetId() Returns MEng.Card4;

Returns the value of the field id member. In most cases this is of no use for you, since this field is not set until the fields are registered, and the list you build in order to register won't have meaningful values for this field.

GetName() Returns MEng.String;

Returns the value of the field name member.

GetLimits() Returns MEng.String;

Returns the value of the field limits member. If you didn't set any, it will be an empty string.

 

Final, Non-Const Methods:

Set
(
    [In] MEng.String FldName
    , [In] CQCFldTypes FldType
    , [In] CQCFldAccess FldAccess
);
SetWithLimits
(
    [In] MEng.String FldName
    , [In] CQCFldTypes FldType
    , [In] CQCFldAccess FldAccess
    , [In] MEng.String Limits
);

These methods allow you to set up a field definition object after the fact. This is commonly done during driver initialization, where a local object is repeatedly set up and then added to the registration list.

SetAlwaysWrite([In] MEng.Boolean ToSet);

Some fields don't represent a value in the device, but instead a write-only field will be designed to invoke some action when a client writes to it. Sometimes just writing to it at all causes the action, and sometimes writing a particular value causes a particular action.

Since CQCServer tries to optimize and not tell drivers when a client writes a value to a field that is the same as the currently stored value, this will prevent these types of invocation fields from working if the same value is written twice. So you can set this field to tell CQCServer that you always want to be notified when this field is written to.

SetQueuedWrite([In] MEng.Boolean ToSet);

Some devices cannot respond in a reasonable time to incoming field change events, in response to which they usually send a message to the device that they control. If they cannot do this operation quickly, it will slow down access to that device by other clients.

In such cases, the driver should mark any fields that suffer from this issue as being 'queued write' fields. This will tell CQCServer that it should not update the field value just because the driver returned successfully from the field changed event. Instead, it is assumed that the driver has queued up the request and will process it on it's own time, from within it's polling callback event, so that other clients are not prevented from getting to the driver's fields.

The driver becomes responsible for updating the target field with the written value once it has successfully updated the controlled device. Failing to do so will cause the field to become out of sync with the value in the device (though if it is a readable field, it might get back into sync on the next poll cycle.) If the field is write only, and marked always write, it doesn't matter much. But, if it is not marked always write, even though it is write only, failing to keep the field up to date with device can cause writes to occur that don't need to.