L-S-B Broadcast Technologies GmbH. Ember Gadget Interface. Ember Interface. Representing and controlling devices with Ember

Transcription

1 Ember Gadget Interface Ember Interface Representing and controlling devices with Ember 1

2 Date: 06/2010 Version: Draft 7 Author: Marius Keuck Draft 4 Draft 5 Draft 6 Draft 7 New Chapter about Audio Level Meters, Minor diagram design changes Minor Changes Added an explanation about how to disable specific entries in an enumeration. Added a description of the optimized algorithm that can be used to transmit PPM Streams. 2

3 Contents Contents Introduction Ember Node Tags Class Overview Creating a tree The sample frame Node identifier Building the tree Sending the tree Glow Wrapper Receiving a tree Asynchronous reader Traversing the message Directory requests Audio Level Meters Default stream transmission method Optimized stream transmission method Programming guidelines Code listings

4 1. Introduction 1.1 Ember This document describes the usage of the Ember library, which is designed to encode and decode data that is transferred between two devices or applications. In this case, Ember is used to represent gadget frames and similar device types, like audio routers. Almost like XML, Ember uses a hierarchical structure, where each single element is a node, which may have one parent and a list of children. To get an overview of the Ember specification, it is recommended to read the Ember specification draft document first. 1.2 Node Tags An Ember node has a tag, which contains a class type and a 32 Bit number. The class is an enumeration which indicates the meaning of a node, and can have one of the following values: Application, Context and Private. Application specific nodes have the same meaning, wherever they appear. The meaning of context and private specific nodes depends on their location. The exact usage will be described later. 1.3 Class Overview Ember offers several node types in order to be able to construct a tree hierarchy, and to provide the possibility to store different types of data, like strings or integer values. The following image shows the classes of the most common types: 4

5 Image 1 Ember Class hierarchy Basically, there are two different kinds of nodes: containers, which may have several children, and leafs, which contain the data. The classes Set and Sequence are derived from the Container and have an important difference: while a Set may be empty and each child node is optional, a Sequence represents an ordered collection or list type, where the order of the child nodes may be significant. Also, tag uniqueness is not required in a Sequence, but recommended. The Frame is the root node; it encapsulates the rest of the tree and internally uses a Crc node which is used to assure that Ember messages are received correctly. All other node types may be added to the Frame as needed. The DynamicContainer is a special version of the Set. It can either be a Sequence, or a Set, depending on the nodes inserted. As long as each node tag only exists one, the dynamic container is a set. But as soon as it detects a duplicate entry it becomes a sequence. Because of that flexibility, the DynamicContainer is used to represent gadget nodes and parameters. It can also be used to create a category of parameters, like Gains or Sources. The following chapter demonstrates how to build an Ember tree that represents a simple gadget frame. 5

6 2. Creating a tree 2.1 The sample frame A single gadget frame normally contains several slots, where each slot may contain a card which provides specific functionalities, like a de-embedder or a frame synchronizer. These cards have individual parameters. The sample frame used here has four different slots, called Slot 1 to 4. Both, the frame and the slots are represented as nodes. As shown in the image below, the frame node is the parent of the four slots. Parent Node Frame 1 (1) Slot 1 (2) Slot 2 (3) Slot 1 Number is 2 Slot 3 (4) Slot 4 (5) Image Node identifier In Ember, a node can be identified by its tag number and identifier string. In the image above, the values put in brackets are that number, and the text is the identifier. Both, the identifier and the number must be unique, as long as they appear in the same level. That means that all child nodes of our Frame 1 must have different identifier strings. Otherwise it would be impossible to clearly identify the slot nodes. But it would be all right if each slot had a parameter called Name, because then each name parameter has a different parent and is in another level. The following image shows both, a valid and an invalid configuration. 6

