To represent parameters in the API definitions you provide, you add the prefix “$<” and the suffix “>” to the parameter name, for example:
TerminateThread ( t_$<nameid>.hndl , 0 );
Code that will be generated for a task named T1:
TerminateThread ( t_T1.hndl , 0);
A second way to use parameters in the API definition is to use the design attribute value of the element itself. For example, suppose the element has a design attribute named Create Mode that uses the attribute key word CK_createdMode, which then evaluates to:
Create Task(nameid)t_$<nameid>. hndl = CreateThread ( NULL ,
0 , ( LPTHREAD_START_ROUTINE )$<nameid> , NULL ,
$<CK_createdMode> , &t_$<nameid>.tid );
Code that will be generated for a task named T1:
t_T1. hndl = CreateThread ( NULL , 0 ,
( LPTHREAD_START_ROUTINE ) T1, NULL ,
CREATE_SUSPENDED, &t_T1.tid );A third way to use parameters in the API definition is to use the property value of the element as the API definition. For example, suppose the element has a design attribute, possibly hidden, that uses the attribute key word CK_sendMessagesAPI
mySendMessage($<nameid>,...)
For the following API definition:
Send Message(nameid)
and design attribute definition:
mySendMessage($<nameid>, $<CK_MessagePriority>);
The resulting generated code, for a data item named DI1, will be:
assuming that the CK_MessagePriority property evaluates to 1.