Requirements of the objects. List of the requirements. Graphic and script creation of the objects from the database using MechWizard

The requirements should be applied for the newly created and edited objects from the database.

Object's properties

The name of the object should contain the name and number of its standard (for example, "GOST 7798-70", "ISO 657/16").

The comments attached to the name should contain the object's name according to the standard (for example, "Hot-Rolled I-Shape with Sloped Flange").

The specification string should be specified by the strPartName variable.

All the comment fields of the table parameters from the DBFLD and DBINF sections of the UniDialog function should be filled in with the descriptions. All the comment fields of the table should be filled in.

It is recommended to group the table fields so that they have the main parameters grouped to the left.

By default, the name of an implementation is "Implementation1" (without space), if another name is not specified by the standard.

If the Russian standard is used, GOST is set in the properties (if the detail was made by OST, TU or ATK).

Parameters

When creating the parameter's name you should take into account:

1. Similar parameters of the objects from the database (for example, dr - thread diameter, p - thread pitch, L- rod length).
2. Names of parameters in the standard (for example, D1 - flange outer diameter, Dy - drift nominal diameter, b - thread length. The function of the parameter should be specified by the comment in the table or by description of the public parameter.
3. Rules of the variable’s name for C language.

Rules to define the variables:

• Identifier is a sequence of symbols, which are variable’s, function’s or operator’s names.
• Identifier can consist of Latin letters, numbers and underscore character.
• Identifier should be started from a letter or underscore character.
• Identifier, consisting of the same sequences of symbols but in a different case (upper/lower case), are different identifiers.
• Maximum length of the identifier is limited to 50 symbols.

Recommendations for variables names:

• Use prefixes for variable types (r - real, i - integer, str - string, b - logic, vec - vector, pnt - point)
• Use descriptive variables’ names (for example, rLength instead of L, bSection instead of sh)
• Use different cases of letters in the long names of the variables (for example, rWP2offset, bUseFlatSeal)

The parameters should be described as public if:

1. It is needed to specify a connect for the object

2. It is needed to specify a nominal size for the object (the parameters are important)

3. It is needed to extract the parameter for further use (by universal marker or to add to the table fields and etc.)

In any other cases the parameter should not be added to the public section.

You can specify only values of the strTheName, strTheType and strTheSubType variables in English. The values of these parameters should be specified in a way to provide the maximum standardization of the connect procedures.

All parameters of the Public type should have descriptions. This also applies to the descriptions of the working planes. The descriptions of the parameters should be started from the object noun (for example, "Bolt head width").

It is not recommended to describe the parameters with dimensions in the Public section. The descriptions of parameters in the table and in VFLD field can have dimensions. In this case, the dimension is specified in SI units after a comma (for example, "Outer diameter, mm").

All parameters names of the VFLD and BFLD sections should be filled in. It is not allowed to use the variable name as the description of the variable (e.g.  L,”L”).

If the preview is set with the dimensions of the detail, it is allowed to use the comments of any parameters in the VFLD L, "L, Length".

It is recommended to specify the description for all parameters used in the script (as comments).

If a detail’s mass is specified in the standard, it should be added to the public parameters and in the UniDialog DBINF section.

The mass of the detail is specified as a "massa" parameter and in kilos per one detail.

If the mass of the implementations is specified in the table, these parameters have names: massa1, massa2 and etc.

To provide the correct localization of the scripts, all string values should be references to the resources, except for the implementation’s name strings, strTheName, strTheType, strTheSubType classifiers, form names etc.

Resource names are specified in English upper case letters without spaces.

For example:

@DIAMETER_OF_THREAD
@WORKING_PLANE_1 
    

The system names should contain only English letters.

Script

It is recommended that the comments are created in English

It is not recommended to place several operators in one line.

When creating the script, follow the order of the functions:

1. ActHeader()
2. OnInitialisation()
3. (Custom functions)
4. OnMakeParameters()
5. SetGripPoint()
6. OnMoveGripPoint()
7. OnDialog()
8. OnDialogChanged()
9. OnChangeParams()
10. OnInitSelect()
11. OnSelectParam()
12. OnMenu()
13. BeforeConnect()
14. OnConnect()

The operators, setting the strPartName and strPartDescription variables, should be placed at the end of the OnMakeParameters parameters.

The script version and the GOST description should be placed in the first lines of the script. General comments of the object can be placed after them. For example:

  SVersion = 2;
    ObjectDescription = "GOST 19425-74";
    // Slope of flange should be taken
    //between 4 and 10%.
    //In particular 8%
    

It is recommended to use the tabulation to specify an offset for the composite statement and is not recommended to use spaces.

Composite statements should satisfy the following requirements:

• Open bracket is on the same level as the statement
• Nested statements are placed in the same level with the 1 Tab offset.
• Close bracket is on the same level as the composite statement.

Example:

function OnConnect {
    if (rPart == 0) {
        if (obj.strTheSubType == "vaBottom") {
            setWorkId (0, obj.objectID);
            Handled = OBJ_HANDLED;
        };
        if (obj.strTheSubType == "vaShell") {
            setWorkId (1, obj.objectID);
            Handled = OBJ_HANDLED;
         };
     };
    …
};

The UniDialog function should satisfy the following requirements:

• The Function is formed as a composite statement
• Every keyword is started from a new line
• Every option of multi-version sections starts from a new line with the offset.

Example:

UniDialog(
  DBFLD, seria, h, b,
  DBINF, num, mas1,
  VFLD,
    L,"length of I-Profile, mm",
    strRefDataHeader,"Reference data:",
    A, "A, sm^2",
    Ix, "Ix, sm^4",
    ix, "ix, sm",
    Wx, "Wx, sm^3",
    Sx, "Sx, sm^3",
    Iy, "Iy, sm^4",
    Wy, "Wy, sm^3",
    iy, "iy, sm",
  BFLD, bHid, "Show hidden lines",
  TVIDS,lViewType,"AnyWBK",
  VIEW,"Vids"
);

It is recommended to break difficult arithmetic expressions over several lines, or use several additional variables.

It is recommended to use the descriptive comments to group lines of the code which have a close logic structure (for example, block of statements to specify working planes etc.).