STRIDE Wiki - User contributions [en]

Test Units Overview

2007-06-20T23:12:00Z

70.167.121.110:

p
==Introduction==

STRIDE enables testing of C++ code through the use of xUnit style test classes. Test classes can be written by engineers, captured using an SCL pragma, and executed from the host. STRIDE facilitates the execution of some or all of the test classes by automatically creating entry points for the execution of test classes on the target.

==Using C++ test classes==

===Prerequisites===

The C++ test class support described here only works in the 2.0.0802 version of STRIDE or later. The host PC must also have a recent distribution of ActiveState perl installed.

===How to get started===

The following is an outline of the required steps to get started with writing C++ test classes.

* Create a new Studio workspace (or open an existing one).
* Set the workspace to cpp mode (for compilation).
* Add '''%STRIDE_DIR%'''\inc\srtest.h to the Source Files folder of your workspace.
* Add '''%STRIDE_DIR%'''\scripts\TestClasses\TestClass_Preprocess.pl (or .js) to your Script Files folder. This script is a preprocessor and code generator. It searches all source files in the current workspace and looks for test classes that have been captured via the ''scl_test_class'' pragma. It then generates c-linkage wrapper functions that instantiate and execute each test class. By default, this generated source file has a name of the form {WORKSPACE_NAME}TCR.cpp and will be located in the workspace directory. If you need to change the name and/or location of this generated file, simply set the '''outFile''' property of the '''''STRIDE.testclass_codegen''''' object prior to calling the generate method. If you will be adding a script to compile the workspace (see next step), this preprocessing script must always '''preceed''' the compilation step.
* Add a script to compile the workspace. In it's simplest form, this script can simple be something like:
#perl syntax
Win32::OLE->Option(Warn => 3);
$main::studio->Workspace->Compile();

// jscript syntax
studio.Workspace.Compile();
* Add a script to generate the Intercept Module(IM). For the simple STUB generation required for C++ test class execution, you can use '''%STRIDE_DIR%'''\scripts\TestClasses\TestClass_Preprocess.pl (or .js) for this purpose.
* Add scripts to build and execute your application. If you are using a host based simulator, we examples available of both. If you are using actual devices, the steps required for building and starting the application are specific to the target environment.
* Create one or more test classes to implement your C++ test logic. See below for more information on creating test classes.
* Ensure that the Studio workspace include path has the location to all of your test class declaration (header) files.
* Once you have created one or more test classes, save the workspace and run the scripts, starting with the TestClass_Preprocess script, followed by compile, IM generation, and application building.
* [''Optional''] If your application is running, you can test execute individual test classes interactively using the Studio interface view. Open the user interface view corresponding to the test class you would like to execute and call it. The return values will indicate how many tests produced each of 4 result types. Furthermore, the input to the entry point will allow you to select all methods or execution (the default) or individual methods -- this is done via a dropdown list of enumerated values.
* Once you are confident that the test classes are behaving as expected, you can generate one or more execution scripts using the Script Wizard. Sample templates for executing test class entry points are provided in the '''%STRIDE_DIR%'''\templates\Script Wizard directory.
* for integration with larger regression test workspaces, we recommend that engineers check-in their test class code and, optionally, the template generated scripts that can be used to execute their test classes.

==CPP test class requirements==

We support several variations on typical xUnit-style test classes. Some of the additional features that we support are:
* test status can be set using STRIDE Runtime APIs ''or'' by specifying simple return types for test methods.
* test writers can create additional child suites and tests at runtime by using Runtime APIs.
* we do not rely on exceptions for reporting of status.

The STRIDE test class framework requires the following of each test class:
* The test class must have a suitable default (no-argument) constructor.
* The test class must have one or more public methods suitable as test methods. Allowable test methods always take no arguments (void) and return either void or simple integer types (int, short, long, char or bool). At this time, we do not allow typedef types or macros for the return values specification.
* the scl_test_class pragma must be applied to the class.

===Simple example using return values for status===

#include <srtest.h>

