Advanced: Creating Customized OSIs : Customizing API Definitions : Features that Facilitate API Definition : Using Parameters for the Generated Code

Using Parameters for the Generated Code

To represent parameters in the API definitions you provide, you add the prefix “$<” and the suffix “>” to the parameter name, for example:

API name:

Terminate Task(nameid)

API Definition in OSDT:

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_SUSPENDED
API Name:
Create Task(nameid)

API Definition in OSDT:

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

This evaluates to:

mySendMessage($<nameid>,...)

 

For the following API definition:

API Name:

Send Message(nameid)

API Definition in OSDT:

$<<CK_sendMessagesAPI>>

and design attribute definition:

mySendMessage($<nameid>, $<CK_MessagePriority>);

The resulting generated code, for a data item named DI1, will be:

mySendMessage(DI1, 1);

assuming that the CK_MessagePriority property evaluates to 1.