7 Frame 1 Frame 1 Slot 1 Name Two nodes may not have the same identifier on the same layer Slot Name Slot 2 Slot Name Name Image 3 The left sample contains no errors, but on the right side Slot appears twice in the same level, which should be avoided! 2.3 Building the tree But now let s see some code, which creates the structure of our frame and the four slots. CEmber_DynamicContainer *pframe, *pslot1, *pslot2, *pslot3, *pslot4 pframe = new CEmber_DynamicContainer(eeBerClass_Context, 1); pslot1 = new CEmber_DynamicContainer(eeBerClass_Context, 2); pslot2 = new CEmber_DynamicContainer(eeBerClass_Context, 3); pslot3 = new CEmber_DynamicContainer(eeBerClass_Context, 4); pslot4 = new CEmber_DynamicContainer(eeBerClass_Context, 5); pframe->insert(pslot1); pframe->insert(pslot2); pframe->insert(pslot3); pframe->insert(pslot4); When we create a DynamicContainer, we have to pass the class type and the number, which is part of our identifier. For nodes, always the ContextSpecific class type is used. With the code above we create a node structure equal to the graph of image 2. The identifier strings are still missing, but it is an easy task to add them as well: 7

8 pframe->insert(eeberclass_application, 1, Frame 1 ); pslot1->insert(eeberclass_application, 1, Slot 1 ); pslot2->insert(eeberclass_application, 1, Slot 2 ); pslot3->insert(eeberclass_application, 1, Slot 3 ); pslot4->insert(eeberclass_application, 1, Slot 4 ); The Insert method of a node offers several overloads, one for each data type available. Internally, the Insert method creates a String leaf. Again, the first argument is the class type, and the second one is the number. But here, the number is not used to identify a node; it is used to determine a property. An identifier string is always an Application specific context with tag number 1. That means that anytime a node with that combination appears, it is an identifier string. The following list shows all current properties, which can be set for a node or a parameter. #define GLOW_Identifier (1) #define GLOW_Description (2) #define GLOW_Value (3) #define GLOW_Minimum (4) #define GLOW_Maximum (5) #define GLOW_Writeable (6) #define GLOW_Format (7) #define GLOW_Enumeration (8) #define GLOW_Factor (9) #define GLOW_Online (10) #define GLOW_Formula (11) #define GLOW_Step (12) #define GLOW_Default (13) #define GLOW_Command (14) #define GLOW_Command_Directory (32) The first two constants, Identifier and Description, and Online, are used for both, nodes and parameters. By default, the identifier string should be displayed in a tree view. But if a description is set, it should be used instead. The other values describe parameter properties: Value Double, integer, string The parameter value. This can be a string, a double or an integer. Minimum Double, integer If the value range is limited, this property indicates the smallest value possible. Maximum Double, integer If the value range is limited, this property indicates the largest value possible. Writeable Boolean Set this property to true, if the parameter can be changed. Format String A C-style format string, like %lf db. Enumeration String If there is an enumeration, all possible values are transmitted in a single string, where each 8

9 Factor choice is separated by the newline character (LF). Internally, the index of the choice is used to determine the current selection. It is also possible to disable specific enumeration entries. This can be done by adding the ~ character as first character of the current string. A complete enumeration could look like this: Disabled\nEnabled\n~Ignore. A factor can be used to represent an internal integer value as floating point value. Online Boolean Boolean value indicating the online state of a node or a parameter. Formula String This property may be used to provide a UPN term which computes the internal value to a display value and vice versa. Step Double, integer This value is added or subtracted from the current parameter value, if it is being incremented or decremented Command Boolean If true, the parameter is a button. So now we have an Ember tree representing our sample frame and its four slots, including their identifier strings. The next step is to add some parameters. The following image shows a small collection of parameters the first two slots may have. Slot 1 Slot 2 Volume Channels Device Name Format Comment Reset Device Name Image 4 Both slots have a parameter called Device Name, which is a read-only string. The table below gives a more detailed description of the other parameters. 9

