[PD] "vis 1" message creates hanging atoms

[Liam Goodacre]

Here is a curious little bug that I've been trying to solve for days. If you use the "vis 1" / "vis 0" messages to dynamically open and close a patch, sometimes the atom objects (float or symbol) hang in the GOP area. By hang I mean that a dead copy is created just below the original atom. It doesn't function, but it stays there on the canvas if you move the GOP object, and it can't be selected or deleted. I am attaching a little patch which demonstrates this.

My guess is that this has something to do with the grey rectangle that is usually imposed over the GOP area when you open it through the menu. This doesn't work when you use the "vis 1" message, and so the parent canvas must be receiving a TCL command to recreate the float, when it wasn't destroyed in the first place.

Does anyone have a clearer idea of what is going on, and, more importantly, how I can work around it? I know that dynamic patching isn't officially supported, but I'm still crossing my fingers for a way to prevent this bug.

A few more curiosities:

1. If the abstraction patch is empty apart from the float, the bug doesn't seem to occur. Try deleting the [metro] ad [f] objects in the "nofloat" patch to see this.
2. If I repeat the process by opening and closing through "vis 1" a second time, the first hanging float starts to disappear. This works in the attached demonstration patch, but not in the patch that I'm trying to build. Could this have something to do with the number of other objects, as in point 1?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151229/3ee1f789/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hanging-float.zip
Type: application/zip
Size: 658 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151229/3ee1f789/attachment.zip>