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
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 oliver@klingt.org:
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_win_size_problem.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 oliver@klingt.org:
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_win_size_problem.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
hans w. koch -
oliver