10 Name Type Sample values Volume Double 0.0 db Channels Integer [0, 4] Format Integer (enumeration) 16:9, 4:3 Comment String Sample frame Reset String (Command) Reset The Volume parameter has no range, but a format string ( %lf db ). Only properties that are used have to be inserted to the parameter description. But before we can add the properties, we have to create the nodes the representing the parameters. This is very similar to the node creation described before. CEmber_DynamicContainer *pvolume; pvolume = new CEmber_DynamicContainer(eeBerClass_Private, 6); pvolume->insert(eeberclass_application, GLOW_Identifier, Volume ); pslot1->insert(pvolume); Instead of the Context class, parameters use the Private specific class. Otherwise, we couldn t distinguish between a node and a parameter if a node contains both. The value 6 is the tag number. Then, the identifier Volume is inserted to the parameter node and the parameter is attached to the slot. That procedure must be repeated for every parameter. After the nodes had been created, the parameter properties may be added, as shown in the following sample. // Volume pvolume->insert(eeberclass_application, GLOW_Value, 0.0); pvolume->insert(eeberclass_application, GLOW_Format, %lf db ); pvolume->insert(eeberclass_application, GLOW_Writeable, 1); // Channels pchannels->insert(eeberclass_application, GLOW_Value, 1); pchannels->insert(eeberclass_application, GLOW_Minimum, 0); pchannels->insert(eeberclass_application, GLOW_Maximum, 4); pchannels->insert(eeberclass_application, GLOW_Writeable, 1); // Format CString senumeration = 16:9\n4:3 ; pformat->insert(eeberclass_application, GLOW_Value, 0); pformat->insert(eeberclass_application, GLOW_Writeable, 1); pformat->insert(eeberclass_application, GLOW_Enumeration, senumeration); // Comment pcomment->insert(eeberclass_application, GLOW_Value, Sample frame ); 10

11 pcomment->insert(eeberclass_application, GLOW_Writeable, 1); // Reset preset->insert(eeberclass_application, GLOW_Value, Reset ); preset->insert(eeberclass_application, GLOW_Command, 1); That s it; all relevant properties are inserted to the parameter nodes. So now, we have created the complete structure that represents the sample frame. 2.4 Sending the tree The next task is to send the complete tree to a connected client application, which normally wants to display or control the devices and parameters of the sample frame. As mentioned before, the root node must be a Frame. So we create one and attach the gadget frame structure to it. CEmber_Frame EmberFrame; EmberFrame.Insert(pFrame); Afterwards, the frame must be encoded to a byte array, which can then be sent to a connected client. The Ember library provides several targets the encoded data can be written to, like memory or files. In most cases a byte array is needed to send data. The class CEmber_Output_Memory does exactly that. It automatically creates a buffer which is large enough to store the complete encoded data. The code below shows how to encode the tree and send it to a client. 11

12 // The EmberFrame is an instance of CEmber_Frame which has been created // before and contains the complete sample frame structure. CEmber_Output_Memory Output; // Encode data EmberFrame.Write(&Output); // Output now contains the encoded data. // Finally, send data. SendToClients(Output.GetMemory(), Output.GetLength()); All steps necessary to create a structure representing a gadget frame, and transmitting the encoded data to connected client applications are now known. 2.5 Glow Wrapper To make the creation of a tree even easier, two more classes called CGlow_Node and CGlow_Parameter were designed. Both make use of the Ember library and are derived from CEmber_DynamicContainer, but are not part of it. The Glow Node is used to represent frames, slots and similar devices, which only need an identifier. The Glow Parameter is used, as the name indicates, to represent parameters and their properties. So, instead of writing something like pvolume->insert(eeberclass_application, GLOW_Value, 0.0); We now can write: pvolume->setvalue(0.0); These two classes can t reduce the number of lines significantly, but they increase readability and save the two constant parameters used to create the tag. For every property, a method is available to set it. Both classes are listed at the end of this document. When using the Glow wrappers, the creation of the tree looks like this: CGlow_Node *pframe = new CGlow_Node(1); CGlow_Node *pslot1 = new CGlow_Node(2); CGlow_Node *pslot2 = new CGlow_Node(3); CGlow_Node *pslot3 = new CGlow_Node(4); CGlow_Node *pslot4 = new CGlow_Node(5); pframe->setidentifier( Frame 1 ); pslot1->setidentifier( Slot 1 ); pslot2->setidentifier( Slot 2 ); pslot3->setidentifier( Slot 3 ); 12