class Simple {
public:
int tc_Int_ExpectPass(void) {return 0;}
int tc_Int_ExpectFail(void) {return -1;}
bool tc_Bool_ExpectPass(void) {return true;}
bool tc_Bool_ExpectFail(void) {return false;}
};
#ifdef _SCL
#pragma scl_test_class(Simple)
#endif

===Simple example using runtime test service APIs===

#include <srtest.h>

class RuntimeServices_basic {
public:
void tc_ExpectPass(void)
{
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should pass");
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_PASS, 0);
}
void tc_ExpectFail(void)
{
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should fail");
srTestCaseSetStatus(srTEST_CASE_DEFAULT, srTEST_FAIL, 0);
}
void tc_ExpectInProgress(void)
{
srTestCaseAddComment(srTEST_CASE_DEFAULT, "this test should be in progress");
}
};
#ifdef _SCL
#pragma scl_test_class(RuntimeServices_basic)
#endif

===Simple example using srTest base class===

#include <srtest.h>

class MyTest : public stride::srTest {
public:
void tc_ExpectPass(void)
{
testCase.AddComment("this test should pass");
testCase.SetStatus(srTEST_PASS, 0);
}
void tc_ExpectFail(void)
{
testCase.AddComment("this test should fail");
testCase.SetStatus(srTEST_FAIL, 0);
}
void tc_ExpectInProgress(void)
{
testCase.AddComment("this test should be in progress");
}
int tc_ChangeMyName(void)
{
testCase.AddComment("this test should have name = MyChangedName");
testCase.SetName("MyChangedName");
return 0;
}
int tc_ChangeMyDescription(void)
{
testCase.AddComment("this test should have a description set");
testCase.SetDescription("this is my new description");
return 0;
}
};
#ifdef _SCL
#pragma scl_test_class(MyClass)
#endif

==Libraries/Components==

===STRIDE.testclass===

The '''''STRIDE.testclass''''' component is used for executing test classes. It handles the underlying communication with the runtime and creates results in a specified reporter suite. This object supports the following properties and methods:
* ''ascript'' : Input only. This is the ascript instance for the current execution environment. This is '''required''' prior to calling the run method. In most cases, you can simply pass the global ascript instance from your script that executes in your workspace.
* ''parentSuite'' : Input only. This is a reporter suite object into which results for the test class should be added. A sub-suite corresponding the the test class will be created in the given parent suite and all test method results will be added to this new child suite. This is '''required''' prior to calling the run method.
* ''dataFile'' : Input only. This specifies the name/location of the test class meta-data file (generated by the preprocessing step). This is '''required''' prior to calling the run method.
* '''run''' : Method. This initiates the running of the specified test class object. This method requires a single argument - the name of the test class entry point function that was generated by the preprocessing step.

===STRIDE.testclass_codegen===

The TestClass_Preprocess.pl/js script demonstrates how to invoke the functionality exposed in the '''''STRIDE.testclass_codegen''''' object. This object exposes the following properties and methods:
* ''exceptions'' : Input only. Indicates whether or not to generate exception handling code in the test class entry point functions. If you do not have exceptions enabled on your target, set this to 0 -- otherwise we recommend you set it to 1 to enable exception handling code in the test class entry point.
* ''outFile'' : Input only. The name/location of the generated file. This will default to a file named {WORKSPACE}TCR.cpp (where {WORKSPACE} is the name of the current workspace) and will be located in the workspace directory.
* ''dataFile'' : Input only. The name/location of the meta-data file generated by the preprocessor. This meta-data is used by the STRIDE.testclass library to determine the name of test classes and methods as they execute. the default name for this file is {WORKSPACE}.tcrd located in the workspace directory. If you override this property, be sure to override the same property in '''''STRIDE.testclass''''' wherever it is called.
* ''studio'' : Input only. This is the automation object interface to the current execution environment. In most cases, you can simply pass the current global studio object from the script in your workspace. This is '''required''' prior to calling generate.
* '''generate''' : Method. Call this method when you are ready to generate the test class entry points.

[[Category:Testing Strategies]]

Platform Abstraction Layer

2007-06-19T21:58:24Z

70.167.121.110:

== PAL Concepts ==
This section describes the basic concepts of the PAL and the system services it must provide.

