I was experimenting with using a Number2 object (stop your snickering) as a way to make a dynamic receive for floats and ran into what is probably a bug. The idea is that you can set the receive name dynamically like this:

This is all fine in the top-level of a patch, but if it's in an abstraction, then it sometimes generates one of those pink highlighted error messages in the parent window and then things are broken.

The problem happens when the receive name property of the Number2 object is empty. So just assign some placeholder receive name, save the abstraction, and you're good to go.

@jameslo i was wrong, it happens also if the parent patch is saved. perhaps i saved the abstraction with the new receive name... probably it is because with the edit properties of the gui elements you can also just replace the names and not create a new one?

This is interesting. it opens way to organic patching, where a portion of the patch can switch from one source of information/instruction/... to another, only depending on its own "appreciation". Decentralized, multi brains processing.

We can imagine multiple information bus, and a system made of little systems that go from one to another.

There are a couple of other interesting ways to do this that I'm aware of:
https://forum.pdpatchrepo.info/topic/11890/dynamic-receive-object
https://forum.pdpatchrepo.info/topic/11711/setting-receive-dynamically
Maybe there are more....

Both of these are more general than my hack, but I just needed to redirect floats.

@jameslo I think you can also use [value] for this.

@ingox I thought I had looked into that. Doesn't [value] have to be banged to get the current data? If so, then the receiver has to poll, which is not what I had in mind.

there are some plans for a dynamic receive: https://github.com/pure-data/pure-data/issues/603

@jameslo That is true. Here are some abstractions that can do dynamic send and receive: r+s+.zip

May not be suitable for pointers though...

@jameslo Looking at @jona's error it seems the message is being sent to the wrong os window name.
[sys_gui] is available again for 64-bit and a horrible hack might be possible...... but I don't want to go there.
@ingox There was a hack to deal with pointers...... but I think they are lost in the process...... unsure.......
convert_pointer2anything.pd
I have always done dynamic receives in the Gui's the same way as you have done......... this.zip
It is unreliable when setting an address remotely but local dynamic receive address setting works reliably.
I have a vague recollection that setting a label first somehow solved the problem you are having (see the zip).
It was a very long time ago..... and I posted something about Gui's needing some unexpected parameters set before others could be reliably reset.
Windows 7 all Pd. versions.
We could cry "bug" but obscure clues are liberally spread around here...... https://puredata.info/docs/developer/PdFileFormat
Some Gui's need all parameters defined........ maybe in much the same way as "dialog"'s.... except that until they are changed by a message they don't much care.
It could be that the message goes to the wrong field when another is empty.
(Caveat.... unlike @jona I cannot even reproduce your error when the parent is unsaved)
David.

I had the same issue. One of the threads @jameslo linked to suggested [iemguts/oreceive] which worked great for me. Using [value] is viable too and it's automatically updated in [expr~] expressions which helps a lot, but it has to be banged otherwise so I ended up using a combination of the two.