13 pslot4->setidentifier( Slot 4 ); // Attach slots to the frame pframe->insert(pslot1); pframe->insert(pslot2); pframe->insert(pslot3); pframe->insert(pslot4); // Volume CGlow_Parameter *pvolume = new CGlow_Parameter(6, Volume ); pvolume->setvalue(0.0); pvolume->setformat( %lf db ); pvolume->setwriteable(true); // Channels CGlow_Parameter *pchannels = new CGlow_Parameter(7, Channels ); pchannels->setvalue(1); pchannels->setrange(0, 4); pchannels->setwriteable(true); // Format CString senumeration = 16:9\n4:3 ; CGlow_Parameter *pformat = new CGlow_Parameter(8, Format ); pformat->setvalue(0); pformat->setwriteable(true); pformat->setenumeration(senumeration); // Attach parameters to slot 1 pslot1->insert(pvolume); pslot1->insert(pchannels); pslot1->insert(pformat); 13

14 3. Receiving a tree Both, client and server applications must be able to receive and decode an Ember tree correctly. In the first step, the message must be decoded. This is done by a so called reader class. When using a protocol like TCP/IP, the message may be split into several packets, so it is hardly possible to detect when a message is complete. At that point, the asynchronous reader the Ember Library offers comes in handy. 3.1 Asynchronous reader Every byte received by a socket or something similar is appended to the reader by calling its ReadBytes method. For each node that has been decoded correctly, the virtual method OnItemReady is called, which can be used to detect if the tree is complete. That can be done by querying if the current node has a parent or not, because the only node that has no parent, is the frame node. So we derive a class from CEmber_AsyncReader_Framing and override its OnItemReady method to be able to process complete messages. class CMyAsyncReader: public CEmber_AsyncReader_Framing protected: virtual void OnItemReady(CEmber_Node *pnode) // When the current node has no parent, we received // a complete message. if(pnode->getparent() == NULL) OnEventEmber(pNode); ; 3.2 Traversing the message Every time OnEventEmber is called, a complete Ember tree must be processed and handled. Assume a user wants to set the Volume parameter of Slot 1 to the value 1.0. The tree necessary to control that parameter looks like that: 14

15 Frame 1 (1) Slot 1 (2) Volume (6) 1 Parameter value Image 5 Frame 1 and Slot 1 are nodes with the class set to context specific, while Volume uses the private class, because it is a parameter. The value 1 is application specific, because it is a property (GLOW_Value). In an xml like style, the tree looks like this: // A = Application // C = Context // P = Private <A 0xFFFFACDC> <C 1> <C 2> <P 6> <A 3> <value>1</value> </A 3> </P 6> </C 2> </C 1> </A> The numbers behind the class types (A, C, P) are the tag numbers. The first number (0xFFFFACDC) identifies the frame, C1 and C2 are the two nodes Frame 1 and Slot 1, P6 is the parameter and A3 (3 = GLOW_Value) the value. The identifier strings must not be sent to the server application, because they are already known. It is necessary to transmit the complete structure from the root node down to the parameter. Otherwise, it would be impossible to assign the Volume to the correct device, because there could be several parameters with the same name. What we have to do now is to traverse the tree to detect what the message wants us to do. 15

16 We start with the Frame node, which always is the root. It never has any neighbors, but it may have several child nodes. So we ask the root to return its first child, and check its tag class and number, which says C1. At this point, we now that this is a node, and there should be a method that searches for the associated structure, which would then return our Frame 1. Next, we ask C1 to return its first child node, which results in C2. Again, we should call a method that checks, if that node really exists and if it is a sub-node of C1 as well. In this case, it is Slot 1. The first child of Slot 1 is P6. P indicates a parameter, Volume. At this point, we should check if the value node exists. If so, we simply call a Get method of that node to retrieve the value that should be set (1.0). The response message that should be sent to the client looks exactly the same, as long as 1 is a valid value. If it is invalid, the message should contain the current value, like 0. Again, the identifier string and other properties don t have to be transmitted, because the client application is already aware of it. The following code sample should clarify the process described above. void OnEventEmber(CEmber_Node *pnode) // Get a handle that is used to traverse the child nodes POSITION Next = pnode->getfirstchildposition(); while(next) CEmber_Node *pwalk = pnode->getnextchild(next); // Check the class type switch(pwalk->gettagclass()) // Node? case eeberclass_contextspecific: OnEventEmber_Node(pWalk); break; // Parameter? case eeberclass_private: OnEventEmber_Parameter(pWalk); break; void OnEventEmber_Node(CEmber_Node *pnode) // At this point we should check, if the node really exists. // The complete structure has to be checked as well, to assure // that the parents are in correct order and so on. if(nodeexists(pnode) == false) return; 16

