If we now add table constraints to our original type definition, it might look as follows:

   Invoke ::= SEQUENCE {
      invokeID    INTEGER,
      opcode      OPERATION.&operationCode ({My-ops}),
      argument    OPERATION.&ArgumentType ({My-ops}{@opcode})
   }

The “{My-ops}” constraint on the opcode element specifies an information object set (not shown) that constrains the element value to one of the values in the object set. The {My-ops}{@opcode} constraint on the argument element goes a step further – it ties the type of the field to the type specified in the row that matches the given opcode value. ASN1C generates an in-memory table for each of the items in the information object sets defined in a specification. In the example above, a table would be generated for the My-ops information object set. The code generated for the type would then use this table to verify that the given items in a structure that reference this table match the constraints. The C# type generated for the SEQUENCE above when –tables is specified would be as follows:

   public class Invoke : Asn1Type {
     public Asn1Integer invokeID;
     public OPERATION_operationCode opcode;
     public Asn1Type argument;

     ...
   }

This is almost identical to the type generated in the simple case. The difference is that ASN1Type is used instead for the argument element instead of ASN1OpenType. This type is defined as the base class for all the generated ASN.1 types. It holds the value to be encoded or decoded. The way a user Would use this to encode a value of this type is as follows:

Note that in this case, the intermediate type does not need to be manually encoded by the user. The generated encoder has logic built-in to encode the complete message using the information in the generated tables.