The settings button is a possible compromise between visibility and invisibility; it tells users that the block will do something reasonable even if you don't click it. But I think clicking it would put the options in the block itself, as in my pictures earlier in this thread; your separate window suggests that the options would apply to all uses of CONTAINS in this project, and I don't want to have to remember those things in a hidden global variable like the settings-menu settings, and anyway wouldn't want to change the behavior of instances of CONTAINS you put in your code earlier. You can get the equivalent of global options by making a custom block that just calls CONTAINS with the options you want.
P.S. The nomenclature "by reference" won't mean anything to most of our users. We call it "identical."
As I see it, if the settings were to apply to all uses of the block within a project, they would have to be set through the block definition procedure. Even so, come to think about it, it’s hard to imagine how the optional settings, if they’re in a pop-up window or so, could be specified by a calling script. Well, anyway, it was just a suggestion, and it’s totally up to you and the team to decide if and how you would like to implement optional settings.
Hey @cookieclickerer33, you’re always entitled to contribute your opinion, especially when thoughts are being shared about some feature that still has to be developed, and perhaps even more so in a topic that you started yourself!
If the block author knew how the user would want the settings set, the block wouldn't need settings in the first place! The situation we're talking about is that a library block or a primitive has options, the user clicks on something to ask to set one or more options, and then (1) do we want the resulting change in settings to apply to every use of the block? and (2) will a proposed UI make it look to the user that the change will apply to every use? And then try to make those two answers line up.
I found what caused the issue
Within the decomposition of your search pattern:
... both ITEM 2 OF () and ITEM 2 OF (ITEM 3 OF ()) are {null}.
Let's see what happens when the search algorithm tries to match this with your code fragment:
The search algorithm matches the first {null} it finds within the search pattern with, in this case:
... and subsequently tries to match this with any code fragments corresponding to further occurences of {null} within the search pattern, in this case:
... which is different from the former. Now it concludes that code fragment doesn't match the search pattern, since there is no consistent "translation" from {null} in the search pattern to all of the corresponding items in the code fragment.
All of this juist goes to proof that metaprogramming Snap! isn't as easy as it may seem.
Solution
Like I pointed out in post #87, you could use WILDCARD as a workaround, since it needs just a single match.
I'm not satisfied with this myself, of course - I'll be looking out for a more fundamental solution.
I'm going to try (one of these days) to use separate internal wildcards for each {null} within a code fragment. Not sure if it will help.
Update
I now slashed the whole concept of treating {null} as a wildcard. It’s just too complicated, and will never work flawlessly. Instead I created a block , complementing , facilitating the use of wildcards in C-shaped command slots.
Would it be possible to make this work with the “my [scripts v]” block
I wanna make a way to replace every sound block in a project with the one that makes sounds work on mobile