Re: [PD] canvas window "relocate" message strangeness ...
hans w. koch wrote: hi, on mac os 10.14.6 and pd 51-0 i don´t see scrollbars in any your examples (i don´t have the propertybang installed, so your last case doesn´t apply) am i missing sth? no, but i was forgetting to include my specs ;-) this occurs in Debian (4.19.98), PD 0.50.2 i also tested it on Windows 7, no scrollbars there. obviously not on OSX either. [propertybang] is not necessary to test this. it just seems that remote messages to relocate a window position (that don't produce what i call "visual representation" of a "click") lead to this scrollbar occurance. ([propertybang] does such a thing. you right-click on an "abstraction" and a "PROPERTIES" entry can be selected, just like in a vslider etc. Inside this abstraction a bang is sent out the IEMGUTS object [propertybang] - which i then use to open a specific window) are there any other ways to open PD canvases with a specific size and position anybody here can think of ? best Oliver best hans Am 05.06.2020 um 01:40 schrieb oliver : Hi, i just discovered a really strange phenomenon when opening patch windows with remote messages Attached is a test patch that presents the "problem": The window is always opening with active scroll sidebars, even though there's nothing to scroll. The only exception is, when the "relocate" message mechanism is done "by hand". Messages that are sent remotely or with a delay produce the scrollbars. It really seems that the visual representation of a clicked BANG or a [message box( comes into play here, though i don't understand how or why. It seems as if only as long as the window messages are passed WITHIN the "visual representation time" (in lack of a better description ... i mean the short thickening of the border of a message box when it is clicked with the mouse) the window is opening as it should (without sidebars). I discovered this phenomenon using the [propertybang] external from IEMGUTS, where the window would only open with said sidebars. To make matters worse, this behaviour is not consistent, but seems a little random. What's sure though, is that only a direct mouseclick onto a bang or message box reliably opens the window without sidebars. Feels a little voodoo-ish to me ... Cheers Oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] canvas window "relocate" message strangeness ...
hi, on mac os 10.14.6 and pd 51-0 i don´t see scrollbars in any your examples (i don´t have the propertybang installed, so your last case doesn´t apply) am i missing sth? best hans > Am 05.06.2020 um 01:40 schrieb oliver : > > Hi, > > i just discovered a really strange phenomenon when opening patch windows with > remote messages > > Attached is a test patch that presents the "problem": > > The window is always opening with active scroll sidebars, even though there's > nothing to scroll. > > The only exception is, when the "relocate" message mechanism is done "by > hand". Messages that are sent remotely or with a delay produce the scrollbars. > > It really seems that the visual representation of a clicked BANG or a > [message box( comes into play here, though i don't understand how or why. > > It seems as if only as long as the window messages are passed WITHIN the > "visual representation time" (in lack of a better description ... i mean the > short thickening of the border of a message box when it is clicked with the > mouse) the window is opening as it should (without sidebars). > > I discovered this phenomenon using the [propertybang] external from IEMGUTS, > where the window would only open with said sidebars. > > To make matters worse, this behaviour is not consistent, but seems a little > random. What's sure though, is that only a direct mouseclick onto a bang or > message box reliably opens the window without sidebars. > > Feels a little voodoo-ish to me ... > > Cheers > > Oliver > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] canvas window "relocate" message strangeness ...
Hi, i just discovered a really strange phenomenon when opening patch windows with remote messages Attached is a test patch that presents the "problem": The window is always opening with active scroll sidebars, even though there's nothing to scroll. The only exception is, when the "relocate" message mechanism is done "by hand". Messages that are sent remotely or with a delay produce the scrollbars. It really seems that the visual representation of a clicked BANG or a [message box( comes into play here, though i don't understand how or why. It seems as if only as long as the window messages are passed WITHIN the "visual representation time" (in lack of a better description ... i mean the short thickening of the border of a message box when it is clicked with the mouse) the window is opening as it should (without sidebars). I discovered this phenomenon using the [propertybang] external from IEMGUTS, where the window would only open with said sidebars. To make matters worse, this behaviour is not consistent, but seems a little random. What's sure though, is that only a direct mouseclick onto a bang or message box reliably opens the window without sidebars. Feels a little voodoo-ish to me ... Cheers Oliver #N canvas 42 256 984 291 12; #X declare -stdpath iemguts; #X obj 27 200 cnv 5 5 17 empty empty empty 20 12 0 14 -194593 -66577 0; #X msg 33 141 vis 0 \, relocate \$1x\$2+0+0 0x0+\$3+\$4 \, vis 1 \, editmode 0, f 20; #X obj 33 200 s pd-\$0-subpatch; #N canvas 42 92 400 100 \$0-subpatch 0; #X text 95 35 Put in anything you like; #X restore 33 244 pd \$0-subpatch; #X msg 33 113 400 100 30 30; #X obj 213 92 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 207 232 cnv 5 5 17 empty empty empty 20 12 0 14 -194593 -66577 0; #X msg 213 173 vis 0 \, relocate \$1x\$2+0+0 0x0+\$3+\$4 \, vis 1 \, editmode 0, f 20; #X obj 213 232 s pd-\$0-subpatch; #X msg 213 145 400 100 30 30; #X text 213 19 window opens with correct size but with scroll-sidebars. , f 24; #X text 36 21 window opens correctly - no sidebars, f 18; #X text 780 165 As long as the window is created within the visual response of the GUI \, it is opening without the sidebars, f 23; #X obj 213 116 del 250; #X obj 413 92 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 407 232 cnv 5 5 17 empty empty empty 20 12 0 14 -194593 -66577 0; #X msg 413 173 vis 0 \, relocate \$1x\$2+0+0 0x0+\$3+\$4 \, vis 1 \, editmode 0, f 20; #X obj 413 232 s pd-\$0-subpatch; #X msg 413 144 400 100 30 30; #X text 778 58 It seems \, like the "hold" time of [bang] or the visual "flash" of the message box is a crucial factor here., f 25; #X text 413 19 where is the threshold ?, f 12; #X floatatom 459 91 5 0 0 0 - - -; #X obj 413 116 delay; #X msg 13 85 bang; #X obj 57 85 r remoteopen; #X obj 593 219 s remoteopen; #N canvas 176 611 450 300 with 0; #X obj 110 126 propertybang; #X obj 110 146 t b b; #X obj 135 166 print property; #X obj 110 200 outlet; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 1 2 0; #X restore 593 118 pd with propertybang; #X obj 781 16 declare -stdpath iemguts; #X text 601 56 right-click here and select "Properties", f 17; #X obj 617 171 bng 30 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 591 15 also with scrollbars:; #X msg 659 182 bang; #X connect 1 0 2 0; #X connect 4 0 1 0; #X connect 5 0 13 0; #X connect 7 0 8 0; #X connect 9 0 7 0; #X connect 13 0 9 0; #X connect 14 0 22 0; #X connect 16 0 17 0; #X connect 18 0 16 0; #X connect 21 0 22 1; #X connect 22 0 18 0; #X connect 23 0 4 0; #X connect 24 0 4 0; #X connect 26 0 25 0; #X connect 29 0 25 0; #X connect 31 0 25 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
