| |
|
|
|
7
General purpose modules
This chapter describes the general-purpose programming objects in the General modules library.
The General Modules library is located in the Accessories page of the Network Editor under Utility Modules. As the library name suggests, it contains a number of general purpose programming objects:
- copy_on_change
- err_handler
- exit_process
- hconnect
- hsv_to_rgb
- rgb_to_hsv
- rgb_or_hsv
- instancer
- journal
- loop
- load_v_script
- morph
- parse_v
- select_array
- shell_command
- timer
The object can also be accessed through V, by prepending the module name with
"GMOD". For example, to create an instance of the parse_v module, type:The following reference pages describe each of these modules in more detail.
make a one-way connection between two primitive objects
module copy_on_change {
int+read trigger;
prim+read+req input;
boolean+read on_inst;
prim+write output;
};
copy_on_change is used to make a one-way connection between two primitive objects. Any changes made to the object input parameter are copied to output. Changes made to output do not modify input.
When this module runs, it is equivalent to executing the V statement:
This allows input and output to be set to any type of data as long as the values can be converted normally.
If you want to perform more than one assignment when an input changes or you want to change an object to a different value than input, you can use the parse_v module.
This parameter is set to trigger copying input's value to output's value even if input has not changed. You do not normally need to set this parameter.
This parameter can be connected to any primitive object, scalar, or array. When its value changes, it is copied to output.
If this parameter is non-zero, the copy is performed when the object is instanced. Otherwise, the copy is only performed when the value explicitly changes.
This parameter can be connected to any primitive object, scalar, or array but it should be a compatible type to the value connected to input. The object connected to this parameter's value is modified when the value of input changes.
This example shows a UIbutton being used to toggle the visibility of a UIfileDialog. When the button is pressed its do parameter is changed. This parameter is connected to the input parameter of copy_on_change which copies that value to output. The visible parameter of the UIfileDialog object is connected to this output. When it is non-zero, the UIfileDialog object appears. When the OK button of the UIfileDialog is pressed, it sets visible to 0 again. The copy_on_change module does not propagate that change back to the do parameter of the UIbutton.
UIshell UIshell;
UIbutton UIbutton {
parent => <-.UIshell;
};
GMOD.copy_on_change copy_on_change {
input => <-.UIbutton.do;
};
UIfileDialog UIfileDialog {
visible => <-.copy_on_change.output;
};interfaces to ERR package to redirect error information to a string object
err_handler is used to redirect error information from the ERR package into a V string. When an error occurs, it is placed in the err_message string object and all methods that need to be notified when err_message changes are run synchronously. In this situation, the num_lines output parameter contains the number of newlines in the error message.
The system only allows a single error handler to intercept error messages at one time. If you have more than err_handler module active, you should make sure that only one is enabled at a time. By default, the NetworkEditor contains an instance of the err_handler module. You should disable this module before trying to intercept errors on your own.
If this parameter is true, error messages are redirected to err_message string. When it is false, errors go to another error handler or to the console if no other error handlers are installed.
Contains the string for the most recently generated error message. This string is replaced by each new error message.
The number of newline characters in the current err_message parameter.
exit the main process of an AVS/Express session
exit_process is used to exit the main process of an AVS/Express session. It does not itself implement a confirmation dialog mechanism but you can implement confirmation on top of this module by attaching a dialog object's ok parameter to the do_exit parameter of this object.
When this value is set to 1, this module causes the main process to exit.
This value specifies the exit status for the process. If it is not set, the process exits with a 0 status.
module hconnect{
int+read direction;
string+read *offer_name;
string+read *accept_name;
string+read *offer;
string+read *accept;
int+read skip_levels;
int+read order;
int+write accepted;
};
The hconnect module allows connections to be made automatically as objects are instanced. The connections are made between subobjects of the instanced object and an existing instance of the hconnect that is an ancestor of the instanced object. For some networks, this can make network construction easier.
You use this module when an object's location in the object hierarchy is an indication that a particular connection is to be made. For example, you can define a macro that contains a user interface panel so that as you drop widgets into this macro, the widgets parent connections are connected to the panel.
With this module, connections can be made either from the parent to the child or from the child to the parent as specified by the direction parameter. For each connection, one hconnect module serves as the child to "offer" a connection and another hconnect module serves as the parent "accepting" the connection. An individual hconnect module can serve as a parent, child, or both.
The offer_name parameter specifies the pathname relative to the hconnect module of the subobject that should be connected. The accept_name parameter specifies the pathname relative to the parent module
A hierarchical class specification allows flexible classification of the offer and accept objects so that connections can be targeted to an appropriate parent. For example, you can define particular types of subobjects that are to connect to particular types of parents.
If this value is a 0, the child is connected to the parent. If the value is a 1, the parent is connected to the child.
If this hconnect module should serve as a child offering a connection, set this parameter to a string defining the pathname relative to the hconnect module of the child's parameter that is to be connected.
If this hconnect module should serve as a parent accepting a connection, set this parameter to a string defining the pathname relative to the hconnect module of the parent's parameter to be connected.
If this hconnect module should serve as a child, this parameter specifies the types of parents to which this hconnect module should connect. The offer parameter of this hconnect module must match the accept parameter of the parent hconnect module for a connect to be made.
If this hconnect module should serve as a parent, this parameter specifies the types of children to which this hconnect module should connect. The accept parameter of this hconnect module must match the offer parameter of the child hconnect module for a connection to be made.
It is sometimes necessary to have the child skip some number of levels in the hierarchy before it starts searching for a parent hconnect module. This is typically used to prevent the child from connecting to another hconnect module defined in the same macro. In this case, set this number to an integer specifying the number of levels in the hierarchy that should be skipped before searching for the parent hconnect module.
If the direction parameter is a 1, this parameter defines the order in which connections are inserted into the connection list of the accepting object. An object with a smaller order value is inserted into the list before an object with a larger order value. If order is not set, the order of the objects in the list is not defined.
This output parameter is set to 1 in the child hconnect object if the connection is made and 0 if no connection was found.
By default, as the child searches for a parent to connect to, it looks for hconnect modules that are direct ancestors of the child. This includes any immediate parent of the hconnect module and all peers of all parents. It is sometimes useful to define the parent hconnect module as a child of one of the peers of a parent. In this case, you can set the hconnect property to 2 on the peer of your parent so that the hconnect module can be found.
These strings are specified as a hierarchical list of classes. Each class is specified as a simple white-space delimited identifier with an optional set of sub-classes. Two class strings match if they have a single class that matches. If a class in both the offer and accept have a sub-class specification, one of the classes in the sub-class specification must also match. For example:
This example shows how to use hconnect to define both child and parent widgets that are to be connected when the child is instanced as a subobject of the parent. To use this example, load these objects into a library and instance the EXtest object.
UIslider+GMOD.hconnect EXslider {
direction = 0; // connection goes from child to parent
offer = "widget"; // connect to "widget" class
offer_name = "parent"; // connect parent subobject of EXslider
};
macro EXpanel {
UIshell+GMOD.hconnect parent_shell {
accept = "widget"; // accept all offer = "widget" children
accept_name = "."; // connect to parent_shell itself
};
};
application EXtest {
// Creates a shell that has a slider in it.
// The connection dynamically is:
//
// EXslider.parent => EXpanel;
//
EXpanel EXpanel {
EXslider EXslider;
};
};
This example shows how to define a menu bar macro and a set of children objects that install themselves into the parent. To use this example, load these objects into a library and instance the EXmenu_bar object.
UIcmd+GMOD.hconnect EXcmd {
direction = 1; // connect from parent to child
offer = "cmd"; // connect to all cmds
offer_name = "."; // connect this object to the parent
};
UIcmdList+GMOD.hconnect EXcmdList {
direction = 1;
accept = "cmd cmdList";
// accepts either cmds or cmdLists
accept_name = "cmdList";
offer = "cmdList";
offer_name = ".";
};
macro EXmenu_bar {
// hconnect=2 causes us to search subobjects for
// hconnect modules
macro CmdLists<hconnect=2> {
UIshell shell {
menu => <-.menu_bar;
};
// menu_bar.cmdList => {CmdLists.File, CmdLists.Edit};
EXcmdList menu_bar {
direction = 1;
// only accept cmdLists
accept = "cmdList";
};
EXcmdList File {
accept = "cmd (File)";
};
EXcmdList Edit {
accept = "cmd (Edit)";
};
};
// connection is made from File.cmdList => {New_File};
EXcmd New_File {
offer = "cmd (File)";
};
// connection is made from Edit.cmdList => {New_Edit};
EXcmd New_Edit {
offer = "cmd (Edit)";
};
};
convert colors from the hsv color cone to the rgb color cube
module hsv_to_rgb {
float h<NEportLevels={0x2,0x1}>;
float s<NEportLevels={0x2,0x1}>;
float v<NEportLevels={0x2,0x1}>;
float r<NEportLevels={0x1,0x2}>;
float g<NEportLevels={0x1,0x2}>;
float b<NEportLevels={0x1,0x2}>;
method+notify_val+notify_inst method_src = "hsv_to_rgb_proc";
};
Float. A value between 0 and 1 specifying hue.
A value between 0 and 1 specifying saturation.
A value between 0 and 1 specifying value.
Float. A value between 0 and 1 specifying red.
Float. A value between 0 and 1 specifying green.
Float. A value between 0 and 1 specifying blue.
hsv_to_rgb converts from the hue, saturation, and value (hsv) color cone to the red, green, blue (rgb) color cube. The rgb values are not computed until all three inputs are set.
All values are in the range 0.0 to 1.0.
Hue is determined by the angle around the cone. The table below shows values with the associated hues:
Saturation is determined by the distance from the center of the cone to the surface. The center (0.0) has no saturation (for example, white) and the surface (1.0) is fully saturated (for example, red). A middle value (0.5) is partially saturated (for example, pink).
Value is determined by the distance from the top of the cone to the base. The top (0.0) has no value (for example, black) and the base of the cone has full value (for example, white). A middle value (0.5) has partial value (for example, grey).
All values are in the range 0.0 to 1.0.
The RGB color cube is commonly used in computer graphics, because it corresponds directly to the amplitude of the Red, Green, and Blue video signals that drive most computer monitors.
The cube is aligned along the XYZ axes in 3-space. For convenience, the XYZ axes are renamed RGB. Black is at the origin (0,0,0) of the cube. Points along the each axis range from black to the pure color. Diagonally opposite from the origin (1,1,1) is white. Points inside the cube have different saturations and values.
The following colors are associated with the corresponding RGB values:
convert colors from the rgb color cube to the hsv color cone
module rgb_to_hsv {
float r<NEportLevels={0x2,0x1}>;
float g<NEportLevels={0x2,0x1}>;
float b<NEportLevels={0x2,0x1}>;
float h<NEportLevels={0x1,0x2}>;
float s<NEportLevels={0x1,0x2}>;
float v<NEportLevels={0x1,0x2}>;
method+notify_val+notify_inst method_src = "rgb_to_hsv_proc";
};
Float. A value between 0 and 1 specifying hue.
A value between 0 and 1 specifying saturation.
A value between 0 and 1 specifying value.
Float. A value between 0 and 1 specifying red.
Float. A value between 0 and 1 specifying green.
Float. A value between 0 and 1 specifying blue.
rgb_to_hsv converts from the red, green, blue (rgb) color cube to the hue, saturation, and value (hsv) color cone. For a description of the hsv color cone and rgb color cube, see Section 7.6, hsv_to_rgb [page 7-12].
The hsv values are not computed until all three inputs are set.
convert colors between the rgb color cube and the hsv color cone
module rgb_or_hsv {
float r<NEportLevels={0x2,0x1}>;
float g<NEportLevels={0x2,0x1}>;
float b<NEportLevels={0x2,0x1}>;
float h<NEportLevels={0x2,0x1}>;
float s<NEportLevels={0x2,0x1}>;
float v<NEportLevels={0x2,0x1}>;
int mode; /* if mode == 0, rgb has priority if both change */
omethod+notify_val+notify_inst method_src = "rgb_or_hsv_proc";
};
Float. A value between 0 and 1 specifying hue.
A value between 0 and 1 specifying saturation.
A value between 0 and 1 specifying value.
Float. A value between 0 and 1 specifying red.
Float. A value between 0 and 1 specifying green.
Float. A value between 0 and 1 specifying blue.
rgb_or_hsv converts between the red, green, blue (rgb) color cube and the hue, saturation, and value (hsv) color cone. For a description of the hsv color cone and rgb color cube, see Section 7.6, hsv_to_rgb [page 7-12].
If the rgb values are set, the hsv values are computed. If the hsv values are set, the rgb values are computed.
If rgb and hsv values are both set, the integer "mode" subobject establishes which values are computed:
instancer is used to dynamically change the state of the instanced property on an object.
You should use this module when you want to dynamically activate or deactivate a portion of your network.
Specifies the integer value for the instanced property. This value should be 1 or 0. The module runs when this parameter changes.
The value of this parameter specifies the object whose instanced property should be changed. Changing this parameter does not cause this module to rerun.
This integer can be one of three values:
- 0 means do not instance or deinstance the object even if Value changes.
- 1 (the default) means instance the object when Value changes from 0 to 1 and de-instance when values changes from 1 to 0.
- 2 means instance the object when Value changes from 0 to 1 but do not instance the object when value changes from 1 to 0.
This example defines a macro that contains a shell. The instancer module attaches the instanced state of the shell to its visibility. When the shell is made visible, it is instanced at the same time. When it is made invisible, it is deinstanced. This example sets the default instanced property on the shell to 0 so that the shell is not instanced initially when the network is instanced.
macro Dialog {
int visible = 0;
GMOD.instancer instancer {
Group => Dialog_shell;
Value => visible;
};
macro Dialog_shell<instanced=0> {
UIshell my_shell {
visible => <-.<-.visible;
};
UIdial my_dial {
parent => my_shell;
};
};
};
module journal{
int+read+notify start_recording;
int+read+notify playback;
int+read+notify stop;
string+read+notify playback_filename;
string+read+notify record_filename;
int+read+write+notify record;
};
journal controls the operation of the AVS/Express journalling facility from within an application. It records journal files and plays these journal files back. You can use this module if you want to add journalling capabilities to your application.
The journal module has these parameters that control is operation.
When set to 1, this begins journalling into the file specified in the record_filename parameter. Any existing contents of this file are discarded.
When set to 1, plays back the file specified by the playback_filename parameter.
When set to 1, stops recording a journal file
Specifies the pathname of a file from which to play journal files.
Specifies the pathname of a file to record journalling commands.
A read-write parameter. When start_recording is set, this is automatically set to 1 by the system to indicate that journalling is on. When stop is set, this is automatically set to 0 to indicate that journalling has been disabled. If you set this to 0 while journalling is on, journalling is temporarily disabled. It can later be reset to 1 to continue journalling without truncating the current contents of the record_filename.
See the implementation of the Network Editor in v/ne.v for an example of how to use the journal module.
module loop {
int+read+write reset;
int+read+write run;
int+read cycle;
int+read start_val;
int+read end_val;
int+read incr;
};
loop iterates an operation. For example, you could use a loop object to control the movement of an object in your application; this could be as simple as controlling the movement of a slider, or as complex as continuously looping a 3D animation.
The loop object contains the following parameters that you can use to control the iteration:
When set to 1, resets the count subobject to the value of the start_val subobject. This value is reset to 0 right after it is changed.
When set to 1, completes an iteration of the loop. It is reset to 0 when the loop is finished.
If set to 1, iterates the loop continuously.
Indicates the starting value of the iteration.
Indicates the ending value of the iteration.
Indicates the interval at which to count from the starting value to the ending value.
The loop object contains these other subobjects that indicate the progress of the iteration:
If set to 1, indicates that an iteration of the loop completed.
Indicates the current value between the starting value and ending value.
The morph module allows you to implement an object that can dynamically switch between different overlapping implementations. This module is one way that you can implement a dynamic network, where modules are created and deleted automatically. With this approach, you do not have to write any code to explicitly delete or create modules, or make or break connections. You do have to invest some work to define the types properly to get the right behavior.
Points to the object into which objects are to be merged.
An index into the morph_types array to select which object should be merged into the value of morph_obj. As this value changes, the old object is unmerged from the value of morph_obj and the new object is merged.
Defines a library of objects between which to morph. The objects in this library are merged into the morph_obj as the morph_type parameter changes.
The morph module uses the merge and unmerge facilities of the Object Manager to switch between types. As you change the morph_type parameters, the morph object is deinstanced, the old type is unmerged, the new type is merged and the morph object is reinstanced. The unmerge operation removes any subobjects or values that are not defined in the base type of the morph object.
To use this object, you first define a morph object. This is the object that you should connect to the morph_obj parameter and should contain all of the parameters and subobjects that you want preserved as you switch between types. Then you define two or more morph types that will be merged into the morph object based on the setting of the morph_type parameter. These objects may be derived from the template of the morph object, but this is not necessary.
This example shows how you can use the morph object to create a UI object that switches configuration based on the setting of the morph_type parameter. This example could have been implemented by switching the visibility of the widgets as well. The advantage of using the morph object is that only the widgets that are in use are instanced at any given time. For larger examples, this can improve the performance of the system as it takes some time to instance UI objects even if they are not visible.
flibrary EXmorph1 {
//
// Define the morph object to contain a shell that will be shared by
// all implementations.
//
// We define close, back, next, cancel because we want these values to
// be maintained across all different morphed objects
//
// Any values that we always want reset when we morph are set here
// (or in the individual morph objects)
//
// Any values that we want preserved have default values set in
// EXmorph_test.EXmorph_obj. Here we need to explicitly undefine
// the shell's width and height because it is set by default in UI.v
// or else these values will replace the ones in the morph_obj when
// we change morph_type.
//
macro EXmorph_obj {
UIshell shell {
width = ;
height = ;
};
int close, back, next, cancel;
};
//
// The first morph type is going to be just a simple "Close" button.
// it connects up to the "close" value.
//
EXmorph_obj EXmorph_type1 {
UIbutton Close {
x => (shell.clientWidth - width) / 2;
y => (shell.clientHeight - height) / 2;
parent => shell;
do => close;
};
};
//
// The second morph type is a set of 3 buttons "Back", "Next", "Cancel"
//
EXmorph_obj EXmorph_type2 {
UIbutton Back {
x => (shell.width - 3 * width - 20) / 2;
y => (shell.clientHeight - height) / 2;
parent => shell;
do => back;
};
UIbutton Next {
x => Back.x + Back.width + 10;
y => Back.y;
width => Back.width;
parent => shell;
do => next;
};
UIbutton Cancel {
x => Next.x + Next.width + 10;
y => Back.y;
width => Back.width;
parent => shell;
do => cancel;
};
};
//
// This is the object to instance. It contains the morph object and
// the GMOD.morph module.
//
macro EXmorph_test {
//
// Any values that we want to be shared by the morph objects are
// set here (and explicitly left unset in the morph types)
//
EXmorph_obj EXmorph_obj {
shell {
height = 100;
width = 350;
};
close+OPort3;
next+OPort3;
back+OPort3;
cancel+OPort3;
};
GMOD.morph morph {
morph_obj => EXmorph_obj;
morph_types {
EXmorph_type1 EXmorph_type1;
EXmorph_type2 EXmorph_type2;
};
// Start out with the "Close" -- set to 1 to get "Back", "Next"...
morph_type+IPort3 = 0;
};
};
};
This second example shows how the morph object can be used to create a dynamic visualization network. The first morph type implements an isosurface module, the second morph type implements combination of slice plane and isoline. The threshold value and component parameters are shared between the two different modules.
flibrary EXmorph2 {
//
// Define the morph object to contain a shell that will be shared by
// all implementations.
//
// Here we define the input_field, output_object and parameter values
// that we want to be retained across both morph_types.
//
macro EXmorph_obj {
Mesh+Node_Data &in_field;
// These values are unset by default
// If they have values, these values will be restored during the merge
// each time that the morph_type changes.
float iso_component;
float iso_level;
olink out_obj;
};
//
// The first morph type is going to be just a simple "Close" button.
// it connects up to the "close" value.
//
EXmorph_obj EXmorph_type1 {
MODS.isosurface isosurface {
in_field => <-.in_field;
IsoParam.iso_level => <-.<-.iso_level;
IsoParam.iso_component => <-.<-.iso_component;
};
out_obj => isosurface.out_obj;
};
//
// The second morph type is a set of 3 buttons "Back", "Next", "Cancel"
//
EXmorph_obj EXmorph_type2 {
MODS.slice_plane slice_plane {
in_field => <-.in_field;
};
MODS.isoline isoline {
in_field => <-.slice_plane.out_fld;
IsoParam {
ncontours = 1;
level_min => <-.<-.iso_level;
contour_comp => <-.<-.iso_component;
};
};
out_obj => isoline.out_obj;
};
//
// This is the object to instance. It contains the morph object and
// the GMOD.morph module.
//
macro EXmorph_test {
EXmorph_obj EXmorph_obj {
//
// Define initial values here.
//
in_field+IPort3;
iso_component+Port3 = 0;
iso_level+Port3 => cache((in_field.node_data[iso_component].min +
in_field.node_data[iso_component].max) / 2);
out_obj+OPort3;
};
GMOD.morph morph {
morph_obj => EXmorph_obj;
morph_types {
EXmorph_type1 EXmorph_type1;
EXmorph_type2 EXmorph_type2;
};
/* Start out with isosurface */
morph_type+IPort3 = 0;
};
};
};
module parse_v {
string+read v_commands;
prim+read trigger;
int+read active;
int+read on_inst;
group+read *relative;
int+read no_errors;
int+read sync;
};
module load_v_script {
string+read filename;
prim+read trigger;
int+read active;
int+read on_inst;
group+read *relative;
};
parse_v and load_v_script execute a script of V commands. Note that for the purposes of this reference page, a "V command" can be a V command (which is prefixed with a $ character) or a V statement (which is not). parse_v gets the V commands from a string object, load_v_script picks up the list of V commands from a file. Otherwise, the operation of these two commands is the same.
For the parse_v module, contains a string of Vcommands that are to be parsed when this module's method runs. For example:
Note: $ commands included in v_commands must be separated by line breaks. Note also that double quotes can be included in the string, but must be escaped.
The V commands are loaded into the object specified by the relative parameter. The module's update method is triggered when this value changes unless the active parameter is set to 0.
For the load_v_script module, this input parameter specifies the filename of a file containing valid V commands that are parsed when the update method runs. The V commands in the file are loaded into the object specified by the relative parameter. The module's update method is triggered when this value changes unless the active parameter is set to 0.
When this value changes, the V commands for this module are parsed unless the active parameter is set to 0.
This parameter is used to disable the execution of the module. One use is to allow changing the v_commands or the filename parameters without having the module execute. You can set active to 0, change the other parameters, and then set active back to 1 again.
If set to 0, this parameter prevents the V commands from being loaded when the object is instanced. You use this parameter if you want the parse_v or load_v_script modules to be only executed when a particular user interaction occurs.
This parameter is a pointer to an object that is the context in which the V commands are executed. If its value is left unset, the Applications object is used. The value of this parameter is the parent for objects created in the V statements. It also is the starting point to start searching for object names referenced by the V statements.
If this parameter is non-zero, any errors generated by the V commands to be executed are ignored.
If this parameter is non-zero, all methods triggered by parameters modified by the V commands are run before this module completes execution.
This is an example of how to use the parse_v object to attach a button to the visibility of a UIshell object. The parse_v module fires when the button is pressed. Its command string sets the visibility parameter of the UIshell to 0. Since the relative parameter is connected to the UIshell object, the V statement "visible = 0;" sets the value of the parameter UIshell.visible.
GMOD.parse_v parse_v {
v_commands = "visible = 0;";
trigger => <-.UIbutton.do;
relative => <-.UIshell;
};
UIshell UIshell;
UIbutton UIbutton {
parent => <-.UIshell;
};
module select_array {
boolean+notify+read select[];
group+notify+read *array_input[];
group+write *array_output[];
};
The select_array module inputs an array of pointers to groups and a parallel array of booleans. If the boolean is set for a particular element of the input array, this element is added to the output array. Thus the output array of groups will contain a subset of the groups in the input array. The size of the output array is equal to the number of "true" values in the select array.
This module runs whenever the select array's value changes or when elements are added to or deleted from the array_input array. The module does not run when subobjects of the elements pointed to by array_input change.
Specifies an array of booleans that defines which elements of the array_input array are to be placed into the array_output array. If the array_input array is smaller or larger than the select array, only the array elements that overlap are processed.
Specifies the list of array objects to be processed. The array must be a one-dimensional array of groups, but the groups themselves can be of any type.
Defines the array of output objects.
group foo[3] {
int a => index_of(foo);
};
int sel_array[3] = {0,1,1};
GMOD.select_array sel { // foo[1] and foo[2] in array_output
select => sel_array;
array_input => foo;
};
module shell_command {
string+read+req command;
int+read active;
int+read on_inst;
char+write stdout[];
<user parameters>
};
shell_command executes a specified command string and places any data output by that string into the stdout array. The command string is executed synchronously: while the command is running, the module is running.
The command string can take additional user-defined parameters. Because the update method for the shell_command module has the no_meth_ctx property set to 1, these parameters can cause the update method to execute when they change. When the command string is processed, the string values of these parameters are substituted into the command string.
The command parameter specifies a string that contains the command as it is delivered to the shell on your system. This shell command can contain variables delimited by the at (@) character. The names of the variables are resolved to be names of parameters that you have added to the module. For example, you might define the shell_command module in V like:
In this example, as the my_dir parameter's value changes, the update method runs and the command is executed. You can set the nonotify attribute on a parameter that you add to prevent it from causing the method to run.
When set to 0, this parameter disables the execution of the command. You can use this to prevent the command from being executed as the command or other parameters are being changed.
When set to 0, this parameter prevents the execution of the shell command in response to the instance event.
This is a binary array of characters that are derived from the standard output stream of the executed command.
timer triggers an operation at a given time interval. For example, you could use a timer to rotate an object by 15 degrees every 10 seconds.
Indicates the time interval for incrementing the Val subobject in milliseconds.
If set to 1, activates the timer. While the timer is active, the Val object is modified at each time step.
Indicates the amount to increment the Val subobject during each time step.
|
| |
|
|
|
Copyright © 2001 Advanced Visual Systems
Inc.
All rights reserved.