Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
Ok, here's the fix. This solves all but a few of the similar errors at
patch closing (e.g. open the same pd patch-> open subpatch-> close
subpatch-> close main patch-> get 2 errors invalid command name
"..c".). This remaining bug does not happen if you close
the entire patch with both windows open.
At any rate, the other fix is attached.
ico
--- ../src_old/g_editor.c 2009-11-02 12:10:00.0 -0500
+++ g_editor.c 2009-11-19 01:35:36.0 -0500
@@ -67,7 +67,8 @@
{
t_object *ob;
if (!glist->gl_havewindow && glist->gl_isgraph && glist->gl_goprect &&
-glist->gl_owner && (pd_class(&glist->gl_pd) != garray_class))
+glist->gl_owner && (pd_class(&glist->gl_pd) != garray_class) &&
+ glist_isvisible(glist))
{
/* if we're graphing-on-parent and the object falls outside the
graph rectangle, don't draw it. */
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] bug when redrawing gop within gop inside a closed sub-patch
Please see attached patch. it appears whenever there is change in the gui of a closed sub-patch that has GOP sub-patch showing another GOP-ed subpatch (try reading that aloud) the redraw is attempted resulting in an error in a console. Probably the best thing is to test the attached patch. The good news--this is a non-lethal bug. Basically run pd from terminal, open the patch and try changing the symbol value. You will likely get an error on the shell (not Pd console) stating: invalid command name ".x89d1d08.c" (or whatever the name is of the sub-patch) Now if you open the sub-patch [pd tester] that has a subpatch with GOP and another one below it in a GOP (visible through parent GOP), everything is fine. #N canvas 258 155 296 207 10; #X symbolatom 115 54 10 0 0 0 - - -; #X obj 115 76 s test; #N canvas 538 176 297 192 tester 0; #N canvas 7 175 450 300 asdasdasda 0; #N canvas 2 50 450 300 blah 0; #X symbolatom 110 120 10 0 0 0 - - -; #X obj 113 29 r test; #X obj 98 61 prepend set; #X connect 1 0 2 0; #X connect 2 0 0 0; #X coords 0 -1 1 1 85 60 1 100 100; #X restore 127 119 pd blah; #X coords 0 -1 1 1 150 90 1 100 100; #X restore 66 44 pd asdasdasda; #X coords 0 0 1 1 300 80 0; #X restore 108 112 pd tester; #X connect 0 0 1 0; Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] netsend (and more) crash bug SOLVED (patch included)
Hey Ico,
You should post this to the patch tracker once you are ready to submit
it.
.hc
On Nov 18, 2009, at 11:40 PM, Ivica Ico Bukvic wrote:
Yay! Finally figured it out.
Please disregard my netsend patch, it's basically treating symptoms
rather than the source.
It turns out that the patch I submitted before to fix canvas GOP
toggle
on/apply/off/apply crash has been the cause of the problem all along
mainly because the final version had the second part nested, causing a
lot of problems at close time.
Namely, the old version is like this (prior to my patch):
void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
if (x->gl_editor)
{
for (y = x->gl_list; y; y = y->g_next)
if (ob = pd_checkobject(&y->g_pd))
rtext_free(glist_findrtext(x, ob));
editor_free(x->gl_editor, x);
x->gl_editor = 0;
}
}
The currently broken patched version (the one I proposed earlier) is:
void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
if (x->gl_editor)
glist_noselect(x);
if (x->gl_editor && x->gl_list)
{
if (x->gl_list) {
for (y = x->gl_list; y; y = y->g_next)
if (ob = pd_checkobject(&y->g_pd))
rtext_free(glist_findrtext(x, ob));
//notice how this part is never reached if x->gl_list
//condition is not satisfied, yet it is reached in
//previous version...
//this is the cause of
//problems I've been experiencing
if (x->gl_editor) {
editor_free(x->gl_editor, x);
x->gl_editor = 0;
}
}
}
}
So, here's the correct version which still resolves two issues
pointed out before without introducing any known regressions. The
issues
once again are:
#1 crash when creating a new patch->create a sub-patch->open sub-patch
properties->enable GOP->apply->disable GOP (without closing
properties)->apply
#2 crash when creating a new patch->create a sub-patch->create an
object
*and leave elected->open sub-patch properties->enable
GOP->apply->disable GOP (without closing properties)->apply
CORRECT VERSION:
void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
glist_noselect(x); //necessary to resolve crash #2
if (x->gl_editor)
{
if (x->gl_list) { //necessary to resolve crash #1
for (y = x->gl_list; y; y = y->g_next)
if (ob = pd_checkobject(&y->g_pd))
rtext_free(glist_findrtext(x, ob));
}
//fix to make this condition independent from x->gl_list
if (x->gl_editor) {
editor_free(x->gl_editor, x);
x->gl_editor = 0;
}
}
}
Cheers!
ico
Information wants to be free.-Stewart Brand
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] netsend (and more) crash bug SOLVED (patch included)
Yay! Finally figured it out.
Please disregard my netsend patch, it's basically treating symptoms
rather than the source.
It turns out that the patch I submitted before to fix canvas GOP toggle
on/apply/off/apply crash has been the cause of the problem all along
mainly because the final version had the second part nested, causing a
lot of problems at close time.
Namely, the old version is like this (prior to my patch):
void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
if (x->gl_editor)
{
for (y = x->gl_list; y; y = y->g_next)
if (ob = pd_checkobject(&y->g_pd))
rtext_free(glist_findrtext(x, ob));
editor_free(x->gl_editor, x);
x->gl_editor = 0;
}
}
The currently broken patched version (the one I proposed earlier) is:
void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
if (x->gl_editor)
glist_noselect(x);
if (x->gl_editor && x->gl_list)
{
if (x->gl_list) {
for (y = x->gl_list; y; y = y->g_next)
if (ob = pd_checkobject(&y->g_pd))
rtext_free(glist_findrtext(x, ob));
//notice how this part is never reached if x->gl_list
//condition is not satisfied, yet it is reached in
//previous version...
//this is the cause of
//problems I've been experiencing
if (x->gl_editor) {
editor_free(x->gl_editor, x);
x->gl_editor = 0;
}
}
}
}
So, here's the correct version which still resolves two issues
pointed out before without introducing any known regressions. The issues
once again are:
#1 crash when creating a new patch->create a sub-patch->open sub-patch
properties->enable GOP->apply->disable GOP (without closing
properties)->apply
#2 crash when creating a new patch->create a sub-patch->create an object
*and leave elected->open sub-patch properties->enable
GOP->apply->disable GOP (without closing properties)->apply
CORRECT VERSION:
void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
glist_noselect(x); //necessary to resolve crash #2
if (x->gl_editor)
{
if (x->gl_list) { //necessary to resolve crash #1
for (y = x->gl_list; y; y = y->g_next)
if (ob = pd_checkobject(&y->g_pd))
rtext_free(glist_findrtext(x, ob));
}
//fix to make this condition independent from x->gl_list
if (x->gl_editor) {
editor_free(x->gl_editor, x);
x->gl_editor = 0;
}
}
}
Cheers!
ico
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] netsend (and more) crash bug
> As a follow-up to this problem, manually stopping metro before closing > the patch solves this problem, but that is not obviously the way to > ensure someone will remember to do so every time before closing... Another correction. This problem is not apparent in pd-vanilla (even though the source is the same) but it only affects the pd-extended. Bizzare... ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] netsend (and more) crash bug
> The problem is this fixes crashing in a non-rt version of Pd. The rt > version however still suffers sporadically from the same problem. It may > take several tries to instigate it, but when it finally occurs, in my > case the reopening of the patch at first misbehaves in that whatever I > do on canvas with a mouse or keyboard, everything is being reported > twice (e.g. clicking on the toggle creates an on and an off event, > creating a new object creates two, typing into it creates 2 letters per > each keypress, etc.). After that closing the patch crashes pd. I've had > this occur before as well but now at least the other bug with open > socket is not there any more. > > Any ideas as to why? As a follow-up to this problem, manually stopping metro before closing the patch solves this problem, but that is not obviously the way to ensure someone will remember to do so every time before closing... Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] netsend (and more) crash bug
Hi all,
In our recent troubleshooting trying to hunt down a mysterious crash at
patch closing we uncovered a bug that appears to be present in
pd-extended 0.41.4 and 0.42.5, as well as pd vanilla (svn checked out
yesterday). Following is reproducible on Linux 9.04 Ubuntu i386.
To reproduce the crash if you run the patch included below (pretty much
vanilla version of netsend/netreceive) as follows:
#N canvas 511 186 450 322 10;
#X floatatom 80 -44 0 0 0 0 - - -;
#X floatatom 71 32 0 0 0 0 - - -;
#X obj 125 -117 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1
0 1;
#X obj 74 -177 loadbang;
#X obj 71 5 netsend 1;
#X floatatom 212 -18 5 0 0 0 - - -;
#X obj 214 -44 netreceive 3000 1;
#X msg 80 -17 send \$1;
#X msg 71 -157 connect 192.168.1.8 3000;
#X obj 122 -95 metro 2;
#X obj 151 -53 +;
#X msg 114 -69 1;
#X connect 0 0 7 0;
#X connect 0 0 10 1;
#X connect 2 0 9 0;
#X connect 3 0 8 0;
#X connect 4 0 1 0;
#X connect 6 0 5 0;
#X connect 7 0 4 0;
#X connect 8 0 4 0;
#X connect 9 0 11 0;
#X connect 10 0 0 0;
#X connect 11 0 10 0;
1) save the patch and click on "connect" message
2) start the metro
3) close the patch *without* stopping the metro
4) reopen it again, and you'll find pd reporting that the old connection
still exists (explained below)
5) at this point you can start the metro again (it should work)
6) however, when closing the patch pd will crash
Part of the problem:
x->x_fd in netsend_disconnect is the same flag used in netsend_send
function, so when one tries to close socket but there is still a stream
of data coming in, because x->x_fd is reverted to -1 after the attempt
to close the socket, the data keeps coming in through netsend_send
function potentially (and I speculate here) preventing socket from
closing. This leaves a stale open socket and eventually causes the whole
thing to crash.
Below is the problematic code.
static void netsend_disconnect(t_netsend *x)
{
if (x->x_fd >= 0)
{
sys_closesocket(x->x_fd);
x->x_fd = -1;
outlet_float(x->x_obj.ob_outlet, 0);
}
}
Solution is changing the netsend_disconnect to create a temp value from
the x->x_fd, change x->x_fd to -1 to prevent other incoming data from
being processed, and only then try to close the socket.
This has apparently fixed part of the problem on our end here.
Please see x_net.c patch below:
--- x_net.c.old 2009-11-18 17:45:24.0 -0500
+++ x_net.c 2009-11-18 17:41:38.0 -0500
@@ -106,8 +106,9 @@
{
if (x->x_fd >= 0)
{
-sys_closesocket(x->x_fd);
-x->x_fd = -1;
+ int tmp = x->x_fd;
+x->x_fd = -1;
+sys_closesocket(tmp);
outlet_float(x->x_obj.ob_outlet, 0);
}
}
The problem is this fixes crashing in a non-rt version of Pd. The rt
version however still suffers sporadically from the same problem. It may
take several tries to instigate it, but when it finally occurs, in my
case the reopening of the patch at first misbehaves in that whatever I
do on canvas with a mouse or keyboard, everything is being reported
twice (e.g. clicking on the toggle creates an on and an off event,
creating a new object creates two, typing into it creates 2 letters per
each keypress, etc.). After that closing the patch crashes pd. I've had
this occur before as well but now at least the other bug with open
socket is not there any more.
Any ideas as to why?
Ico
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > On Nov 18, 2009, at 2:35 AM, Frank Barknecht wrote: >> If you use the route-approach, you can use settable routes (as an >> abstraction like sroute.pd in [list]-abs). But actually I have no idea why a >> settable receive should be necessary anyway? :) > > Why not have settable receives? I dont' see the downside or harm. In > this case, a settable receive is only possible via arguments and > dollarargs in the receive object box. I guess that's an old issue... I didn't mean to start a discussion on the general usefulness of settable receives (about which I have an opinion), I only meant your usecase, which as I understand is that you want to share a global or remote value like a video's FPS in many abstractions. For this I don't think you need a settable receive, as you can reserve a single, unchanging reveiver to receive such information, either a multi-use single-name receiver that distributes items with [route] or many separate receivers (with the namespace pollution problem). > Perhaps another approach would be to have a standard receive name for a > library, then make it local using routes. So something like [receive > framesync/framesync] then the next route would be the project ID, then > the standard bits of data (i.e. fps). Yep. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: > Why not have settable receives? iirc, the problem is that you can easily make Pd crash with settable receives. fgmar IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksETO4ACgkQkX2Xpv6ydvRDEwCfZno+azCeK6rT3EANV2Mshb0f dF4An3Zx85QXsag300tSIg0srPlr+Jn/ =OQTs -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Could you post the full pd.tk and the version of Pd its it supposed to
work with? Also:
- I attached a quick stab at turning your scrollbar logic into a 0.43
GUI plugin. It doesn't work because your code relies on Pd-extended
0.42 things, but if you make your algorithm into a plugin using this
framework, then people can just drop the file into the pd/startup
folder to use your algorithm.
- I created a wiki page to document this whole process, please add any
tests that you can think of here:
http://puredata.info/dev/ScrollBarLogic
.hc
icoscroll-plugin.tcl
Description: Binary data
On Nov 18, 2009, at 10:37 AM, Ivica Ico Bukvic wrote:
OK, try the one below instead (with ::scroll call removed). Also,
plase
don't forget to do the followign test with large graphics objects and
test scrollbar behavior:
1) create iemlib's number2
2) adjust its height to 60 and its font size to 50
3) drag it as far to the top as possible and what you will likely
discover is that it fails to reach the top corner *or* creates
scrollbars even though the object fits comfortably within the window.
This is not the case AFAIK with the version below.
Ico
proc pdtk_canvas_getscroll {name} {
global pdtk_canvas_mouseup_name
global pdtk_canvas_mouseup_xminval
global pdtk_canvas_mouseup_xmaxval
global pdtk_canvas_mouseup_yminval
global pdtk_canvas_mouseup_ymaxval
#bbox all is not accurate enough
#particularly when using large iemlib objects
#so we calculate canvas size manually
#set size [$name bbox all]
#borrowed from http://wiki.tcl.tk/4844
set x1 1.0e30; set x2 -1.0e30 ;
set y1 1.0e30; set y2 -1.0e30 ;
foreach item [$name find all] {
switch -exact [$name type $item] {
"arc" -
"line" -
"oval" -
"polygon" -
"rectangle" {
set coords [$name coords $item]
foreach {x y} $coords {
if { $x < $x1 } {set x1 $x}
if { $x > $x2 } {set x2 $x}
if { $y < $y1 } {set y1 $y}
if { $y > $y2 } {set y2 $y}
}
}
}
}
if {$x1 != 1.0e30} {
set xminval 0
set yminval 0
set xmaxval 100
set ymaxval 20
#set x1 [lindex $size 0]
#set x2 [lindex $size 2]
#set y1 [lindex $size 1]
#set y2 [lindex $size 3]
#pdtk_post "bbox all: $x1 $x2 $y1 $y2\n"
#pdtk_post "new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n"
#these work much better than the ones below
#they allow for intelligent translation of the canvas
#rather than introducing redundant scrollbars
set xminval $x1
set yminval $y1
set xmaxval [expr $x1+($x2-$x1)]
set ymaxval [expr $y1+($y2-$y1)]
#if {$x1 < $xminval} {set xminval $x1}
#if {$y1 < $yminval} {set yminval $y1}
#if {$x2 > $xmaxval} {set xmaxval $x2}
#if {$y2 > $ymaxval} {set ymaxval $y2}
#pdtk_post "$xminval $xmaxval $yminval $ymaxval\n"
set parentname [winfo parent $name]
set winwidth [winfo width $parentname]
set winheight [winfo height $parentname]
set canvaswidth [ expr {abs($xmaxval-$xminval)} ]
set canvasheight [ expr {abs($ymaxval-$yminval)} ]
#set canvaswidth [ expr {abs($xminval)+$xmaxval} ]
#set canvasheight [ expr {abs($yminval)+$ymaxval} ]
#pdtk_post "$canvaswidth $canvasheight\n"
#pdtk_post "$parentname [$parentname.scroll cget -state]\n"
#pdtk_post "scroll=yes $winwidth $canvaswidth\n"
if {$winwidth > $canvaswidth} {pack forget
$parentname.scrollhort}
if {$winheight > $canvasheight} {pack forget
$parentname.scrollvert}
if {$winwidth < $canvaswidth} {pack $parentname.scrollhort -fill
x \
-side bottom
-before $parentname.c}
if {$winheight < $canvasheight} {pack $parentname.scrollvert -
fill y
\
-side
right -before $parentname.c}
if {$pdtk_canvas_mouseup_name != $name || \
$pdtk_canvas_mouseup_xminval != $xminval || \
$pdtk_canvas_mouseup_xmaxval != $xmaxval || \
$pdtk_canvas_mouseup_yminval != $y
Re: [PD-dev] namespaces for send/receive
On Nov 18, 2009, at 2:35 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: So I guess to make it localizable, it would have to be something like framesync/fps$1. Without a settable receive, it makes this kind of chore to deal with then. If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :) Why not have settable receives? I dont' see the downside or harm. In this case, a settable receive is only possible via arguments and dollarargs in the receive object box. I guess that's an old issue... Perhaps another approach would be to have a standard receive name for a library, then make it local using routes. So something like [receive framesync/framesync] then the next route would be the project ID, then the standard bits of data (i.e. fps). .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
On Wed, 18 Nov 2009, Frank Barknecht wrote: If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :) One example is the GFDP (GridFlow Documentation Project), which uses settable receives because it uses receive-symbols that are local to the toplevel patch they are in (an intermediate between global and the ordinary local). This value has to be output by an object, so it cannot appear directly in an [r] box, and the GFDP doesn't use that much dynamic patching... _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
OK, try the one below instead (with ::scroll call removed). Also, plase
don't forget to do the followign test with large graphics objects and
test scrollbar behavior:
1) create iemlib's number2
2) adjust its height to 60 and its font size to 50
3) drag it as far to the top as possible and what you will likely
discover is that it fails to reach the top corner *or* creates
scrollbars even though the object fits comfortably within the window.
This is not the case AFAIK with the version below.
Ico
proc pdtk_canvas_getscroll {name} {
global pdtk_canvas_mouseup_name
global pdtk_canvas_mouseup_xminval
global pdtk_canvas_mouseup_xmaxval
global pdtk_canvas_mouseup_yminval
global pdtk_canvas_mouseup_ymaxval
#bbox all is not accurate enough
#particularly when using large iemlib objects
#so we calculate canvas size manually
#set size [$name bbox all]
#borrowed from http://wiki.tcl.tk/4844
set x1 1.0e30; set x2 -1.0e30 ;
set y1 1.0e30; set y2 -1.0e30 ;
foreach item [$name find all] {
switch -exact [$name type $item] {
"arc" -
"line" -
"oval" -
"polygon" -
"rectangle" {
set coords [$name coords $item]
foreach {x y} $coords {
if { $x < $x1 } {set x1 $x}
if { $x > $x2 } {set x2 $x}
if { $y < $y1 } {set y1 $y}
if { $y > $y2 } {set y2 $y}
}
}
}
}
if {$x1 != 1.0e30} {
set xminval 0
set yminval 0
set xmaxval 100
set ymaxval 20
#set x1 [lindex $size 0]
#set x2 [lindex $size 2]
#set y1 [lindex $size 1]
#set y2 [lindex $size 3]
#pdtk_post "bbox all: $x1 $x2 $y1 $y2\n"
#pdtk_post "new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n"
#these work much better than the ones below
#they allow for intelligent translation of the canvas
#rather than introducing redundant scrollbars
set xminval $x1
set yminval $y1
set xmaxval [expr $x1+($x2-$x1)]
set ymaxval [expr $y1+($y2-$y1)]
#if {$x1 < $xminval} {set xminval $x1}
#if {$y1 < $yminval} {set yminval $y1}
#if {$x2 > $xmaxval} {set xmaxval $x2}
#if {$y2 > $ymaxval} {set ymaxval $y2}
#pdtk_post "$xminval $xmaxval $yminval $ymaxval\n"
set parentname [winfo parent $name]
set winwidth [winfo width $parentname]
set winheight [winfo height $parentname]
set canvaswidth [ expr {abs($xmaxval-$xminval)} ]
set canvasheight [ expr {abs($ymaxval-$yminval)} ]
#set canvaswidth [ expr {abs($xminval)+$xmaxval} ]
#set canvasheight [ expr {abs($yminval)+$ymaxval} ]
#pdtk_post "$canvaswidth $canvasheight\n"
#pdtk_post "$parentname [$parentname.scroll cget -state]\n"
#pdtk_post "scroll=yes $winwidth $canvaswidth\n"
if {$winwidth > $canvaswidth} {pack forget
$parentname.scrollhort}
if {$winheight > $canvasheight} {pack forget
$parentname.scrollvert}
if {$winwidth < $canvaswidth} {pack
$parentname.scrollhort -fill x \
-side bottom
-before $parentname.c}
if {$winheight < $canvasheight} {pack
$parentname.scrollvert -fill y
\
-side
right -before $parentname.c}
if {$pdtk_canvas_mouseup_name != $name || \
$pdtk_canvas_mouseup_xminval != $xminval || \
$pdtk_canvas_mouseup_xmaxval != $xmaxval || \
$pdtk_canvas_mouseup_yminval != $yminval || \
$pdtk_canvas_mouseup_ymaxval != $ymaxval } {
set newsize "$xminval $yminval $xmaxval $ymaxval"
$name configure -scrollregion $newsize
set pdtk_canvas_mouseup_name $name
set pdtk_canvas_mouseup_xminval $xminval
set pdtk_canvas_mouseup_xmaxval $xmaxval
set pdtk_canvas_mouseup_yminval $yminval
set pdtk_canvas_mouseup_ymaxval $ymaxval
}
}
pdtk_canvas_ch
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
> > - when you select all and mouse drag components out of the current > > view, Pd-extended updates scrollbars immediately, Pd and Pd-devel > > update the scrollbars once you release the mouse, and Ico's gave me > > an > > error saying "Error: can't read "::scroll(.x6d5610)" > > > > - when you resize the window, Pd-devel updates the scrollbars live, Pd- > > extended updates live with glitches, Pd updates on release, Ico's gave > > me an error saying "Error: can't read "::scroll(.x6d5610)" > > > > .hc I think I now remember why this is--my pdtk has a feature where you can toggle scrollbars, menu, ontop, and background color, per window in a way that retains their properties even if they are temporarily closed (e.g. an embedded patcher). Hence, every window at creation generates global variables that retain that window's properties so if it is a patcher when it is restored, it reflects whatever changes have been made to it. I use abstractions with sys_gui extern to alter these properties (I believe I sent all this out in an email as well). Hence, if you don't wish to use my entire pdtk file, the pdtk_canvas-getscroll I copied in my previous email needs to be filtered to be used, since I have a check in there to skip the whole process if the scrollbars have been disabled. Simply look for lines with ::scroll($name) inside that function and circumvent them. Another thing to test with these pdtks is checking how the detection of borders/enabling of scrollbars is handled with larger fonts and you'll find out that without the fix attached in my pdtk you will get scrollbars when you shouldn't particularly the y one when using large font iemlib number boxes (I think I sent this out in my previous email as well). I'll try to send you an updated version of that method when I get to office. Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
