charred

Curious to know what is happening here. I have messages going to [thispatcher], to show and hide the close button on a window. As shown in the attached patch, using an LED to trigger messages results in having to push the LED four times instead of twice to cycle through the On/Off . Individual buttons trigger the messages correctly, but the buttons remain highlighted after the click while the mouse is still hovering over them. The off part of the mouse click does not trigger an update to [mousestate] but moving the mouse does, which de-highlights/un-highlights/(lowlights?) the clicked button. 

If I separate the "window exec" message out of the list and delay triggering it until after the window messages are passed to [thispatcher], the commands are executed properly but the delay needs to be at least 150 msec. I'm curious to know why the "window flags no close" and "window flags close" are taking so long to be processed (150 msec) or cleared by [thispatcher]. Is there a way around this?

I'm on a 16" 2019 MacBookPro OS 10.15.3, M/M/J 8.1.3

CloseButton.maxpat

Curious to know what is happening here. I have messages going to [thispatcher], to show and hide the close button on a window. As shown in the attached patch, using an LED to trigger messages results in having to push the LED four times instead of twice to cycle through the On/Off . Individual buttons trigger the messages correctly, but  the buttons remain highlighted after the click while the mouse is still hovering over them.  The off part of the mouse click does not trigger an update to [mousestate] but moving the mouse does, which de-highlights/un-highlights/(lowlights?) the clicked button. 

If I separate the "window exec" message out of the list and delay triggering it until after the window messages are passed to [thispatcher], the commands are executed properly but the delay needs to be at least 150 msec. I'm curious to know why the "window flags no close" and "window flags close" are taking so long to be processed (150 msec) or cleared by [thispatcher]. Is there a way around this?


I'm on a 16" 2019 MacBookPro OS 10.15.3, M/M/J 8.1.3


Curious to know what is happening here. I have messages going to [thispatcher], to show and hide the close button on a window. As shown in t

thispatcher-window-exec-delayupdate-issue

everything works normal in max 7, including the very first time you click the led.

Thanks for looking at that, Roman. Hmm, must be the remainder of my patch bogging my system down -- lots of processing going on. Time to tear it apart and figure some things out.

The problem is not related to "thispatcher".

I noticed a bug in certain objects ("toggle", for instance). If you use toggle instead, turn on and then off without moving the mouse a single pixel, it doesn't respond, only when you click again. If you turn on, move the mouse slightly and then click again, it will immediately turn off.

Now, the 150ms delay, is directly related to the "led" object. Open the "led" button inspector and notice the 150 value on the "blinktime" attribute. Coincidence? ;-)

maybe it is somehow releated to the fact that there is this silly windows shaking effect now when you change a thispatcher window style?

in a similar context, namely when trying to move a window´s position using the mouse, i exprience trouble of that sort, too (yet i dont consider it a bug) - it is like ... err ... not sure how to explain it better ... that 

the patcher window is moving, any input from "mouse up" to an object can no longer be set to overdrive, can come late, or get lost.


maybe it is somehow releated to the fact that there is this silly windows shaking effect now when you change a thispatcher window style?

in a similar context, namely when trying to move a window´s position using the mouse, i exprience trouble of that sort, too (yet i dont consider it a bug) - it is like ... err ... not sure how to explain it better ... that while the patcher window is moving, any input from "mouse up" to an object can no longer be set to overdrive, can come late, or get lost.


Thanks very much for looking at this. And thanks again, Roman, for your input -- I launched the patch in Max 7 but had the same issues. I've updated an updated patch (attached) for the following points. And I don't mean to drag anyone into an extended discussion -- I'm just trying to figure out what is happening in my system, so if others have suggestions I'm happy to hear them. The close, no close messages work correctly (with one issue) and I don't need to use buttons to trigger them, but now I'm wondering what might be interfering with my system messages.

Pedro, I'm assuming that your bug comment refers to using a toggle attached directly to a message box with two messages "window flags no close, window exec" that is then going into [thispatcher], as in the upper two patches (1 and 2). Using the purple toggles I can't replicate that. In patch 4 I've attach a red toggle to the message box "window flags no close" that goes directly into [thispatcher]. It toggles on and off correctly without needing any movement. However, if I trigger that message on (red toggle or red button) and then trigger "window exec", with a yellow toggle, the yellow toggle either requires mouse movement, or else three clicks to reset properly.

