genmae
Code generation tool for MAE applications messaging and I/O from MAE Registration file (mreg).
genmae files [-msg [msgfile]] [-cbh] [-cbcpp] [-apih] [-apic] [-wiki] [-update-props] [-cpp args]
genmae [-props filename] [-table tablename] [-protocpp] [-protoh]
genmae [-table tablename] [-protocpp] [-protoh] [-sql]
gencode [-class classname] cpp|incl|h2db|h2sql propsfilename
gencode [-class classname] h2prop propsfilename
genmae takes a MAE Message Registration File (mreg) and converts it into usable code - message handlers or API interface files. genmae can also scan source code file to extract mreg directives. genmae is an upgrade from genautoui.
genmae allows the developer to (1) concisely identify the messaging interface between an app and the rest of the MAE environment and (2) define inbound messages in source code adjacent to the source code that handles that message.
MAE best practices require apps to handle requests from multiple users or user sessions. Each session is an instance of a cached class that contains a method to process each inbound message. Inbound messages may be:
When genmae creates the message handling file (msgChannel.cpp), it generates code to:
Command |
Action |
files |
Process the named files. Usually one of the files is channel.mreg. |
-msg |
Based upon the message directives found, create the C++ code to handle all the defined inbound messages. If no filename is provided, it is saved to msgChannel.cpp. The contents of the mreg file are copied to the generated msg file with message directives appropriately converted. |
-apih |
If any APIs have been declared, create the C++ include file (ChannelAPI.h) for the API, declaring the ChannelAPI class. |
-apic |
If any APIs have been declared, create the C++ source file (ChannelAPI.h) for the API, defining the ChannelAPI class. The code takes parameters, packs them into an XMLData messaging structure, and sends it to the app at channel, where it is received and processed as an API message. |
-cbh |
Generate a .h file for the method prototypes specified by mreg file #msg and #response methods. Each prototype is declared and commented. This is handy for rapidly providing a starting point for a class being developed. The copyright, author (Written by), and author's e-mail are extracted from maeapi/broadcast.mreg, if present. |
-cbcpp |
Generate a .cpp file for the methods specified by mreg file #msg and #response methods. Each method is declared and commented, but devoid of code. This is handy for rapidly providing a starting point for a class being developed. The copyright, author (Written by), and author's e-mail are extracted from maeapi/broadcast.mreg, if present. |
-wiki |
Generate a channel.wiki file (see wiki2doc) that documents all inbound defined messages that are defined in message directives from the mreg and other source files. The use of directive comments makes for richer wiki documentation. |
-cpp args |
Invokes the g++ C++ compiler on the generated code using the arguments provided (args). |
-class classname |
By default, the class name is determined by the filename (minus the .h or .cpp) or DB table name, but this command line option overrides that and forces the class name to be the one provided. |
-props filename |
The properties (private variables) of the class to create are located in filename. It can be a plain text file or a .h include file. If it's a plain text file, then each line is expected to be a C++ variable type followed by the property name. If the file is a .h file, genmae looks for two key comment lines, extracting the variables to be declared between them. The upper line must contain the comment CORE DATA BEGIN; the lower line must contain the command CORE DATA END. Any variables outside those two comment lines are ignored. A line with one type and multiple variables separated by commas is permitted. If it is followed by a // comment, then that comment will be used when generating code for get()s, set()s, clear(), set(), and toHashArray() in .h and .cpp prototype files. For example: // CORE DATA BEGIN class Person; // Track names and ages DbRecNum id; // DB table record id string name; // Name of the user int age; // Age of the user // CORE DATA END If a property of type class is provided (as in the example above), then class name is taken from there (no need to specify -class). |
-table tablename |
This is the database table name and the C++ class name. If there is no -props option, then genmae will query the MySQL database table using |DbBroker's commhub.ini configuration to query the tables schema; the schema fields become the new class's properties. This is very handy for quickly making a .h and .cpp file from a database table. If there is a -props option, then tablename is taken as the class name for the .h and .cpp files. |
-protocpp |
Generate a .cpp file for the variables specified by -table/-props. The methods created are the constructor, clear(), set(), initdb(), append(), save(), toHashArray(), and load(). This is handy for rapidly providing a starting point for a class being developed. The copyright, author (Written by), and author's e-mail are extracted from maeapi/broadcast.mreg, if present. |
-protoh |
Generate a .h file for the variables specified by -table/-props. The prototypes declared are the constructor, get()s, set()s, clear(), set(), initdb(), append(), save(), toHashArray(), and load(). This is handy for rapidly providing a starting point for a class being developed. The copyright, author (Written by), and author's e-mail are extracted from maeapi/broadcast.mreg, if present. |
-sql |
Compose a SQL CREATE TABLE for the variables specified by -props. This is handy for rapidly creating SQL to create the table needed for a class. You should review the SQL for field type accuracy because executing it. |
cpp |
(gencode compatibility) Also given a propsfilename, generate a .cpp file - just like the -protocpp option above. |
incl |
(gencode compatibility) Also given a propsfilename, generate a .h file - just like the -protoh option above. |
db2h db2cpp |
(gencode compatibility) Also given a propsfilename, generate a .h file - just like the -protoh option above. |
h2db h2sql |
(gencode compatibility) Also given a propsfilename, compose a SQL CREATE TABLE command - just like the -sql option above. |
h2prop h2sql |
Update the /usr/mae/conf/propdoc.conf file with any comments associated with properties of the class. This is later used to generate wiki documentation for the db table with the class (see makedbwiki.) |
propsfilename |
(gencode compatibility) The properties (private variables) of the class to create are located in propsfilename. It can be a plain text file or a .h include file. See -props option above for more detail. For example: DbRecNum id; // DB table record id string name; // Name of the user int age; // Age of the user |
The primary MAE Message Registration File has the file suffix of .mreg. At a minimum, it contains context setting directives. It may contain #process directives, instructing it to read and process other files, which may not be .mreg files. For example, it may specific which C++ files to read for directives or .ui files (see genformcode) with UI controls that generate messages.
Directives in the .mreg file begin with #. Directives inside C++ files may begin with //#. Directives inside .ui files may begin with <!--#. Comment lines in the .mreg file are extracted and included in generated code. In non-mreg files, the ## directive indicates a comment line. A directive must be the starting text of a line; it may have whitespace before it. Inside non-mreg files, directives can be proceeded by comments, such as //#end to end a //#code block.
There are primarily two types of directives - context (global) directives and message directives. The context directives are usually referenced once and provide information needed for code generation. The message directives identify an inbound message and details about it - such as parameters or code to handle the message.
#channel=channel
Specify the message channel name. For an app, this is typically the app name in lower case, e.g. storyedit.
#primechannel=channel
Specify the prime message channel name when an app uses more than one channel. Note that all .mreg files for the app must all include this directive, otherwise duplicate message handlers will conflict at compile time.
#otherchannels=channellist
Specify a comma separated list of the other message channels. This directive only needs to appear in the prime channel's .mreg file. This is used so the message handler can route an inbound message to the appropriate channnel-specific message handler.
#appclass=appclass
Specify the app's class that contains the methods that message handlers will call. This is typically the class that holds the user session state data, e.g. StoryEditApp.
#appcache=appcache
Specify the application's cache vector where user sessions are held, e.g. StoryEditAppCache.
#cacheid=cacheid
Specify the variable name to use for the cache index. The default is uid.
#apiinclude "filename.h"
Specify an #include that should appear at the top of the generated API.h file. This is important for including any datatypes used in API method declarations.
#apiclass=apiclass
Specify the API class name. The default is ChannelAPI.
#apicache=appcache
Specify the application's cache vector where API sessions are held, e.g. StoryEditAppCache.
#apicacheid=apicacheid
Specify the variable name to use for the API cache index. The default is uid.
#apih text"
Pass the provided text directly to the top of the API .h file. This is handy for adding #defines or other code that is not otherwise generated.
#idcode
Specify the C++ code to locate (and error check) the user session instance and assign it to the instance variable. The default code expects in inbound integer parameter with the same name as the cache id, which is then used to fetch the correct instance from the cache. Note that code may include C preprocessor directives wich as #ifdef.
#msgprecode
Specify code that follows the idcode block (which determines the cache instance) but proceedes the processing of specific messages. Default: none.
#msgpostcode
Specify code that follows the processing of specific messages but before the next event is processed. Default: none.
#responseprecode
Specify code that follows the idcode block (which determines the cache instance) but proceedes the processing of user response messages. Default: none.
#responsepostcode
Specify code that follows the processing of user response messages but before the next event is processed. Default: none.
#mouseprecode
Specify code that follows the idcode block (which determines the cache instance) but proceedes the processing of mouse movement messages. Default: none.
#mousepostcode
Specify code that follows the processing of mouse movement messages but before the next event is processed. Default: none.
#apiprecode
Specify code that follows the idcode block (which determines the cache instance) but proceedes the processing of API messages. Default: none.
#apipostcode
Specify code that follows the processing of API messages but before the next event is processed. Default: none.
#rpcprecode
Specify code that follows the params extraction block but proceedes the processing of RPC messages. Default: none.
#rpcpostcode
Specify code that follows the processing of RPC messages but before the next event is processed. Default: none.
#process "filename"
Tell genmae to scan the specified file for additional directives. In C++ files, // appears before each directive; in .ui files, <!-- precedes the directive. Multiple #process directives may be used to process multiple files. Note that the #directive must immediately follow the comment without any spaces, e.g. //#response ... These comments may be indented using whitespace. For .ui files, genmae also runs genformcode mreg filename to convert it to mreg formated directives.
#toparam datatype=code
When constructing code for the API interface, genmae needs to understand how to convert each data type into a string as it packs it into the XMLData structure. Use the keyword param in code to specify where the API parameter should be positioned in the code. For example: #toparam UserDevice=param.toString().
Note that all #toparam lines from ../maeapi/broadcast.mreg are imported, so it is unnecessary to duplicate them. broadcast.mreg is a handy place to put all #toparam lines.
#fromparam datatype=code
When constructing code for receiving messages, genmae needs to understand how to convert a string into each data type passed to a message handler. Use the keyword param in code to specify where the string should be positioned in the code. For example: #fromparam Money=Money(param).
Note that all #fromparam lines from ../maeapi/broadcast.mreg are imported, so it is unnecessary to duplicate them. broadcast.mreg is a handy place to put all #fromparam lines.
#ignore
When genmae finds this directive, it ignore any text on the same line that follows it. This is useful for commenting out directives.
#userstart message-handler-method-decl
When a user session begins, the userstart message (using keyword userstart) is sent to the app to draw the initial screen that the user sees. When received, it calls the message handler method (see #msg below).
Only #msg is required, but consider #receive (see below). If it has parameters, then #param directivess are required. #code is unnecessary unless you want to override the generated code to call the message handler. Each inbound message has a unique keyword that must be specified. Any comments in between #msg and #param are added as comments in the generated code.
#msg ["keyword"] [message-handler-method-decl]
#msg ["channel:keyword"] [message-handler-method-decl]
Define an inbound specific message that arrives as request keyword. The parameters will be extracted (as mapped by #param directives) and passed to the message handler method provided, which is a member of the appclass. The method declaration must follow valid C++ syntax, including default parameter values.
Note that a #msg following a #api block will be converted to #apimsg.
If a channel is specified, then the keyword is only output in generated files specific to that channel, so a shared file can have #msg for multiple channels.
#param method-parameter=message-parameter
Map a message parameter to a message handler method parameter. Inbound message parameters are strings, so they need to be converted to the method's expected data type for the paramter. A number of data types are known, but non-standard data types require a #fromparam directive (see above) so genmae knows how to convert them. Any non-mapped parameters are flagged as missing during code generation unless the parameter has a default value. Certain message parameters are predefined:
Name |
Value |
param |
The XMLData structure with all the inbound message parameters. |
src |
The channel that sent the message. |
request |
The keyword used for this request. |
device |
The UserDevice value of the device parameter (if present). |
#param method-parameter=@code
Provide code to calculate the parameter in the expected data type instead of extracting it from the message automatically. What is provided as code is not altered. The code may refer to param, src, and request (see table above).
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that calls the message handler method. The lines that follow this directive will be used as the code, unaltered.
#receive "keyword" "mregfile" [message-handler-method-decl]
This is an alternative to #msg and is positioned identically as a #msg block, but allows the message sending application to define the method and parameters. Define an inbound specific message that arrives as request keyword defined by a #send (and any #params following it) in the mregfile specified. (If mregfile starts with maeapi/, then /usr/mae/ is prefixed, e.g. maeapi/guibroker.mreg becomes /usr/mae/maeapi/guibroker.mreg) The method declaration is optional; if present, it overrides the one provided by #send. If no parameters provided, then the parameters from the #send declaration are used.
Only #msg is required. If it has parameters, then #param directives are required. #code is unnecessary unless you want to override the generated code to call the message handler. Each inbound message has a unique keyword that must be specified. Any comments in between #msg and #param are added as comments in the generated code.
#response ["keyword"] [message-handler-method-decl]
#response ["channel:keyword"] [message-handler-method-decl]
Define an inbound specific message that arrives as request keyword. The parameters will be extracted (as mapped by #param directives) and passed to the message handler method provided, which is a member of the appclass. The method declaration must follow valid C++ syntax, including default parameter values.
If a channel is specified, then the keyword is only output in generated files specific to that channel, so a shared file can have #msg for multiple channels.
#param method-parameter=message-parameter
Map a message parameter to a message handler method parameter. Inbound message parameters are strings, so they need to be converted to the method's expected data type for the paramter. A number of data types are known, but non-standard data types require a #fromparam directive (see above) so genmae knows how to convert them. Any non-mapped parameters are flagged as missing during code generation unless the parameter has a default value. Certain message parameters are predefined:
Name |
Value |
cbdata |
The XMLData structure with all the inbound message parameters. |
cbtag |
The keyword used for this request. |
response |
The content of the user's response. This string may be empty/blank. For a selector/pull-down, the value may be $NA if the user selected the prompt option. |
#param method-parameter=@code
Provide code to calculate the parameter in the expected data type instead of extracting it from the message automatically. What is provided as code is not altered. The code may refer to param, src, and request (see table above).
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that calls the message handler method. The lines that follow this directive will be used as the code, unaltered.
A menu option is defined using #menu to specify the text that the user sees. It is immediately followed by a #msg directive per Defining Specific Messages, above.
#menu "menu" "menu-option"
Define a menu option and the method to handle it. Menu options are displayed together with other menu options of the same menu. For example, the "File" menu may have the option "Save" and "Load". Note that each menu optoin requires a separate #menu directive.
A keystroke is defined using #key to specify the keystroke that the user presses. It is immediately followed by a #msg directive per Defining Specific Messages, above.
#key "keystroke"
Define a keystroke and the method to handle it. Keystrokes may be basic, such as "a" or special, such as "ctrl-a" or "f1" or "alt-a". To capture all keystrokes, use "all".
Keystrokes: esc, bs, tab, del, ins, left, right, up, down, home, end, pgup, pgdn, enter, space; f1, f2, ... f12; ctrl-a, ctrl-b, ... ctrl-z, ctrl-1, ctrl-2, ... ctrl-0; alt-a, alt-b, ... alt-z, alt-1, alt-2, ... alt-0; ctrl-left/right/upd/down/home/end; alt-left/right/upd/down/home/end; shift-left/right/upd/down/home/end; shift-f1, shift-f2, ... shift-f12.
A UI is rendered with named areas (regions) that are hidden from the user (hotspots are defined in HTML or .ui files). When a user clicks on a region, your app can register to respond to that click. Such a region is called a hotspot. A hotspot is defined using #hotspot to specify the region that the user clicks on. It is immediately followed by a #msg directive per Defining Specific Messages, above.
#hotspot "region"
Define a response to a user click on a region. When the user clicks on the region, a message without paramters is sent to the app and handled by the #msg directive immediately following per Defining Specific Messages, above. If the region is an image and the app needs to know where inside the image the user clicked, then use the #mouse directive instead.
#hotspot "region" using "otherapp"
Define a response to a user click on a region by redirecting the click to another app to process. It is up to the other app to process it or not.
When a user clicks on an image (with a region / named area) and the app wants to process where (x,y) the user clicked, then use the #mouse directive. This directive will also tell you the mouse button position - up, down, or update. The #mouse directive is immediately followed by a #msg directive per Defining User Response Messages, above, with three additional parameters: x, y, and dir.
#mouse "region" "cmd" [message-handler-method-decl]
Define a response to a user mouse action in a region. When the user performs a mouse action in the region (down press, up release, or movement), a message without paramters is sent to the app (cmd) and handled by the message handler method or #code, like #msg. Implicit variables dir (string), x (float), and y (float) can be used in #param mappings.
Name |
Value |
cbdata |
The XMLData structure with all the inbound message parameters. |
request |
The keyword used for this request. |
x |
The x of the (x,y) location where the user clicked. |
y |
The y of the (x,y) location where the user clicked. |
dir |
The direction of the user click. The value may be "up", "down", or "move". Note that a user mouse click generates both a down click and an up click. |
An API call defines a standard inbound message. It has two sides - the side that sends the message and the side that receives the message - so an API call must define both sides. Comments that immediately follow the #api directive are expected to be in Javadoc format; @param references become specially formatted when generating wiki output using -wiki. A #msg directive is expected to follow this section; the #msg directive defines how the API message is received and processed.
#api [api-method-decl]
Define an API method to be used by other applications. The parameters will be packed (as mapped by #param directives) and passed as a message, which is subsequently passed to the message handler in your app. The method declaration must follow valid C++ syntax, including default parameter values.
Following the #api block, include a #apimsg (or #msg) block to process the API request.
#param message-parameter=method-parameter
Map an API parameter to a message parameter. Message parameters are strings, so each method parameter needs to be converted from the method's expected data type to a string. A number of data types are known, but non-standard data types require a #toparam directive (see above) so genmae knows how to convert them.
#param method-parameter=@code
Provide code to add a string message parameter. What is provided as code is not altered. The code may refer to your API method parameters.
Name |
Value |
cbdata |
The XMLData structure with all the inbound message parameters. |
request |
The keyword used for this request. |
channel |
If a value is assigned to channel, then the message is sent to that channel (not the default channel). |
instanceId |
If a method call contains an instance id, then this id will be used for sending the message to the right instance. |
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that packs the XMLData message and sends the message. The lines that follow this directive will be used as the code, unaltered. Note that a send() method is automatically generated for the API class that you may want to use to send your packed XMLData structure.
#apimsg ["keyword"] [message-handler-method-decl]
Define an inbound specific API message that arrives as request keyword. The parameters will be extracted (as mapped by #param directives) and passed to the API message handler method provided, which is a member of the appclass. The method declaration must follow valid C++ syntax, including default parameter values.
#param method-parameter=message-parameter
Map a message parameter to a message handler method parameter. Inbound message parameters are strings, so they need to be converted to the method's expected data type for the paramter. A number of data types are known, but non-standard data types require a #fromparam directive (see above) so genmae knows how to convert them. Any non-mapped parameters are flagged as missing during code generation unless the parameter has a default value. Certain message parameters are predefined:
Name |
Value |
cbdata |
The XMLData structure with all the inbound message parameters. |
cbtag |
The keyword used for this request. |
response |
The content of the user's response. It may be empty/blank. |
#param method-parameter=@code
Provide code to calculate the parameter in the expected data type instead of extracting it from the message automatically. What is provided as code is not altered. The code may refer to param, src, and request (see table above).
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that calls the message handler method. The lines that follow this directive will be used as the code, unaltered.
An API call defines how a message is received by a daemon that processes such messages. However, such daemons may also send out standard messages that multiple other applications use. In this case, you can declare a standard outbound message using #send followed #param directives that other applications can import using a #receive directive.
#send keyword [receive-method-decl]
This does not generate code for the current daemon/app. It defines a #msg method where the #receive direcitve is used by another application (not the current application). The parameters will be unpacked (as mapped by #param directives following a #msg) when received by the message handler in the other app. The method declaration must follow valid C++ syntax, including default parameter values.
#param method-parameter=message-parameter
Map a message parameter to a method parameter. Message parameters are strings, so each method parameter needs to be converted to the method's expected data type from a string. A number of data types are known, but non-standard data types require a #fromparam directive (see above) so genmae knows how to convert them.
#param method-parameter=@code
Provide code to convert a string message to a method parameter. What is provided as code is not altered.
An RPC (Remote Procedure Call) has two sides - the client side and the server side. The client calls the server and receives an answer. Comments that immediately follow the #api directive are expected to be in Javadoc format; @param references become specially formatted when generating wiki output using -wiki. A #rpc directive is expected to follow this section; the #rpc directive defines how the RPC message is received and processed.
#api ["cmd"] [api-method-decl]
Define an RPC API method to be used by other applications. The parameters will be packed (as mapped by #param directives) and passed as a message, which is subsequently passed to the RPC handler in your app. The method declaration must follow valid C++ syntax, including default parameter values.
This API call returns an XMLData structure to the calling app. Its contents are
Property |
Description |
rpc_error |
A text error message |
Following the #api block, include a #rpc block to process the RPC request.
#param message-parameter=method-parameter
Map an RPC parameter to a message parameter. Message parameters are strings, so each method parameter needs to be converted from the method's expected data type to a string. A number of data types are known, but non-standard data types require a #toparam directive (see above) so genmae knows how to convert them.
#param method-parameter=@code
Provide code to add a string message parameter. What is provided as code is not altered. The code may refer to your API method parameters.
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that packs the XMLData message and sends the RPC message. The lines that follow this directive will be used as the code, unaltered. This API call returns XMLData with the response.
#rpc ["keyword"] [message-handler-method-decl]
Define an inbound specific RPC message that arrives as service keyword. The parameters will be extracted (as mapped by #param directives) and passed to the API message handler method provided, which is a member of the appclass. The method declaration must follow valid C++ syntax, including default parameter values.
#param method-parameter=message-parameter
Map an inbound parameter (from params) to a method variable. Inbound message parameters are strings, so they need to be converted to the method's expected data type for the paramter. A number of data types are known, but non-standard data types require a #fromparam directive (see above) so genmae knows how to convert them. Any non-mapped parameters are flagged as missing during code generation unless the parameter has a default value. Certain message parameters are predefined:
Name |
Value |
params |
The XMLData structure with all the inbound message parameters. |
service |
The keyword used for this request. |
#param method-parameter=@code
Provide code to calculate the parameter in the expected data type instead of extracting it from the message automatically. What is provided as code is not altered. The code may refer to param, src, and request (see table above).
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that processes the request. The lines that follow this directive will be used as the code, unaltered, inside a new method called rpckeyword.
Note that the message handler follows this method declaration:
XMLData rpcmethod(string service, XMLData & params, string appname, string user, void * notused);
Param |
Description |
service |
The name of the service being requested |
params |
The values provided by the client (see #api's #params). |
appname |
The app id of the client app. |
user |
Reserved for future use. |
notused |
Reserved for future use. |
Sometimes, you may not literally know the keyword that the message handler expects. In this case, you can provide a method that returns true if the keyword should be processed by the method handler. In this case, both the validation method and the handler code must be provided using #msgvalid and #code.
#msgvalid validator
The validator is a boolean expression that is typically a method call (not a method declaration) that must return a boolean. When the boolean return is true, then the #code is run. Otherwise, it may be processed elsewhere.
#msgvalid isTile(request)
#msgvalid string(request,0,4) == "tab."
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive to handle the message or call the message hanlder. The lines that follow this directive will be used as the code, unaltered.
Sometimes, you may not literally know the keyword that the user response message handler expects. In this case, you can provide a method that returns true if the keyword should be processed by the method handler. In this case, both the validation method and the handler code must be provided using #responsevalid and #code.
#responsevalid validator
The validator is the method call (not a method declaration) that must return a boolean. When the boolean return is true, then the #code is run. Otherwise, it may be processed elsewhere.
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive to handle the message or call the message hanlder. The lines that follow this directive will be used as the code, unaltered.
Sometimes, you may not literally know the keyword that the mouse message handler expects. In this case, you can provide a method that returns true if the keyword should be processed by the method handler. In this case, both the validation method and the handler code must be provided using #msgvalid and #code.
#mousevalid validator
The validator is the method call (not a method declaration) that must return a boolean. When the boolean return is true, then the #code is run. Otherwise, it may be processed elsewhere.
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive to handle the message or call the message hanlder. The lines that follow this directive will be used as the code, unaltered.
There are a number of broadcast messages defined in the MAE system that your app can choose to recieve and process. They are defined in ../maeapi/broadcast.mreg. For example, they could be:
Name |
Purpose |
time |
Update game time. |
location |
Update the location of an Entity in the game. |
setting |
Update one field of an object. |
combatant |
Update an Entity. |
possession |
Update a Possession. |
booty |
Update Booty on an Entity. |
magicEffect |
Update magic on an Entity. |
money |
Update Money on an Entity. |
taskstatus |
Report a task as started/terminated. |
cacheadd |
An object is now in use in another app. |
cacheremove |
An object has expired in another app. |
objectchg |
Update one or more field values in an object. |
#broadcast keyword
Declare that the app that handles the broadcast message of the keyword mentioned. Code will be generated in the message handler must be provided in a #code directive that immediately follows.
The method to handle the broadcast message is defined in ../maeapi/broadcast.mreg along with inbound parameters. The API call to send the broadcast message is also defined in broadcast.mreg.
#errorcheck
Use this directive to proceed either a #code block or generated action code with code, presumably to error check the parameters before they are used. However, you may place any code here.
#code
Use this directive when you wish to override the automatically generated code that calls the message handler method. The lines that follow this directive will be used as the code, unaltered.