17 // If the node is valid, continue traversing the tree OnEventEmber(pNode); void OnEventEmber_Parameter(CEmber_Node *pnode) // Again, check that the parameter is valid if(parameterexists(pnode) == false) return; // Here we have to check, if the value node exists CNode *pvalue = pnode->get(eeberclass_application, GLOW_Value); // If so, get the value and set it. if(pvalue!= NULL) switch(pvalue->gettype()) case eebertype_integer: int nvalue = ((CEmber_Leaf_Int *) pvalue)->getvalue(); >GetValue(); // Method to set the parameter internally SetParameterInt(nValue); break; case eebertype_real: double dvalue = ((CEmber_Leaf_Double*)pValue)- // Method to set the parameter internally SetParameterDouble(dValue); break; case eebertype_utf8string: char *szvalue = ((CEmber_Leaf_UTF8 *) pvalue)->getvalue(); // Method to set the parameter internally SetParameterString(szValue); break; Basically, that is everything necessary to walk through the tree. But a few things are still missing. The validation of the path is very important. You have to check, if the current node or parameter is in the right location, i.e. if Slot 1 (C2) really is the child of Frame 1 (C1). The implementation depends on how a device handles its parameters internally. 17

18 Another thing missing is the construction of the response. One possibility to implement that is to add a second parameter of type CEmber_Node* to the OnEvent methods, which is called presponse. After the validation of the current node or parameter succeeds, it can be added to the response node. After the tree has been traversed, the response node can be sent to the clients connected. 3.3 Directory requests The last thing missing is the so called directory request. Before a client can display or control any parameters, it must query the structure of a device. That is what the directory request is used for. Exactly like parameter properties, it is a node with application context, but the tag number is 32 (GLOW_Command_Directory). When a client application connects to a device, it knows nothing about it. So the first action is to perform a directory request, which looks like that: <C 0xFFFFACDC> <A 32> </A 32> </C> That means, that the application requests the root node. Depending on the size of the tree, it makes sense to only send one level or the entire tree, if it isn t that large. To reduce traffic, we could only send the Frame 1 node. A response would look like this: <C 0xFFFFACDC> <C 1> <A 1>Frame 1</A 1> </C 1> </C> The application can now display Frame 1 in its tree view, for example. When a user clicks on it, the child nodes of that frame have to be requested: <C 0xFFFFACDC> <C 1> <A 32> </A 32> </C 1> </C> The message requests the child nodes of Frame 1 (C1). The response looks like this: <C 0xFFFFACDC> <C 1> <C 2> <A 1>Slot 1</A 1> <P 6> <A 1>Volume</A 1> 18

19 </P 6> // Rest of the parameter list </C 2> <C 3> <A 1>Slot 2</A 1> </C> // Parameter list </C 3> </C 1> When a node contains parameters, it should add them to the response as well. To handle that kind of request, the switch statement in the OnEventEmber method has to be extended with a case eeberclass_application label. If the tag number is 32 (GLOW_Command_Directory), a directory request must be processed. This means that the child nodes and their parameters should be sent to the client who requested the directory. 19

