Needs a 'wait' to work, Why?

[SparkOut]

If stopAskingQuestions is among the lines of the pendingMessages then
Cancel ... Wait which message id?
From the line above, all we know is that the message is in the queue somewhere,
Which is why we loop through each line to see if the message (name) is on it, and if so
Then we get the id from item 1 of that line, so that we can cancel it. (Cancel requires an id not a message name)

[chris25]

I think the discussion went off course a tiny bit, my question is not concerning the examples that you gave, I understand these examples, they are straightforward. My original question concerned the line 4 and 5 of the dictionaries example where another variable 'X' has been used. This script is for canceling ONE message only. Logically therefore what is the need for line 4 and 5? If the message that needs to be cancelled is found and placed into tPendingMsgs, on line 3 then why can one not proceed to cancel it. Why the need for a repeat loop to place tMsg into another variable?

ON cancelThisMsg tMsg
put the pendingmessages into tPendingMsgs
IF tMsg is in tPendingMsgs THEN
repeat FOR each line x in tPendingMsgs
if tMsg is in x THEN cancel item 1 of x
end REPEAT
END IF
END cancelThisMsg

[SparkOut]

Because, as mentioned, the parameter passed to the handler is a message name. Not an ID.

The handler you quote here will cancel ALL instances of that (individual) message name in the pending message list.

The fist IF checks to see if there is a message of that name in the queue of pending messages.
If there isn't, it doesn't bother checking any deeper. If there is, then it has to loop through the lines of detail in the pending messages list to check if the message name is on that line or not. "Repeat for each line x" is a (very efficient) version of the repeat loop we have mentioned before. It copies each line in turn into the variable named (in this case "x" - ugh, not a good variable naming convention, even in a repeat loop, IMHO). It doesn't need to keep an index counter of "line number", say.
The line copy "x" is then checked to see if it contains the message name. If not, skip to the next line.
If the message name is found on that line, then get the id to use with the cancel statement from item 1 of the line. tMsg is not being put into another variable at all. tMsg (the message name parameter) is checking first against "the whole list of pending messages" and then only if necessary tMsg (the message name parameter) will be checked on each line.

[chris25]

Ok, there are a number of things that you have just said that turn my understanding of this repeat variable upside down, the way I visualized this was completely wrong, now you have broken down the steps I can really understand what is actually going on, I see the piston action if you like. Thankyou. I am sorry if I have been a pain, but to understand and not just use something endlessly because you know it works, means I have learned it and not just memorized when it is supposed to be used.

Kindest regards
chris

[SparkOut]

Good!

Hi Simon,
repeat until the pendingMessages is empty
cancel item 1 of line 1 of the pendingMessages
end repeat
I was asking when, if you are cancelling All messages, why do you need to add: cancel item 1 of line 1. I know that the ID of a message is Item 1 in that line, though there are two sets of numbers separated by a comma, but if All messages are being cancelled, then why identify item 1 line 1 when there well may be several lines to be canclled?

As for this, we will clear all the messages, ie repeat until the pendingMessages is empty.
You know that the pendingMessages gives a list of message information line by line, starting with the id of the message at the beginning of the line.
So we take line 1 and get item 1 (the message id) and cancel that id. That line of message data won't show up in the pending messages list next time it is accessed.
Then if there are no more lines in the pendingMessages the repeat loop will end. If there are still messages pending then the repeat loop starts again. There is still a line by line list of pending messages, so there will still be a line 1 of that list, the message information on that line will not be the same as the previous loop but it will still start at the top. So we don't have to work hard to count and work through the list, we just loop until it is empty, and until it is empty then there will always be a line 1.

[chris25]

Ok, so once again I 'see' how the mechanics are operating, I visualized several oranges in a bucket and the bucket being turned upside down in one sweep, but it is more like a pipe where only one orange at time can fit and each orange is being thrust to the front and taken away one by one, it can not clear out everything together in one swoop. (forgive the child-like visual, but this all makes sense now).
Thankyou.