Fixes (see changelog) and bump to v1.1.3

.checksums

@@ -1,5 +1,5 @@
 {
-    "src\\editor\\event-out\\main.html": "6bad9c420154d8b311906a169602d29d19d9ef81",
+    "src\\editor\\event-out\\main.html": "ddd0b0d8312e59fcc8e0b156815ef2d1124acfc9",
     "src\\editor\\event-in\\main.html": "5775c74f0586c430d691c3f8ffc5145c744eb1dc",
     "src\\editor\\event-return\\main.html": "bcd175ed92a1d8f460a138d2eab2fc94597f43c3"
 }

CHANGELOG.md

@@ -1,3 +1,17 @@
+## 1.1.3 - Bug Fix (2021-09-27)
+
+### Changed
+
+* Change return node so that topic setting doesn't override the msg.topic. The topic setting in the node will now only be used if the inbound msg has no topic.
+
+### Fixed
+
+* [A nested loops issue](https://discourse.nodered.org/t/new-node-node-red-contrib-events-alternative-to-link-nodes/51028/35).
+
+  `msg._eventOriginator` and `msg._eventReturner` are now both arrays with the latest entries at the top. This enables multi-level out and return. 
+
+  Infinite loops should no longer be possible unless you deliberately mess with these properties (hint: don't!).
+
 ## 1.1.2 - Improvements & new event-return node (2021-09-26)
 
 ### New

README.md

@@ -23,6 +23,7 @@ This allows you to create sub-flows (sub-routines) and loops very easily.
 * A separate event handler is needed because the Node-RED core devs want to make sure that Node-RED's own event handlers are not used by contributed nodes.
   These nodes use a separate event handler module that is shared with other nodes from me including node-red-contrib-uibuilder.
   That means that these nodes will (in the future) interact with uibuilder where needed but are not dependent.
+  Other nodes could also use the same library. Whichever nodes use the library, they will all get the same event handler.
 * The `/` char in the topic is used as a level (namespace) separator in the same way as with MQTT.
 * Can use either glob-style (`*`, `**`) or MQTT-style (`+`, `#`) wildcards.
 * The package contains some example flows. Access using the Import examples library in Node-RED.
@@ -49,7 +50,8 @@ However, if you wish, you can:
 * Allow the received msg to be passed through to the output.
 * Allow the use of an `event-return` node so that sub-subflows (sub-routines) or loops can be created.
 
-The node adds a `msg._eventOriginator` property that records the `event-out` node ID that is originating the msg. This helps with debugging and tracing of data flows.
+The node adds a `msg._eventOriginator` array property that records the `event-out` node ID that is originating the msg. This helps with debugging and tracing of data flows.
+If a series of `event.out` nodes are used, each will add an ID to top of the array so that you can see the full path taken and so that the `event-return` nodes can navigate back up the tree.
 
 The input topic is sanity checked: it must be a string and no more than 255 chars. It should not contain `*`, `#` or `+`
 
@@ -74,6 +76,7 @@ Then create a flow starting with an `event-in` node, do some processing and end
 
 The `event-return` node does not need any configuration, it uses the `msg._eventOriginator` property from the input msg
 to route data back to the originating `event-out` using an internal event sender/listener based on the node ID of the `event-out` node.
+In the process, it adds to top of an array `msg._eventReturner` with the ID of the return node so that you can trace backwards if needed.
 
 You can, however, allow the node to pass messages through to an output if you want to.
 
@@ -92,4 +95,8 @@ You can also override the msg.topic for the output if you wish.
 
 ## Change Log
 
-See the [CHANGELOG](./CHANGELOG.md) file for details.
+See the [CHANGELOG](./CHANGELOG.md) file for details.
+
+## To Do
+
+* Allow though AND return