20 4. Audio Level Meters This chapter shortly describes how to integrate an Audio Level stream into Ember. Since Build 1272 of vsmstudio, two different methods are implemented that may be used to transmit stream information. Basically, a stream is provided as a normal parameter. It does not display the current stream value, but is used to subscribe to a stream instead. So usually a stream parameter is called Stream and it is an enumeration with a single entry called Stream as well. When a user wants to use that stream, it needs to be dragged on to a Peak meter control. After that, a Stream subscribe command will be sent to the device offering the stream. The following table shows the commands that were introduced for streams: GLOW_Command_Directory (32) GLOW_Command_Unsubscribe (33) GLOW_Command_Stream (34) GLOW_Command_StreamSubscribe (1001) GLOW_Command_StreamUnsubscribe (1002) Already known, used to request a directory Indicates that the system is no longer interested in any child nodes. Indicates, that a parameter contains a stream Stream unsubscribe Stream subscribe 4.1 Default stream transmission method Let s assume we have a root node called Audio Stream (number 1) which offers a stream parameter (number 2). When requesting the directory of that node, the ember message would look as if the stream parameter were a normal enumeration (with a single entry). As soon as it is used on a panel, the subscribe command would be sent: <C 0xFFFFACDC> <C 1> <P 2> <C 34> <P 1001> </P 1001> </C 34> </P 2> </C 1> </C> 20

21 The <C 34> indicates that this is a stream parameter, while the <P 1001> indicates the Subscribe command. An Unsubscribe would look similar to this, except that the 1001 would be replaced by a A stream should only send its current values when it has an active subscription. This mechanism reduces the network traffic and may even reduce the CPU load of the device that provides the stream values. The message to notify an updated stream value of 7 for example would then look like this: <C 0xFFFFACDC> <C 1> <P 2> </C> <C 34> <P 3> <value>7</value> </P 3> </C 34> </P 2> </C 1> The <P 3> indicates that this is a stream value. The type should always be integer. The unit is 1/32 db. 4.2 Optimized stream transmission method This method requires less CPU performance because it uses a smaller structure to transmit the PPM values. It uses a container that contains a reference to the stream and the current stream value. To be able to use this mechanism, a reference number must be send to vsmstudio when a subscription command is received. To do this, first create a directory response that contains the parameter. Then, a stream command node must be added to the parameter node and an identifier must be added to the command node. The following example shows a correct response to a subscription command: 21

22 <C 0xFFFFACDC> <C 1> <P 2> </C> <C 34> <P 1> <value>unique Stream Identifier</value> </P 1> </C 34> </P 2> </C 1> Instead of the stream value, we just send the stream identifier once. The following code sample shows how to append the required information to a parameter node, where the stream identifier is 1000: CGlow_Parameter *pparameter = ; // Create the stream command node CGlow_Node *pstreamnode = new CGlow_Node(GLOW_Command_Stream); // Attach the stream identifier pstreamnode->insert(eeberclass_private, GLOW_Identifier, 1000); // Attach the stream node to the parameter pparameter->insert(pstreamnode); When a stream is subscribed, all changes should be sent to the vsmstudio automatically. Now, instead of always constructing the complete tree from the root node to the stream parameter, only a single container with identifier and value pairs is required. The root node must be marked as such and must still have the root number as tag number. When the root identifier is 1 as in the samples above, and stream 1000 changed its value to -128, the following structure is created to notify this update: <C 0xFFFFACDC> <C 1> <A 34> <P 1000> <A 3> -128 </A 3> </P 1000> <P 1001> <A 3> -64 </A 3> </P 1001> </A 34> <A 1000>true</A 1000> </C 1> </C> 22

23 <C 1> is the root node of the tree, which is indicated by the <A 1000>true</A 1000>, where 1000 is the number for GLOW_RootTag. <A 34> is dynamic container (34 = Stream command) that must contain the stream identifiers and their values. <P 1000> is the stream identifier and <A 3> represents its current value. <P 1001> is a second stream to show that this container may have as many entries as necessary. The following code constructs the tree listed above, without the stream 1001: CEmber_Frame *pframe = ; CGlow_Node *proot = new CGlow_Node(1); CEmber_Node *pstreamcontainer = new CEmber_DynamicContainer(eeBerClass_Application, GLOW_Command_Stream); proot->setroot(true); proot->insert(pstreamcontainer); pframe->insert(prootnode); // Add the stream CGlow_Parameter *pstream = new CGlow_Parameter(1000); pparameter->setvalue(-128); pstreamcontainer->insert(pparameter); 23

