OK
So we can go back to having the msg/flow/global/context dropdown idea? 
I withdraw my inline request
(I'll just right-click and set it manually when aesthetically OK to do so )
[FINAL SUGGESTIONS FOR FUNDAMENTAL GET/SET BLOCKS] 
Simon
Maybe they see it that way, I don't. Anything that can be easily added to Node-RED to reduce the amount of JavaScript people (esp. beginners/non-coders) have to write is a "Good Thing" in my view. I think you've shown that they work well together.
I would love to see more teachers move on to Node-RED after kids get bored with Scratch. I think that it is a great tool to sit between Scratch and, for example, raw Python coding. Node-RED also would help more people get into web-based development and JavaScript. While I know that JS is not a brilliant language in many respects, it is critically important for web development and these days that means a lot more than just web sites - IoT and business applications too.
Wow! A lot to catch up on here. Firstly let me say that, while I realise this has grown into something rather larger than anticipated, it is fantastic work and I believe it to be a real asset to Node-RED.
A quick aside on the object vs drop-down for global, etc - I actually like the idea of global, etc being a separate block and personally, I don't find the fact that you can then "misuse" it a problem. In fact, it may become a strength. Why shouldn't you be able to set flow.fred to flow? You can most certainly do this with JavaScript and it might even occasionally be useful, who knows? Just my thought anyway, I certainly don't object to the dropdown. Though it might become a maintenance pain in the future if other options ever become available. I would think separate blocks would be easier to develop, especially if other people start to contribute.
On another point, I would encourage you, Bart, to use semantic versioning when developing. It isn't a problem to get a version like 0.0.9999 but it makes it a lot easier for people to follow along.
Yes please. I think this is a lot easier for people to read in general.
Yes
I'd be against this anyway if it appears as "magic" - e.g. not immediately obvious to novice users.
While I understand Nick's warning on this, I do like it as an option. But, as Nick well knows, I do tend to make things over complex. 
Failing this, I agree that you should stick with the 1-based approach in line with Blockly with a note in the help for the node.
Hi guys,
I have put a new version on Github.
@TotallyInformation: will use the semantic versioning when published. Didn't even know that the version numbers should be updated in a test phase...
Summarized what has changed:
- The inputs of all my blocks are now inline based on the enormous amount of votes I received.
- A new byte-block has been added, which accepts values from 0 to 255. This allows me to control the value when a byte value is set:
TODO: when this byte block is replaced by other blocks (to calculate the byte value dynamically), then the code generator should show an error. In the console or where ??? - Blockly is 1-based, while Javascript is 0-based. Therefore the buffer indexes are now automatically decremented during code generation:
- Three new blocks have been added for flow, global and context. There data type is 'Object'.
- The Node-RED memory get/set/keys blocks have been removed (from the Node-RED category). Instead an object keys block has been added (in the Objects category), that can get the property names both of normal objects and also from the 3 Node-RED memory blocks. Moreover the object get/set blocks have been changed so they can both handle normal objects and also the 3 Node-RED memory blocks. The code generation will automatically produce other code for objects or memory:
- TODO I should add a default buffer input to some blocks (in the Buffer category), otherwise syntax errors will ge generated:
Does anybody have a tip about which default buffer value? An empty buffer? I'm not allowed to produce syntax errors, because errors are not displayed (in contradiction to the function node where a red circle on top of the node in the flow indicates syntax errors).
Hopefully we are getting near to a npm version now ...
Bart
1 Like
Lovely
I'm keeping any further comments to myself as they are just look/feel ones and can be easily changed/ignored after you publish it out
Apart from
Rule 1 of Version Club: EVERY change should have an incremented version number 
1 Like
or is that rule 1.0.1 ? 
2 Likes
Here is a proposal to get rid of the syntax errors in the Buffer category.
To make sure there is always by default a buffer as input available, I created a new empty-buffer block.
That block is not available in the toolbox (since you cannot do anything with it), but it is added automatically to al the buffer inputs as shadow blocks:
Does it make sense to solve it like this? The change is available on Github for testing...
@cymplecy: I have the impression that you are a bit spoiled today. All your requests have been implemented in the blockly node, and Node-Red version 0.19 is installed on your machines 
If you think that I can quickly implement your new questions, please post them ...
Do you guys have the impression that this version is getting ready for NPM. I want to avoid that in the next version (with timer support) there will be major backwards compatibility problems so our users run into problems with their old Blockly workspace ...
I will start adding documentation and examples to the readme page, as soon as you guys think that the look-and-feel is ready to go ...
I am VERY spoilt today
My easily implentable suggestion is order of the blocks
I'd like to see most commonly used (from beginners point of view as always) blocks near the top
NodeRED category
send
msg
flow
global
(node)context
(then I don't care)
msg doesn't NEED to be second but I think it should be as its important and familiar but I know this isn't a logical arguement
Objects
get object msg and set object msg should be at top
Minor - do we need to say object in get object msg property payload?
Is it not implied by the fact that we are in the object category?
(Just trying to save horizontal space)
And contrevsioally, I'm thinking that not ALL blocks should be inline..........
I think in general, get blocks should be inline but set ones should be external
(But since we can choose it ourselves its not a big issue)
Simon
PS What method do you use to make your nice looking little GIFs?
I think something is bound to break but I'd say its good enough to launch
BUT...
I do have one existing Blockly node in a working flow that needs changing but its not allowing me to edit it (it will allow me to edit it but it doesn't save and deploy button doesn't become active)
Is it possible to manually use a text editor to edit something somewhere to fix it so I don't have to redo the block (as its one of those with 10 if statements....)
I keep starting other posts with suggestions but then I manage to delete them again before posting
I AM NOT GOING TO SAY ANYTHING MORE UNTIL ITS LAUNCHED
I assume there is some error in the code generation, so he doesn't change the generated-code field. If you are using chrome, you can show it in the developer tools (console panel).
Perhaps I should show the error somewhere...
Don't know if this can help you, but in .json file you can lookup your Blockly node:
The "func" field contains the generated Javascript, while the "workspaceXml" field contains the Blockly workspace in xml (i.e. your Blockly drawing).
But that is the problem being a tester, since backwards compatibility was not a concern yet ...
Will have a look at that this evening, because I want my screenshots and animated gifs in the documentation to correspond as much as possible with the real current screen layout.
P.S. I make the animated gif files with the free GifCam tool. Some people might get a epileptic seizure by reading through the above discussion, but it is a quick way to demonstrate Blockly to people that haven't installed our experimental version...
That doesn't sound good, even for a non-native English speaking person like me. Could you explain this a bit?
How can you choose it? I don't hope you are referring to the context menu item I was referring to in one of the previous, because it seems that it doesn't work that way: you cannot switch between inline or external inputs! Which blocks do you want to have external inputs ?
I think you can
Its means it is OK to launch
Damn haven't noticed that an extended popup is displayed when right-click on top of a block. Have big digging to much in the technical details of Blockly ... Good catch !!
Following two changes:
are both available on Github. Here is the result:
Ok, then I can start writing documentation ...
Would be nice if you could quickly review the documentation.
2 Likes
Ta for info
Its not worth the effort to try and edit the .json - I'm just going to recreate the node
Simon
I concur. A new launch is always exciting - of course, you always find a fault as soon as you've pressed the button! That must be rule 1.0.2! 
1 Like
I am breaking my promise 
I think status node is not quite right
I'm making a Blocky gate node and I wanted to set a status of closed with a red dot when its closed when its blocking messages - all good - works fine
But I want to clear the status when the gate is open and letting messages thru
I tried leaving the text input empty - got an error when tried to use it
Tried putting in text block with no text - got error
Tried putting in text block with single space - no error but coloured dot is still visible
Simon
And I don't think you are allowed to use orange as a colour - I think it should be yellow
Simon