=== Function Registration ===
Typically, the STRIDE Runtime calls PAL functions; however, there are some functions
in the STRIDE Runtime that need to be called by the PAL. To eliminate PAL
dependencies on the STRIDE Runtime, these functions are accessed through a function
registration process initiated by the STRIDE Runtime at startup. You write the
registration routine called by the Runtime. This registration routine passes in the address
of the STRIDE Runtime function to be registered as the input parameter, and stores the
address of the STRIDE Runtime function in your own function variable, which is actually
a pointer to a function. You can then call the registered function using your function
pointer variable.

The registered STRIDE Runtime functions allow you to complete such tasks as
delivering a received I-block to the Runtime, checking the number of I-blocks the
Runtime has ready to send out, or signalling the Runtime that your transport is ready for
the next I-block. It is not necessary for the PAL to know the details of these Runtime
functions.

=== Event Notification ===
Unique information is required by an operating system to notify a thread of a pending
event. This information can be a simple index into a table, an address to a thread control
block, the address of a semaphore or one of a number of other implementations. Although
each implementation may be different, a unique notifier is necessary for each thread. The
STRIDE Runtime calls this unique information a Notification Identifier (NID). A thread
uses a NID when waiting for a STRIDE event, and the STRIDE Runtime uses the same
NID to notify the thread of a pending STRIDE event.

An additional piece of information included with the notify routine is a box ID, which is
the ID of the mailbox where the message is delivered.

=== Critical Data Protection ===
The STRIDE Runtime needs to protect critical data structures from multiple,
simultaneous accesses. The specific method of protection is not dictated to the PAL. The
PAL requires that when one thread calls a STRIDE function which in turn calls
palProtect(), and another thread calls a STRIDE function which also calls palProtect();
the second thread is preempted until the first thread’s STRIDE function calls
palUnprotect(). Once palUnprotect() is called, the second thread can be rescheduled
and continue. In addition, the STRIDE Runtime guarantees that calls to palProtect() will
not be nested.

=== Timer Administration ===
The STRIDE Runtime requires that at least one timer be available. When a timer is
created, a callback is registered so that the STRIDE Runtime can be notified of timer
expirations. A user parameter, provided when the timer is created, is passed to the
callback when it gets called. If several timers share a callback routine, this user parameter
can be used to identify which timer expired. The STRIDE Runtime can also stop, start
and delete timers.

Because the STRIDE Runtime also has the need to timestamp trace log data, a routine
that returns the system time, PalGetTime(), is also part of the PAL. This routine is not
associated with timers.

=== Memory Allocation ===
The STRIDE Runtime dynamically allocates memory for messages and trace log storage.
The Runtime uses palMemAlloc() and palMemFree() to allocate memory dynamically
and then return it to the system.

=== Transport Services ===
The PAL transport routines are needed to transfer I-blocks (STRIDE data packets) into
and out of the STRIDE Runtime on your target platform. These routines handle the
buffering and transferring of data to and from your transport mechanism. The PAL also
contains registration routines that allow for STRIDE Runtime routines to be called by the
PAL.

The palOut() routine enables the STRIDE Runtime to transfer I-blocks to your transport.
The STRIDE Runtime calls the palOut() routine whenever it needs to send out an Iblock.
Your transport calls the routine registered with the palOutRdyReg() routine when the
transport is ready for the next I-block to be transmitted. The STRIDE Runtime will not
call the palOut() routine until you call the registered function. In this way, you can
control the flow of transmitted I-blocks.

When a complete I-block has been received by your transport, the routine registered with
the palInReg() routine should be calle to put the received I-block into the STRIDE
Runtime.

In some cases it is useful to know when the transmit path is not being requested. Your
transport mechanism can check the number of I-blocks the STRIDE Runtime has ready
for transmission by calling the routine registered with the palOutPndReg() routine.

=== Host Services ===
The PAL also provides a way for the STRIDE Runtime to support your transport protocol
on the desktop. A Windows® DLL linked to the STRIDE Panel enables these host
services. The DLL allows your data to be received and transmitted using your transport

== PAL Organization ==