As for the 150 ms delay, I changed the blink time on the LEDs and buttons to values between 50 and 300 msec but the problem persists. (Again, this is on my system: Roman indicated that on Max 7 he didn't have a problem with the patch.)

The "one issue" I mentioned above: on patches 1 and 2 if you click on a message box with two messages, the box "indents" but doesn't refresh until you move the mouse, so the update issue isn't restricted to the LEDs and buttons. But if I use a window size message with window exec in the same message ( patch 5) the message box updates properly, as do the buttons associated with each message, as well as the LED.

But I've also found in patch 4, if I click and hold on one of the black buttons and then release, it will remain highlighted until I move the mouse away. So for click quicks involving the window flags [mousestate] registers the change of state, but doesn't for long clicks. At the same time, the close/noclose is executed properly -- as before, the buttons are not being updated until a change is registered in mouse position.

Sorry for the bandwidth on this -- just trying to get a handle on things. It would seem that for my system the close and no close messages are what are causing the mouse down/up update issue in the patch.

CloseButton2.maxpat

Pedro, I'm assuming that your bug comment refers to using a toggle  attached directly to a message box with two messages "window flags no close, window exec" that is then going into [thispatcher], as in the upper two patches (1 and 2).  Using the purple toggles I can't replicate that. In patch 4  I've attach a red toggle to the message box  "window flags no close"  that goes directly into [thispatcher]. It  toggles on and off correctly without needing any movement. However, if I trigger that message on (red toggle or red button) and then trigger  "window exec", with a yellow toggle, the yellow toggle either requires mouse movement, or else three clicks to reset properly.

As for the 150 ms delay, I changed the blink time on the LEDs and buttons to values between 50 and 300 msec but the problem persists. (Again, this is on my system: Roman indicated that on Max 7 he didn't have a problem with the patch.) 

The "one issue" I mentioned above: on  patches 1 and 2  if you click on a message box with two messages, the box "indents" but doesn't refresh until you move the mouse, so the update issue isn't restricted to the LEDs and buttons. But if I use a window size message with window exec in the same message ( patch 5) the message box updates properly, as do the buttons  associated with each message, as well as the LED.

But I've also found in patch 4, if I click and hold on one of the black buttons and then release, it will remain highlighted until I move the mouse away. So for click quicks involving the window flags [mousestate] registers the change of state, but doesn't for long clicks.  At the same time, the close/noclose is executed properly -- as before, the buttons are not being updated until a change is registered in mouse position.

Sorry for the bandwidth on this -- just trying to get a handle on things.  It would seem that for my system the close and no close messages are what are causing the mouse down/up update issue in the patch. 

"window flags noclose, window exec, window flags close, window exec"

in one messagebox at once? are messages queued properly and the closebox remains accessible?


i wonder what your aim is.

and: what happens when you send 

"window flags noclose, window exec, window flags close, window exec"

in one messagebox at once? are messages queued properly and the closebox remains accessible?


All four "patches" result in the same intended result, regardless of mouse held state. I suspect this could be because on Windows, the window is being completely killed then reopened to refresh the "close button" state on the menubar.

Only the top right (2nd) patch works properly. The 1st patch requires multiple clicks to change the state of the LED before doing anything to the menubar. The 3rd patch works only if the mouse state is not held down.

 upon click (regardless if mouse is held or not), the new generated patch window does not register the previous held mouse state (if mouse is still held), therefore all four patches 

 The issue seems to be coming from the Mac side as the window isn't being reopened... something should be done to ignore the mousestate when button-down is held && when updating the "noclose" or "close" to "thispatcher".

Perhaps Max devs can pitch in their 2 cents too??

I have tested this patch on both Windows and Mac Max8. 

On Windows:
All four "patches" result in the same intended result, regardless of mouse held state. I suspect this could be because on Windows, the window is being completely killed then reopened to refresh the "close button" state on the menubar. 

On Mac:
Only the top right (2nd) patch works properly.  The 1st patch requires multiple clicks to change the state of the LED before doing anything to the menubar.  The 3rd patch works only if the mouse state is not held down.

As on Windows, the window is completely killed upon click (regardless if mouse is held or not), the new generated patch window does not register the previous held mouse state (if mouse is still held), therefore all four patches work as intended.  The issue seems to be coming from the Mac side as the window isn't being reopened... something should be done to ignore the mousestate when button-down is held && when updating the "noclose" or "close" to "thispatcher".  

Yes, I was referring to toggle not updating.

I was also inferring that there was no problem with thispatcher specifically, nor sending the "close/noclose" message and "window exec" immediately or separately. There's no delay problem there. The thing is, only when the window exec command is received does thispatcher effectively do its thing and somehow while the window is being redefined, the other objects can't update and misbehave. I'm also inclined to Dan Tsui's conclusions.

Here's a simple example that denotes that the bug is "more severe" than merely redrawing the interface:

Yes, I was referring to toggle not updating.
I was also inferring that there was no problem with thispatcher specifically, nor sending the "close/noclose" message and "window exec" immediately or separately. There's no delay problem there. The thing is, only when the window exec command is received does thispatcher effectively do its thing and somehow while the window is being redefined, the other objects can't update and misbehave. I'm also inclined to Dan Tsui's conclusions.
Here's a simple example that denotes that the bug is "more severe" than merely redrawing the interface:

@Pedro Wow... this is quite a severe bug. Interesting findings that you got. Thanks for your time in this!

On Mac, this behavior is exactly as you described.

On Windows, the mouse state toggle refreshes itself when mouse-down is released only if mouse pos did not change. Other than that, Windows seems to also behave the same as the Mac.

Max devs should really look into this then...

@Pedro Wow... this is quite a severe bug. Interesting findings that you got.  Thanks for your time in this! 

On Mac, this behavior is exactly as you described.
On Windows, the mouse state toggle refreshes itself when mouse-down is released only if mouse pos did not change. Other than that, Windows seems to also behave the same as the Mac.

Ah, interesting to see this, Pedro -- many thanks. When I swap in the window size commands in your patch the toggle operates normally. I assume this is because the resize window execution does not redefine the window, but just changes the dimensions of the current window?

Ah, interesting to see this, Pedro -- many thanks. When I swap in the window size commands in your patch the toggle operates normally. I assume this is because the resize window execution does not redefine the window, but just changes  the dimensions of the current window?

"window size" kind of repositions the window, too. (unlike "noclose", where i wonder why windows attempts to redraw the patcher windows at all.) and i guess it is exactly these things which differ a lot between mac and win.


"window size" kind of repositions the window, too. (unlike "noclose", where i wonder why windows attempts to redraw the patcher windows at all.) and i guess it is exactly these things which differ a  lot between mac and win.

thispatcher, window exec, delay/update issue