Sounds like you are saying that calls to canvas_fixlinesfor() shouldn't have calls to glist_getcanvas() in them. It seems not very straightforward, for example, the iemguis included in Pd-vanilla have this:

canvas_fixlinesfor(glist_getcanvas(x->x_gui.x_glist), (t_text*)x);

.hc

On Jul 14, 2010, at 3:15 PM, Miller Puckette wrote:

I think glist_getcanvas() is only appropriate when getting or changing properties that are inherited from the containing canvas (whether visible or not, for example) -- and many canvas_whatever(canvas, object) or glist_whatever(canvas, object) calls assume tha the oject is indeed in that glist itself (glist is synonym for canvas) and will crash if not.

cheers Miller

On Wed, Jul 14, 2010 at 01:17:41PM -0400, Hans-Christoph Steiner wrote:

...

I've noticed that in GUI objects, its quite common to call the canvas_* functions using glist_getcanvas(). I also just found out that this causes a crash in [envgen] when this is done for canvas_deletelinesfor(). See bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=2842897&gro...

So it seems to me that glist_getcanvas() should not be called on the glist before sending it to one of these canvas functions. I was wondering if this is kind of a blanket rule, and we should be removing the glist_getcanvas() calls in GUI objects. For example:

unauthorized/cooled~/cooled~.c: canvas_deletelinesfor( glist_getcanvas(glist), (t_text *)z); unauthorized/cooled~/cooled~.c: canvas_fixlinesfor( glist_getcanvas( x->x_glist ), (t_text*)x );

In ggee/gui/w_envgen.h, I fixed the crasher by replacing:

canvas_deletelinesfor(glist_getcanvas(glist), x);

with this:

canvas_deletelinesfor(glist, x);

.hc

---

"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

----------------------------------------------------------------------------

'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf

Ok, keep me posted. If that turns out to be wrong, I can change it in a lot of externals in SVN too.

.hc

On Jul 14, 2010, at 4:11 PM, Miller Puckette wrote:

I think those are all wrong and will try changing them over here :)

thanks M

On Wed, Jul 14, 2010 at 04:07:16PM -0400, Hans-Christoph Steiner wrote:

...

Sounds like you are saying that calls to canvas_fixlinesfor() shouldn't have calls to glist_getcanvas() in them. It seems not very straightforward, for example, the iemguis included in Pd-vanilla have this:

canvas_fixlinesfor(glist_getcanvas(x->x_gui.x_glist), (t_text*)x);

.hc

On Jul 14, 2010, at 3:15 PM, Miller Puckette wrote:

...

I think glist_getcanvas() is only appropriate when getting or changing properties that are inherited from the containing canvas (whether visible or not, for example) -- and many canvas_whatever(canvas, object) or glist_whatever(canvas, object) calls assume tha the oject is indeed in that glist itself (glist is synonym for canvas) and will crash if not.

cheers Miller

On Wed, Jul 14, 2010 at 01:17:41PM -0400, Hans-Christoph Steiner wrote:

...

I've noticed that in GUI objects, its quite common to call the canvas_* functions using glist_getcanvas(). I also just found out that this causes a crash in [envgen] when this is done for canvas_deletelinesfor(). See bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=2842897&gro...

So it seems to me that glist_getcanvas() should not be called on the glist before sending it to one of these canvas functions. I was wondering if this is kind of a blanket rule, and we should be removing the glist_getcanvas() calls in GUI objects. For example:

unauthorized/cooled~/cooled~.c: canvas_deletelinesfor( glist_getcanvas(glist), (t_text *)z); unauthorized/cooled~/cooled~.c: canvas_fixlinesfor( glist_getcanvas( x->x_glist ), (t_text*)x );

In ggee/gui/w_envgen.h, I fixed the crasher by replacing:

canvas_deletelinesfor(glist_getcanvas(glist), x);

with this:

canvas_deletelinesfor(glist, x);

.hc

---

"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

'You people have such restrictive dress for women,? she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - ?Hijab Scene #2", by Mohja Kahf

----------------------------------------------------------------------------

Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs

Likewise:

http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi... http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi... http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...

.hc

On Jul 14, 2010, at 4:33 PM, Miller Puckette wrote:

Ok .. commited and pushed to SF... On Wed, Jul 14, 2010 at 04:18:32PM -0400, Hans-Christoph Steiner wrote:

...

Ok, keep me posted. If that turns out to be wrong, I can change it in a lot of externals in SVN too.

.hc

On Jul 14, 2010, at 4:11 PM, Miller Puckette wrote:

...

I think those are all wrong and will try changing them over here :)

thanks M

On Wed, Jul 14, 2010 at 04:07:16PM -0400, Hans-Christoph Steiner wrote:

...

Sounds like you are saying that calls to canvas_fixlinesfor() shouldn't have calls to glist_getcanvas() in them. It seems not very straightforward, for example, the iemguis included in Pd-vanilla have this:

canvas_fixlinesfor(glist_getcanvas(x->x_gui.x_glist), (t_text*)x);

.hc

On Jul 14, 2010, at 3:15 PM, Miller Puckette wrote:

...

I think glist_getcanvas() is only appropriate when getting or changing properties that are inherited from the containing canvas (whether visible or not, for example) -- and many canvas_whatever(canvas, object) or glist_whatever(canvas, object) calls assume tha the oject is indeed in that glist itself (glist is synonym for canvas) and will crash if not.

cheers Miller

On Wed, Jul 14, 2010 at 01:17:41PM -0400, Hans-Christoph Steiner wrote:

...

I've noticed that in GUI objects, its quite common to call the canvas_* functions using glist_getcanvas(). I also just found out that this causes a crash in [envgen] when this is done for canvas_deletelinesfor(). See bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=2842897&gro...

So it seems to me that glist_getcanvas() should not be called on the glist before sending it to one of these canvas functions. I was wondering if this is kind of a blanket rule, and we should be removing the glist_getcanvas() calls in GUI objects. For example:

unauthorized/cooled~/cooled~.c: canvas_deletelinesfor( glist_getcanvas(glist), (t_text *)z); unauthorized/cooled~/cooled~.c: canvas_fixlinesfor( glist_getcanvas( x->x_glist ), (t_text*)x );

In ggee/gui/w_envgen.h, I fixed the crasher by replacing:

canvas_deletelinesfor(glist_getcanvas(glist), x);

with this:

canvas_deletelinesfor(glist, x);

.hc

---

"Free software means you control what your computer does. Non- free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

'You people have such restrictive dress for women,? she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - ?Hijab Scene #2", by Mohja Kahf

---

Programs should be written for people to read, and only incidentally for machines to execute.

• from Structure and Interpretation of Computer Programs

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

----------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.