This section explains the two categories of PAL services that support the STRIDE Runtime, as
well as the files used to implement these services on your target.

=== PAL Services ===
The PAL services include the following:
* Operating System (OS) Services
* Input/Output (IO) Services

=== PAL Operating System Services ===
The PAL Operating System (OS) Services are the routines that enable the STRIDE
Runtime to work with the operating system on your target platform. In order to write your
PAL OS services you must have detailed knowledge of how your operating system
handles thread synchronization, timers, critical sections, dynamic memory, and
notification. The PAL OS services make the features of your operating system available
to the STRIDE Runtime. All of the functions described here must be fully implemented in your PAL.

{|class="wikitable" border="2" style="margin:1em auto 1em"
! Function Name !! Description
|-
|colspan="2" | '''Synchronization'''
|-
| palCreateNID || Create a Notification Identifier (NID)
|-
| palDeleteNID || Delete a Notification Identifier (NID)
|-
| palCreateRFCProxyNID || Create the RFC Proxy Notification Identifier (NID)
|-
| palDeleteRFCProxyNID || Delete the RFC Proxy Notification Identifier (NID)
|-
| palWait || Wait for an event
|-
| palNotify || Signal a thread that an event is pending
|-
|colspan="2" | '''Timers'''
|-
| palTimerCreate || Create a timer
|-
| palTimerDelete || Delete a timer
|-
| palTimerStart || Start a timer
|-
| palTimerStop || Stop a timer
|-
| palGetTime || Return system time (e.g., tick count)
|-
|colspan="2" | '''Critical Section'''
|-
| palProtect || Begin critical section
|-
| palUnprotect || End critical section
|-
|colspan="2" | '''Memory'''
|-
| palMemAlloc || Allocate a block of dynamic memory
|-
| palMemFree || Free a block of dynamic memory
|}

=== PAL Input/Output Services ===
The PAL Input/Output (IO) Services are the routines that enable the STRIDE Runtime to
work with different data transport mechanisms. These routines enable your transport to
send and receive data between the host and the target.

The IO services have also been defined to allow the target platform to control how
memory is managed and the rate of data exchange. See Appendix A beginning on page
121 for definitions of the header file functions

{|class="wikitable" border="2" style="margin:1em auto 1em"
! Function Name !! Description
|-
|colspan="2" | '''Transmit'''
|-
| PalOutPndReg || Query the current output queue of the Runtime
|-
| PalOutRdyReg || Identify the transport as ready to receive data
|-
| PalOut || Send data to the host platform
|-
|colspan="2" | '''Receive'''
|-
| PalInReg || Data extracted from the transport and identified for the STRIDE Runtime
|}

[[Category:Deploying STRIDE]]

Studio:Integrating the Intercept Module (IM)

2007-06-19T21:33:55Z

70.167.121.110:

== IM Files and how they are used ==
=== Naming conventions ===
=== The Intercept Module source file (IM.c / IM.cpp) ===
=== The IM.h file ===
=== The IMEntry.h file ===
== Adding the IM files to the build ==
== IM Resource Requirements ==
* Stack size
* Threads
== Starting the IMStubRead thread ==

[[Category:Deploying STRIDE]]

Studio:Integrating the Intercept Module (IM)

2007-06-19T21:28:21Z

70.167.121.110:

Studio:Advantages and disadvantages of "default" candidates

2007-06-12T19:50:26Z

70.167.121.110:

The following table describes the advantages and disadvantages associated with the "default" candidate method vs. the candidate method.

