Closed Gauntlet173 closed 1 year ago
I don't think I'm getting this error with the new relationship declaration blocks, and it might have something to do with an extraneous listener. See if re-implementing using the relationship declaration pattern helps.
I'm getting errors in two different circumstances. One, when the current workspace is loaded. The other when workspaces are loaded for the purpose of getting the Category list.
In both cases, the list of known categories isn't available when the block is being constructed.
The easiest thing that might work would be to put the current list in the mutator, build the block from its mutator data, and update it automatically when the list of categories changes, or when the search for categories is finished on load.
So everything has a current value and a list. You build the dropdowns using those. The getCategories code runs once, and when it finishes it updates the lists of all of the blocks that have category lists. Maybe we could have the dropdowns register themselves, to avoid needing to hunt for them. Then, if a category block is added, or changed, or deleted, we update the list and update the dropdowns.
Later, we might find some way of warning the user that a block has been set to a value that isn't in its list. Will add that as an enhancement.
OK, I have it working for the new_object_category block, now I just need to re-implement for attribute and relationship declarations.
First, set the menu generator to a reasonable default (nothing for categories) Then, save the current options and the current selected value for each dynamic dropdown to the mutator and restore them from the mutator. Lastly, add code to the updateLocalCategories to go through all of the blocks and update all the relevant fields. Remove the extraneous functions inside the options for generating options.
It is almost working. v1.6.10-alpha is saving the information, but when I load a previous version .blawx file, save it in the new format, and re-open it, I'm getting a bunch of errors that seem to stem from a mismatch between how many properties it is expecting to find and how many are actually there? I suspect there is a counting error in the domToMutation mutationToDom pairing, somewhere, but it doesn't make obvious sense to me, yet.
I think the problem was in the dom to mutation loop through the fields, and it's sorted now. Only code that experienced the problem will need to be manually corrected, and there should be none of it.
Playing with 1.6.11 for a while, this seems to have been resolved.
right now the mutators for the new attribute declaration and new object declaration blocks are using a Kludge in order to set the value on deserialization, which causes errors in the console. I genuinely don't know if there is a better way to do it, searching the Blockly documentation has given me jack squat except people trying to fix this problem for the last 3 years.