npMsgs plugin

About this plugin

With this plugin you can make communications between your publications. Some publication(s) can be sender (s) and another(s) can be receiver(s), so you can make call (and obtain replies) and send string from sender publications to receivers publications in an easy way.

In fact the same publication can act as sender and as receiver, see the Instances sample. But more generally you can establish a publication or more as senders and one or more publications as receivers. From senders you can send strings and make calls, and from receivers you can receive strings sended and maked calls.

Also is possible to establish group of receivers, in other words, you can send strings or make calls only for a specific group of receivers and no others receivers. All of this in an easy way, as you can see in the samples included by this plugin installation.


This plugin are imposible without the aid of this people:

Thanks a lot!

Plugin actions index


This action enabled the publication as a sender that can send strings or make calls to other publications that act like receivers. Before you use any other sender related actions you need to execute this action. This action no need any params.



This action disable the publication as sender, previously enabled. You dont need to call this action when the publication close, for example. You can use this action if in some momment need to disable the sender. Remember that is possible to run various sender's publications at a time.



This action can be use to retrieve the handle of the sender. The needed param must be the name of a variable to stored the retrieved sender handle. Remember that the publication that use this plugin have a sender handle, ever if this is not enabled or disabled.



This action find if the sender is enabled or not. The needed param must be the name of the variable to store two possible values: True or False. In the first case the sender is enabled, in the second case the sender is disabled. Remember that in order to use the sender related actions this must be enabled first.



Use this actions in order to retrieve all availables publications receivers. In other words, any of your publications that have a enabled receiver can be retrieve by this action. The result variable is an array with every receivers handles. You can use this array in order to send strings for every receivers, for example.

Optionally you can especify a receivers group name. If do this the action return in the result variable an array only with the publication receivers named with the group. Take a look at the plugin samples. Remember that if not use a group name all publications as receivers can must be retrieved.



Send a sender call to all receivers or, optionally, only to a group of receivers. A call dont send anything to the receivers, but the receivers can execute a subroutine when a call is made, and a call reply can be executed (see npOnMsgsReceiveCallReply action) executed on the sender side.



Send a string (255 chars max.) to publications that act as receivers. Providing a receiver handle (see npMsgsSenderGetReceivers action) and the text to be send, this action send the string to the appropiate receivers, and this receivers can get the string when the appropiate subroutine is executed, see npOnMsgsReceiveString action.



Set a subroutine to be executed when a call reply is sended by a receiver. In fact this subroutine must execute just after the receiver "on call" subroutine is executed. Also you can set a variable name to store the receiver handle that reply the sender call.



Use this action to enable the publication as a receiver. Before you can use other receiver actions or use sender actions, almost a receiver must be enabled. This action not need any param.



Use this action to disabled (temporary or not) a publication as receiver. When a receiver is disabled a sender cant view this, and cant send strings or make calls or retrieve the receiver handle. This action not need any param. You dont need to execute this action before the publication close but only when you need.



Retrieve in the result variable the handle of the receiver. A publication that use this plugin ever have a receiver handle, ever if this is enabled or not. Use the only one param to set the variable name to store the receiver handle.



Find if the receiver is enabled or not. This action return into the result variable that you can choose True or False, depend if the receiver is enabled or not.



Set a subroutine that is executed when a sender make a call to the receiver or receivers. Also you can set a variable name to store the handle of the sender that make the call.



Set a subroutine that is executed when a sender send a string to the receiver or receivers. You can set a variable name in order to store the string sended by the sender, and, also optionally (not mandatory) a variable name to store the sender handle.


Action errors subroutine

All the NeoPlugins deal with errors in the same way that NeoBook does: when the plugin found an action error the [LastError] variable store information about the error, so you can take care about this variable when execute an action.

But all the NeoPlugins also incorporate an advanced way to deal with possible action errors. You can define a subroutine named OnNeoPluginActionError in order to be executed when some action error are found and you can use this variables inside:

Note that this error handling subroutine are shared for all the NeoPlugins, so you no need to specify a subroutine for every plugin you use in your publication because the same subroutine are recognized and automagically used by every NeoPlugin. Below you can view a sample of this subroutine code:

  AlertBox "NeoPlugin Error" "Error [LastError] in plugin: [PluginName]"

Also note that the use of this NeoPlugins error handling subroutine is completelly optional. You can continue using the [LastError] variable as usual and even use the both methods at the same time.