{| class="wikitable", cellpadding="5"

|-

!

! '''"Default" candidate method'''

! '''Candidate method'''

|-

| '''Define and pragmatize each function prototype'''

| Not needed.

| Cumbersome if there are hundreds of candidate functions.

|-

| '''Code footprint of the generated code'''

| Only the proxy/stub of the "default" candidate is generated; thus, the code footprint is much smaller.

| The code footprint is dependent upon how many candidates are defined using the scl_ptr_flist() pragma, since a proxy/stub is generated for each candidate defined in the list.
|-

| '''Capturing of function callback command/response payloads via the trace module'''

| Any function callback command/response payloads with the identical signature can be captured.

| Only those candidate functions defined in the scl_ptr_flist() pragma can be captured.

|-

| ''' Visibility of function callbacks via the trace module'''

| The function callback being called is unknown. All of the function callbacks with the identical signature will be displayed with the "default" candidate name and SMID.

| All of the function callbacks being called are known, as long as the candidate functions were declared in the scl_ptr_flist() pragma.

|}
<br>
One disadvantage of using the shorthand method to define candidates in scl_ptr_flist(), as shown in Method 3 of the "Working with "default" candidates topic, is that the function pointer prototypes are not defined by the user/customer, but rather by STRIDE. So, for example, if the user wants to create a proxy for foo2() with stub candidate functions C2 and "cand4" on the target, the generated IM code will give "undefined" compiler errors for "cand4". The following procedure using the header file MyHeader.h (the file containing the SCL pragmas or function prototypes) resolves this issue:
<tt>#ifdef srIMON
void cand4(int x, char y);
#endif </tt>

The use of the srIMON preprocessor directive allows the SDAC to compile the file without any name conflicts for "cand4", since these are already defined within STRIDE. It also allows the generated IM code to compile successfully.
'''MyFunctions.c'''

MyFunctions.c is an example of a user-created file containing the actual code for the candidate "cand4":
<tt>void cand4(int x, char y)<br>
{ <br>
} <br> </tt>

MyTest.c

MyTest.c is an example of a user-created file containing a test thread that makes the call to foo2() with the appropriate function pointer callback:

Help:Editing

2007-03-01T00:53:15Z

70.167.121.110:

http://meta.wikimedia.org/wiki/MediaWiki_User's_Guide#For_editors

Studio:How to synchronize scripts

2007-03-01T00:43:33Z

70.167.121.110:

If a test scenario requires multiple scripts synchronization between the scripts is required. For example if testing a component requires to simulate a depend component it is sometimes easier to split it in multiple scripts. One script could be driving the test which launches a separate script non-blocking which simulates the depended component.

The following example shows how communication between two scripts can be achieved using a simple client-server example. The client queries the server for date and time. The server returns a date and time string.

The interface between the client and server is defined in a SCL file. For the example the SCL files has two interfaces, one to request information (in the example the date and time string) and one to shutdown (end) the server script.

SCL File:
#define MAX_STRING_SIZE 50
int get_time(char* szTime);
int shutdown(void);
#ifdef _SCL
#pragma scl_function(get_time)
#pragma scl_ptr(get_time.szTime, OUT, PRIVATE)
#pragma scl_string(get_time.szTime, MAX_STRING_SIZE)
#pragma scl_function(shutdown)
#endif /* _SCL */

The server scripts waits for requests, gets the time and returns requests:
## Used interfaces
my $req = $main::ascript->Functions->Item("get_time")->Owner;
my $shutdown = $main::ascript->Functions->Item("shutdown")->Owner;

## teake ownership of required interfaces
$req->Register();
$shutdown->Register();

## initialize exit variable
my $end = 0;

## Wait for requests from clients until exit
while ($end == 0)
{
## Wait for an event
my $event = $main::ascript->WaitForEvent();

## if the event is a get time request, get the time
## and return
if ($event->Name eq $req->Name)
{
$req->OutPointers->{szTime} = gmctime();
$req->{ReturnValue} = 1;
$req->Return();
}

## Shutdown event. Set the variable to exit the loop
if ($event->Name eq $shutdown->Name)
{
$shutdown->{ReturnValue} = 1;
$shutdown->Return();
$end = 1;
}
}

## Unregister ownership
$req->Unregister();
$shutdown->Unregister();

The client script queries the server. However it also assures that the server is running. To show how scripts can be launched and terminated the client scripts first checks if the server is running. If not it starts the server and waits until the server is ready to accept requests. This is done by waiting until the server has registered the interfaces for script communication. At the end the client script sends a shutdown request to the server to end the server script.

