Try this:[tgl]|[dirty $1(|[send c] [namecanvas c]

 On Friday, November 6, 2015 6:56 PM, Thomas Mayer <thomas@residuum.org> wrote:

Hello,

I am developing a dynamic abstraction that depends on arguments.

As I am dynamically deleting objects, the abstraction is opened, and then closed again using [; $1 menuclose(, with $1 being the name of the canvas set before with [namecanvas $0-r].

This is working well, but when I close a patch with the abstraction included, Pd prompts me to save the opened abstraction.

I have also tried different float values as additional parameters for menuclose. (https://github.com/residuum/Puredata-abstractions/blob/master/glue/switch-ma...)

I am not sure if this is an error by me or if I have found a bug. If I have found one or even two, I will report them.

Reading the source of g_editor.c (https://github.com/pure-data/pure-data/blob/master/src/g_editor.c#L1974), I see that 1 should disable the check for modified content (no call to glist_finddirty(x)), but on closing Pd still asks me for confirmation.

Using 3 will close Pd, which of course is undesired.

Using 2 does segfault: Program received signal SIGSEGV, Segmentation fault. 0x080962c4 in pd_symbol () (gdb) backtrace #0  0x080962c4 in pd_symbol () #1  0x08098d8c in outlet_symbol () #2  0x080d4fe2 in ?? () #3  0x08098bd3 in outlet_bang () #4  0x080d884b in ?? () #5  0x080d8b51 in ?? () #6  0x08098d07 in outlet_float () #7  0x08097fef in ?? () #8  0x08098d07 in outlet_float () #9  0x080d883b in ?? () #10 0x080d8b51 in ?? () #11 0x08098d07 in outlet_float () #12 0x080d76ae in ?? () #13 0x08098e23 in outlet_list () #14 0x08098e23 in outlet_list () #15 0x080d87d9 in ?? () #16 0x08098e23 in outlet_list () #17 0x080d7e30 in ?? () #18 0x08098d07 in outlet_float () #19 0x08097fef in ?? () #20 0x08098d07 in outlet_float () #21 0x08098d07 in outlet_float () #22 0x080d4c62 in ?? () ---Type <return> to continue, or q <return> to quit--- #23 0x08098bd3 in outlet_bang () #24 0x080d884b in ?? () #25 0x080d8bd2 in ?? () #26 0x08098bd3 in outlet_bang () #27 0x080978d9 in pd_typedmess () #28 0x08097aaa in pd_vmess () #29 0x0805966a in canvas_loadbangsubpatches () #30 0x080596e3 in ?? () #31 0x08059690 in canvas_loadbang () #32 0x080978d9 in pd_typedmess () #33 0x08097aaa in pd_vmess () #34 0x0809626a in pd_doloadbang () #35 0x080a0568 in glob_evalfile () #36 0x080a2dd7 in ?? () #37 0x080a3d62 in glob_initfromgui () #38 0x0809f324 in binbuf_eval () #39 0x080a65f1 in socketreceiver_read () #40 0x080a5bcc in ?? () #41 0x080a2a78 in m_mainloop () #42 0x080569bb in main ()

I have found the same behaviour in Pd vanilla 0.46 Debian and Windows and Pd extended 0.42 Debian and Windows

Thanks, Thomas

On 11/07/2015 12:45 AM, Thomas Mayer wrote:

As I am dynamically deleting objects, the abstraction is opened, and then closed again using [; $1 menuclose(, with $1 being the name of the canvas set before with [namecanvas $0-r].

i always find it most inelegant to use gui interaction for dynamic patching. will it work is you ever want to run your patch in with "--nogui"?

a solution for deleting objects (including the abstraction itself) is using iemgut's [canvasdelete]. after loading the object, you can send a message to a canvas to delete an object by index:

[delete <ID>( | [s <canvasname>]

obviously this is not Pd-vanilla any more.

gfmadsr IOhannes