24 5. Programming guidelines In most cases server application providing some parameters don t have to keep the complete Ember tree in memory. Normally, there are only three situations when an Ember tree has to be constructed. The first one is the response to a directory request. If parameters are included to that request, they should contain all known properties, because the client may not know them yet. The second situation is the response to a value update request. And third is an automatically generated message when a parameter changed its value. To avoid polling, a server should always send its responses to every client connected. These responses don t require the identifier strings or parameter properties. It can be assumed that they are already known, because before a parameter can be changed, the directory must have been queried by the client application. 24

25 6. Code listings class CGlow_Node : public CEmber_DynamicContainer public: CGlow_Node(DWORD dwnumber) : CEmber_DynamicContainer(eeBerClass_ContextSpecific, dwnumber) void SetIdentifier(PCSTR szidentifier) Insert(eeBerClass_Application, GLOW_Identifier, szidentifier); void SetDescription(PCSTR szdescription) Insert(eeBerClass_Application, GLOW_Description, szdescription); void SetOnline(bool bonline = true) Insert(eeBerClass_Application, GLOW_Online, bonline); void SetOffline(bool boffline = true) Insert(eeBerClass_Application, GLOW_Online,!bOffline); ; class CGlow_Parameter : public CEmber_DynamicContainer public: CGlow_Parameter(DWORD dwnumber) : CEmber_DynamicContainer(eeBerClass_Private, dwnumber) CGlow_Parameter(DWORD dwnumber, PCSTR szdescription) : CEmber_DynamicContainer(eeBerClass_Private, dwnumber) SetDescription(szDescription); public: void SetIdentifier(PCSTR szidentifier) Insert(eeBerClass_Application, GLOW_Identifier, szidentifier); void SetDescription(PCSTR szdescription) Insert(eeBerClass_Application, GLOW_Description, szdescription); 25

26 void SetEnumeration(PCSTR szenumeration) Insert(eeBerClass_Application, GLOW_Enumeration, szenumeration); void SetFormat(PCSTR szformat) Insert(eeBerClass_Application, GLOW_Format, szformat); void SetFormula(PCSTR szformula) Insert(eeBerClass_Application, GLOW_Formula, szformula); void SetWriteable(bool bwriteable = true) Insert(eeBerClass_Application, GLOW_Writeable, bwriteable); void SetCommand(bool biscommand = true) Insert(eeBerClass_Application, GLOW_Command, biscommand); void SetOnline(bool bonline = true) Insert(eeBerClass_Application, GLOW_Online, bonline); void SetOffline(bool boffline = true) Insert(eeBerClass_Application, GLOW_Online,!bOffline); void SetValue(int nvalue) Insert(eeBerClass_Application, GLOW_Value, nvalue ); void SetValue(double dvalue) Insert(eeBerClass_Application, GLOW_Value, dvalue ); void SetValue(PCSTR szvalue) Insert(eeBerClass_Application, GLOW_Value, szvalue ); void SetDefault(int nvalue) Insert(eeBerClass_Application, GLOW_Default, nvalue ); void SetDefault(double dvalue) Insert(eeBerClass_Application, GLOW_Default, dvalue ); void SetStep(int nvalue) Insert(eeBerClass_Application, GLOW_Step, nvalue ); void SetStep(double dvalue) Insert(eeBerClass_Application, GLOW_Step, dvalue ); 26

27 ; void SetMinimum(int nminimum) Insert(eeBerClass_Application, GLOW_Minimum, nminimum ); void SetMinimum(double dminimum) Insert(eeBerClass_Application, GLOW_Minimum, dminimum ); void SetMaximum(int nmaximum) Insert(eeBerClass_Application, GLOW_Maximum, nmaximum ); void SetMaximum(double dmaximum) Insert(eeBerClass_Application, GLOW_Maximum, dmaximum ); void SetFactor(int nfactor) Insert(eeBerClass_Application, GLOW_Factor, nfactor ); void SetRange(int nminimum, int nmaximum) SetMinimum(nMinimum); SetMaximum(nMaximum); void SetRange(double dminimum, double dmaximum) SetMinimum(dMinimum); SetMaximum(dMaximum); 27