## Check if server is running
if (!($main::ascript->Functions->Item("shutdown")->Owner->IsRegistered))
{
## Server not available
## As an option we can start the server here
## This might not be required in all cases but is a good sample
## on how to start another script non-blocking
$main::studio->Workspace->Files->Item("server.pl")->RunNonBlocking();

## wait for the server to be up
## An easy way is to wait until the server has taken ownership
## of the supported functions
while (!($main::ascript->Functions->Item("shutdown")->Owner->IsRegistered))
{
$main::ascript->Sleep(100);
}

}

## Get a shortcut to the function
my $req = $main::ascript->Functions->Item("get_time")->User;

## Call te function (blocking request to the server)
$req->Call();

## Check for the return value and display date and time
if ($req->ReturnValue)
{
$main::ascript->MessageBox($req->OutPointers->szTime, "Current Time");
}
else
{
$main::ascript->MessageBox("Server returned Error", "Error");
}

## Shutdown the server (if required)
$main::ascript->Functions->Item("shutdown")->User->Call();</nowiki>

Studio:How to synchronize scripts

2007-03-01T00:38:02Z

70.167.121.110:

If a test scenario requires multiple scripts synchronization between the scripts is required. For example if testing a component requires to simulate a depend component it is sometimes easier to split it in multiple scripts. One script could be driving the test which launches a separate script non-blocking which simulates the depended component.

The following example shows how communication between two scripts can be achieved using a simple client-server example. The client queries the server for date and time. The server returns a date and time string.

The interface between the client and server is defined in a SCL file. For the example the SCL files has two interfaces, one to request information (in the example the date and time string) and one to shutdown (end) the server script.

SCL File:
#define MAX_STRING_SIZE 50
int get_time(char* szTime);
int shutdown(void);
#ifdef _SCL
#pragma scl_function(get_time)
#pragma scl_ptr(get_time.szTime, OUT, PRIVATE)
#pragma scl_string(get_time.szTime, MAX_STRING_SIZE)
#pragma scl_function(shutdown)
#endif /* _SCL */

The server scripts waits for requests, gets the time and returns requests:
## Used interfaces
my $req = $main::ascript->Functions->Item("get_time")->Owner;
my $shutdown = $main::ascript->Functions->Item("shutdown")->Owner;

## teake ownership of required interfaces
$req->Register();
$shutdown->Register();

## initialize exit variable
my $end = 0;

## Wait for requests from clients until exit
while ($end == 0)
{
## Wait for an event
my $event = $main::ascript->WaitForEvent();

## if the event is a get time request, get the time
## and return
if ($event->Name eq $req->Name)
{
$req->OutPointers->{szTime} = gmctime();
$req->{ReturnValue} = 1;
$req->Return();
}

## Shutdown event. Set the variable to exit the loop
if ($event->Name eq $shutdown->Name)
{
$shutdown->{ReturnValue} = 1;
$shutdown->Return();
$end = 1;
}
}

## Unregister ownership
$req->Unregister();
$shutdown->Unregister();

The client script queries the server. However it also assures that the server is running. To show how scripts can be launched and terminated the client scripts first checks if the server is running. If not it starts the server and waits until the server is ready to accept requests. This is done by waiting until the server has registered the interfaces for script communication. At the end the client script sends a shutdown request to the server to end the server script.
## Check if server is running
if (!($main::ascript->Functions->Item("shutdown")->Owner->IsRegistered))
{
## Server not available
## As an option we can start the server here
## This might not be required in all cases but is a good sample
## on how to start another script non-blocking
$main::studio->Workspace->Files->Item("server.pl")->RunNonBlocking();

## wait for the server to be up
## An easy way is to wait until the server has taken ownership
## of the supported functions
while (!($main::ascript->Functions->Item("shutdown")->Owner->IsRegistered))
{
$main::ascript->Sleep(100);
}

}

## Get a shortcut to the function
my $req = $main::ascript->Functions->Item("get_time")->User;

## Call te function (blocking request to the server)
$req->Call();

## Check for the return value and display date and time
if ($req->ReturnValue)
{
$main::ascript->MessageBox($req->OutPointers->szTime, "Current Time");
}
else
{
$main::ascript->MessageBox("Server returned Error", "Error");
}

