Commit 50cf48fe authored by Jonathan Wilkes's avatar Jonathan Wilkes
Browse files

Fix nasty bug with array name not updating properly on its graph, plus a more...

Fix nasty bug with array name not updating properly on its graph, plus a more trivial bug with the canvas properties not getting updated properly
parent 61574038
......@@ -262,7 +262,7 @@
</fieldset>
<div class="submit_buttons">
<button type="button" onClick="ok()" data-i18n="[title]iem.prop.ok_tt">
<button type="button" id="ok_button" onClick="ok()" data-i18n="[title]iem.prop.ok_tt">
<span data-i18n="iem.prop.ok"></span>
</button>
<button type="button" onClick="apply()" data-i18n="[title]iem.prop.apply_tt">
......@@ -295,6 +295,12 @@ var pd_garray_attrs;
var new_array_dialog;
function ok() {
// Put the focus on the "ok" button, to make sure we call the change
// method for an attribute. For some reason I don't need to do this
// in the iemgui dialog, but I haven't looked close to figure out why.
// A lot of this could probably be abstracted out, but I'm not sure of
// the best way to do that yet.
document.getElementById("ok_button").focus();
apply();
cancel();
}
......
......@@ -746,9 +746,34 @@ void garray_arraydialog(t_garray *x, t_symbol *s, int argc, t_atom *argv)
x->x_outlinecolor = outline;
x->x_style = style;
if (size != a->a_n)
{
garray_resize(x, size);
}
else
{
/* So, this next function call is here _solely_ to get the
the new array name to show up in the graph label if the user
happened to change it. Let me emphasize-- in order to
redraw array labels, we must call a function that redraws
not only the _entire_ array and its graph, but also redraws
the parent canvas in which the graph is displayed. There is
no interface I can find to just say, "redraw the label".
Worse, Pd redraws a single array at least 3 times, and maybe
even the graph and the containing glist-- it's hard to tell
because so much data is sent over the wire that I run out of
buffer in my terminal window. These are a side-effect of
garray_redraw, as well as the garray_resize branch above. (And
don't forget that the canvas dialog callback probably causes
as many redraws as well.)
Until the Pd codebase handles redrawing in a sane fashion,
without depending on a vast array of side-effects, there's
simply no way to effectively maintain it. */
glist_redraw(x->x_glist);
garray_redraw(x);
}
//fprintf(stderr,"garray_arraydialog garray_redraw done\n");
garray_select((t_gobj *)x,glist_getcanvas(x->x_glist),1);
canvas_dirty(x->x_glist, 1);
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment