Find replace function

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."

I don’t know if I should answe this as it’s still in active development

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! :grinning:

In my opinion I think it’s cool this is even possible knowing how limiting manipulating block stacks are in snap

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.

Find and replace code script pic (4)

This is a bug report, isn’t it? :smirk:
I’ll look into it … soonish.
(or perhaps you already spotted the bugger?)

If a WILDCARD is used, it works as intended:


This may help debugging the issue.

i did not. btw the first version of block looked better :3

I found what caused the issue
Within the decomposition of your search pattern:

Find and replace code script pic (30)

... 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:

Find and replace code script pic (34)

The search algorithm matches the first {null} it finds within the search pattern with, in this case:

Find and replace code script pic (32)

... and subsequently tries to match this with any code fragments corresponding to further occurences of {null} within the search pattern, in this case:

Find and replace code script pic (35)

... 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. :smirk:

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.

@luna.judah: Anyway, thanks for the bug report!

A brute force fix could be to detect if this would be an issue and then if it is use a wildcard

Could you explain / elaborate?

You said the fix is to use a wild card so you could determine if without the wildcard would be an issue, then add one in if it is an issue

I think the snap team needs to make manipulation of block stacks easier

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 Find and replace code DEV script pic, complementing Find and replace code DEV script pic 2, facilitating the use of wildcards in C-shaped command slots.

Link to Find & Replace project.

On my list of projects is a metaprogramming library that would create a slightly simpler and more uniform syntax tree format.

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

Ugh bletch.

Who are you asking?

It should be straightforward to make a block translation dictionary.

Thanks for the compliment!
(did you have a better solution in mind?)

Yeah, case-independent naming! (You can use the same name for two blocks, one a command, one a reporter...)