I know it has been mentioned before - and probably will be mentioned again.
I am sure I have complained about how it works with the commands:
SET
CHANGE
DELETE
MOVE
Not wanting to make it more complicated, but I just realised a suggestion on how it is shown.
SET is used to set things. Yeah, fairly understandable. But I was thrown just now while doing something.
When working in function nodes you can context.set( ), flow.set( ) and global.set( )
These are used to set those variables.
If you are doing the opposite, it is get rather than set.
So, in the change node it is (can be) confusing.
I am wanting to flow.get("something") and save that to the ...... msg.payload.
But the selection is set.
It may be nicer if there could be a get option so the order the names are shown remains the same.
This was another thing which was brought up in previous discussions, as set and move work differently.
Do I need to elaborate more on this idea, or is it already dead in the water?
How would it read in the config ?
Get. flow.something ...
I can’t see a simple phrasing that works compared to Set ... to... and move... to...
Well,
To me it should say Get not set.
If I was coding in JavaScript it code would be:
msg.payload = flow.get("name");
As discussed in the past the node (change) *pushes the data from the bottom field to the top one.
So: flow.name is moved to msg.payload.
It all falls apart when you move. Then it is from the top to the bottom field.
I know brainy people can see around this.
But adding a get option would (maybe) increase that it always goes in a certain direction with the two fields.
Bottom to top would be better I think. It shows you who is getting changed then from where.
set and get would help with the understanding of what is happening too.....
I think I just shot myself in the foot. My inability to explain things.
But as I said, while I was working on a recent problem I got into a bit of a mess wondering how the msg.payload was changed when none of the change nodes had a get in them.
It is intended to read as:
Set [top option] to the value of [bottom option]
If they were flipped around, you would no longer be able to start the sentence with "set".
and if it was flipped and labelled to say
Get [ msg.payload ] from [ flow.foobar ]
then the get would look like it applies to the msg,payload - when in fact it would be doing a msg.payload = flow.get("foobar"); which doesn't line up with @Trying_to_learn mental model ... so i think we'll leave it there for now.
Well, not really.
get msg.payload (from) flow.name works.
And from the picture (screen shot) it would still work.
Errrr.....
I am more confused now.
Yes, new picture.
The original one (without the red X's) bit me.
As it is/was it is setting msg.payload from flow.name.
The new way would be get from.
So the directionality would remain.
The problem I have is (again) if I am doing that task from a javascript level.
It is flow.get (ignoring the flow part).
But using the change node: irrespective of which way the data is going it is always set.
I am sorry. I was just not thinking straight (or in the right mindset - maybe) and it stuck out to/for me that there is this disparity in how things are done.
I don't believe I have actually expressed this aspect before. (Ok, maybe I did.) So I thought I would mention it and see if while discussing it that things would fall into place.
I'm not sure that has happened. But I don't want to argue for the sake of arguing. That's just silly.
I'd better stop now.
Thanks @dceejay and @dceejay.
Sorry for the confusion.
definitely time for a break... !
Yup.
Definitely.
(I can't believe I've been coming here for 2 years! And the google group before that!)
You'd have thought that in that time I would have learnt something. 
Hey Andrew - if you shift to using @BartButenaers Blockly node, then you can have the best of both worlds 
Removes all ambiguity
Yeah, I've seen it and read about it.
It is something I may get done one day.
I'm just not confident enough just yet to do it.