## Shutdown the server (if required)
$main::ascript->Functions->Item("shutdown")->User->Call();</nowiki>

Studio:How to synchronize scripts

2007-03-01T00:12:17Z

70.167.121.110:

<nowiki>If a test scenario requires multiple scripts synchronization between the scripts is required. For example if testing a component requires to simulate a depend component it is sometimes easier to split it in multiple scripts. One script could be driving the test which launches a separate script non-blocking which simulates the depended component.

The following example shows how communication between two scripts can be achieved using a simple client-server example. The client queries the server for date and time. The server returns a date and time string.

The interface between the client and server is defined in a SCL file. For the example the SCL files has two interfaces, one to request information (in the example the date and time string) and one to shutdown (end) the server script.

SCL File:
#define MAX_STRING_SIZE 50
int get_time(char* szTime);
int shutdown(void);
#ifdef _SCL
#pragma scl_function(get_time)
#pragma scl_ptr(get_time.szTime, OUT, PRIVATE)
#pragma scl_string(get_time.szTime, MAX_STRING_SIZE)
#pragma scl_function(shutdown)
#endif /* _SCL */

The server scripts waits for requests, gets the time and returns requests:
## Used interfaces
my $req = $main::ascript->Functions->Item("get_time")->Owner;
my $shutdown = $main::ascript->Functions->Item("shutdown")->Owner;

## teake ownership of required interfaces
$req->Register();
$shutdown->Register();

## initialize exit variable
my $end = 0;

## Wait for requests from clients until exit
while ($end == 0)
{
## Wait for an event
my $event = $main::ascript->WaitForEvent();

## if the event is a get time request, get the time
## and return
if ($event->Name eq $req->Name)
{
$req->OutPointers->{szTime} = gmctime();
$req->{ReturnValue} = 1;
$req->Return();
}

## Shutdown event. Set the variable to exit the loop
if ($event->Name eq $shutdown->Name)
{
$shutdown->{ReturnValue} = 1;
$shutdown->Return();
$end = 1;
}
}

## Unregister ownership
$req->Unregister();
$shutdown->Unregister();

The client script queries the server. However it also assures that the server is running. To show how scripts can be launched and terminated the client scripts first checks if the server is running. If not it starts the server and waits until the server is ready to accept requests. This is done by waiting until the server has registered the interfaces for script communication. At the end the client script sends a shutdown request to the server to end the server script.
## Check if server is running
if (!($main::ascript->Functions->Item("shutdown")->Owner->IsRegistered))
{
## Server not available
## As an option we can start the server here
## This might not be required in all cases but is a good sample
## on how to start another script non-blocking
$main::studio->Workspace->Files->Item("server.pl")->RunNonBlocking();

## wait for the server to be up
## An easy way is to wait until the server has taken ownership
## of the supported functions
while (!($main::ascript->Functions->Item("shutdown")->Owner->IsRegistered))
{
$main::ascript->Sleep(100);
}

}

## Get a shortcut to the function
my $req = $main::ascript->Functions->Item("get_time")->User;

## Call te function (blocking request to the server)
$req->Call();

## Check for the return value and display date and time
if ($req->ReturnValue)
{
$main::ascript->MessageBox($req->OutPointers->szTime, "Current Time");
}
else
{
$main::ascript->MessageBox("Server returned Error", "Error");
}

## Shutdown the server (if required)
$main::ascript->Functions->Item("shutdown")->User->Call();</nowiki>

Studio:Applying pragmas up and down type chains

2007-02-27T21:35:51Z

70.167.121.110:

== case 1 ==

this is how we apply pragmas

void f(void);
#pragma scl_function(f)
int g(double);
#pragma scl_function(g)

== case 2 ==

this is how we apply more pragmas

== case 3 ==

#pragma foo

Studio:Applying pragmas up and down type chains

2007-02-27T21:35:41Z

70.167.121.110:

== case 1 ==

this is how we apply pragmas

void f(void);
#pragma scl_function(f)
int g(double);
#pragma scl_function(g)

== case 2 ==

this is how we apply more pragmas

== case 3 ==

#pragma foo