OK,
So, I reenabled the workaround I had used before in pd-l2ork and all is well
again. But it still does use a workaround and an ugly one at that. Yet, that is
the *only* way I can see fixing this. The problem is essentially what I had
mentioned already cutting and undoing cutting a canvas
Bugs item #3459480, was opened at 2011-12-14 08:21
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=3459480group_id=55736
Please note that this message will contain a full copy of the
Le 2011-12-14 à 10:15:00, Ivica Ico Bukvic a écrit :
So, the only way I can ensure in pd-l2ork that this never happens is
that I enable global variable in canvas_new making sure that pd_new
function is aware its next allocation is for a canvas. I also maintain a
global single-linked list of
Mathieu Bouchard ma...@artengine.ca wrote:
Le 2011-12-14 à 10:15:00, Ivica Ico Bukvic a écrit :
So, the only way I can ensure in pd-l2ork that this never happens is
that I enable global variable in canvas_new making sure that pd_new
function is aware its next allocation is for a canvas. I
Le 2011-12-14 à 12:49:00, Ivica Ico Bukvic a écrit :
So what part of the code specifically binds keyboard and mouse actions
to a canvas?
Look for the name as it appears in Tcl commands going to Pd. From what it
looks like in commands to/from Tcl, you can see that it is a .x%lx
On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote:
...
Wow! You just helped me finally solve this riddle! Could it be really
this simple? In canvas_free() call inside g_canvas.c simply add the
following 2 lines:
if (x-gl_editor)
canvas_destroy_editor(x);
I added them right
Personally, I'm hoping to put band-aids on as many manaifestations of the
problem as I can track down (so thanks for this one :) and then re-design
the whole editor creation and destruction strategy for 0.44 - it looks
like it can never be fully debugged the way it's stet up now!
Miller
On Thu,
