So I am just putting the finishing touches on a macro abstraction that is a real time saver and does all sorts of fun stuff and can use plain old regular abstractions as the macro files or be extended well beyond into quite complicated macros while still following the standard pd patch methodology, arguments, dynamic number of ins/outs, variables, etc. But it has one major flaw, if you apply the object by using the autopatching/placing the next object the new object will be connected to the abstraction which deletes itself, not the new objects the abstraction patched in and if you undo that will crash pd since the abstraction no longer exists; you have to apply the abstraction by clicking in the window or risk creating a situation that can crash pd. So I am looking for work arounds and a TCL plugin seems like it would be the best bet, my plan was too intercept the new object creation, check if it is the macro abstraction and if it is apply the object by sending a deselect then wait a few milliseconds so the abstraction can do its thing before placing the object (part of the macros is which object/objects to select on shutdown). I am having very slow progress in finding my way through pd's TCL and I am not even sure if what I intend is possible so hoping some of you can point me in the right direction, offer alternatives, or any sort of help.

@whale-av Anything done from within the macro abstraction will be done after the connection is made to the abstraction if you apply by pressing control-1 to place the next object, so any work around like simulated clicks would be done after that connection is made which means it is to late, I tried everything including disconnecting the macro abstraction before it deletes itself but no luck since that connection is in the undo history and if you undo it you get a crash. Here you can see that if you place the new object with Control-1 or the like there will be no connection to it from the objects which the macro patched in, it was made to the macro object which deleted itself and when you do the undo you get the crash.

Think I explained things better this time, becoming stupid from fighting with TCL/TK for far too long, but I think a TCL plugin is the only way short of a full fledged external.

@oid I am not sure that you can interrupt the gui/pd communications for a "put" with a plugin. Maybe you could unbind the shortcuts and do what you want with them in a plugin, programming what you need before returning the result to Pd with pdsend.
I spent some time long ago and modified pd_menucommands.tcl and pd_menus.tcl to add a new menu with a drop down choice to the gui window (the files are in woof.zip in the first post of the link below).

That could be a route to try. You can then make your own snippets of code to solve this specific problem, while keeping all other menu items as they are........
https://forum.pdpatchrepo.info/topic/9991/woof-a-new-window-menu-for-vanilla-tcl
The tcl was for Pd 0.46-7 so you would need to paste the parts that I inserted into the two files into the latest versions of them.
Obviously having a backup would be best....
I marked (bracketed) the changes with "MMMMMMMMMMMMMMMMMMMMMMMMMMMMMM"

pdsend is used by undo and redo and editmode in the current version of pd_menucommands.tcl so that gives an indication of how to format the messages that you will need to send to Pd once you have done your modified action.
You can test the messages to Tk/tcl and to Pd from within a patch using the [sys_gui] external..... tcl_message_2.pd ...... has examples of both.
David.

@whale-av I attempted playing with the menus but I am trying to avoid actual editing of pd's tcl since the purpose of this plug-in is making the abstraction something which can be easily shared, seems there is little you can do there with a plugin since these are mostly run at startup and forgotten? I think I am getting closer, I can redefine the procs in pdtk_text, mainly pdtk_text_new which is the new object creation proc and pdtk_text_set which provides the text in the currently edited object. Have pdtk_text_set test the current object to see if it is the macro abstraction and set a variable if it is, then when pdtk_text_new is called if the variable i set then deselect all before doing the rest of pdtk_text_new. This assumes pdtk_text_new is run before the connection is made, which I think it is, even if it is not I can use pdtk_text_set to make default binding work but the Put menu and custom bindings still present an issue. Thanks for that bit on the tcl message and cluing me in on HCS/sys_gui, will be very helpful.

@oid have you tried using iemguts objects for this? specifically [initbang]?
posting the patch may help as well..

@seb-harmonik.ar Quick test suggests [initbang] happens too late, the event has been added to the undo history by then and there seems to be nothing I can do at that point. My [msg] abstraction has the same bug and is far simpler. https://forum.pdpatchrepo.info/topic/14071/msg-a-message-object create a new object, use [msg] on it, control-1 or the like to autoplace the new object, undo and watch pd crash.

@seb-harmonik.ar Have not had much luck getting this too work, I suspect having [initbang], [loadbang], and [closebang] as well as not completely understanding how the scheduler works keeps it out of reach for me. The [closebang] is buried in [macro$0execute]/[macro$0errata] and used to be a [del 0] getting its bang from the [trigger] until you clued me into what the delay was doing. Reverted the patch to before my attempt and in [macro$0execute] I included a quick outline of what each subpatch does as well as the very preliminary help for the macros themselves in the subpatch there, should be enough to get you orientated. Also included is the basic counter macro in the macros folder, [m count] will run it.

Edit: I am guessing the select logic will not really work with this fix? The autopatched object will always be connected to the last object? Will also require a tweak of the macros to make it connect to the proper object but that is trivial.

@oid wow that is involved.. I'm trying to wrap my head around it, but did you try just putting the [del 0] right after the [loadbang] in m.pd?

not sure about the [closebang] stuff.. why not just do everything before triggering [canvasdelete]?

@seb-harmonik.ar Yeah, it got fairly complex, some things are done kind of weird for ease of bug hunting/sorting out the final details but it is a fairly complete macro system for pd and it won't get much simpler, just abit. Putting a [del 0] before the [loadbang] just causes it too crash if you use the auto patching. The [closebang] stuff will not work if done on the [loadbang], nothing ends up selected after it deletes itself. I fought with your [del] trick for a good while, not sure it can be done on this one but I don't really know. I did get it too not crash on undo once, but the autoplaced object ended up unconnected and stuck to the cursor instead, not sure how I did that and have not been able to reproduce it.

My current plan is going back to TCL but I have not had much luck there either but I am slowly making progress and I might get that too work. Installed tclpd to explore that some but not thrilled about it as a solution since the deken version seems broken and compiling it was a bit of a pain so any solutions done that way do not really help make the abstraction something that can be uploaded and shared. A proper external is probably the way this abstraction should be done, but that is a bit beyond my ambition at this time.

So I got a TCL solution partially working. Rebound control-1..5 so they now test the contents of the current object to see if it is the macro, if it is it toggles editmode off then on to deselect all, waits a few ms and places the new object. Works well but only works for default keybindings and does not work for objects placed from the Put menu, but I am not sure there will be a simple solution for the Put menu.