Alexandre

I just wanted to find a simple way to know exactly when my patcher window size is changed, in order to resize the lcd that is in it.

I need to test the window size (with the msg "window getsize" sended to [thispatcher]) when the mouse button is released, but [mousestate] doesn't report the button events when i click on the window zoom corner, or the titlebar, or elsewhere outside a patcher. It looks like [mousestate] only report the button pressed when I click inside one of the patchers opened.

Any other way to get the new window coordinates when changed ?

Hi,
I just wanted to find a simple way to know exactly when my patcher window size is changed, in order to resize the lcd that is in it.
I need to test the window size (with the msg "window getsize" sended to [thispatcher]) when the mouse button is released, but [mousestate] doesn't report the button events when i click on the window zoom corner, or the titlebar, or elsewhere outside a patcher. It looks like [mousestate] only report the button pressed when I click inside one of the patchers opened.

How can i do ?
Any other way to get the new window coordinates when changed ?
thanks,


thispatcher-and-mousestate-when-is-my-patcher-window-size-changed

Well, thanks, this way of doing is also working here. But your way of doing is fine until you a bit more of your cpu... i don't want to resize the lcd every 25 ms for nothing, with my sound going on...

So what i want is the state of the mouse BUTTON, the 1st outlet of [mousestate], which do not work while clicking somewhere else than inside the max patcher. This 1st outlet of [mousestate] is doing nothing when i grow the window.

Is'nt there a way to get the mouse buttons info when the mouse click outside max ?

So what i want is the state of the mouse BUTTON, the 1st outlet of [mousestate], which do not work while clicking somewhere else than inside the max patcher. This 1st outlet of [mousestate] is doing nothing when i grow the window.
Is'nt there a way to get the mouse buttons info when the mouse click outside max ?


about the cpu, i don't care about [mousestate] every 25ms, but about the "window getsize" msg sended to [thispatcher] every 25ms, (msg to test if the window size have changed), plus i just don't like this way of programming, to have useless messages sended everytime, everywhere, after it's a mess, and then your sound is not working right, and you can't figure out why...

I feel something might be missing in [thispatcher], it would have been nice that it output some msg when the window size is modified.

Anyway, i'm sending "window getsize" every 1000ms (and only while my sound is off), not elegant, but working.

Thanks for the Oli Larkin's external notice, I remember i tried this and it was working before on my MBP, but now it's not. strange.

After an hour of sending "window getsize" every second to [thispatcher], the "save" button in mac os window started to "twinkle", and some part of the mac os saving window too!... so i stopped this "window getsize", and guess what, suddenly my system is not twinkling anymore...

This "window getsize" every second is clearly not a solution.

Guess, you know what ?
After an hour of sending "window getsize" every second to [thispatcher], the "save" button in mac os window started to "twinkle", and some part of the mac os saving window too!... so i stopped this "window getsize", and guess what, suddenly my system is not twinkling anymore...

This "window getsize" every second is clearly not a solution.
I don't find any solution..


Wow, that's a f*** weird way of doing, and it seem to work!.. But the problem again is that when lot's of audio and drawing is going to be on, plus when i'll share my patch with a friend on an other computer, then your 80 ms limit on your last patch will not react the same way, and then, either my lcd wont resize, or this "window getsize" is going to be sent all the time. And I'm not gonna spend my time adjusting this delay, just for a resize option that i will use episodically.

Anyway, I even didn't think about using [active], and as my LCDs are mostly for display only, what i will do is to bring another patcher window to front after 5 seconds... ("window getsize" sent every second during theses 5 seconds)

(anyone at C74 working in august and reading this?),

that it would be really welcome that [thispatcher] output some msg when the patcher window size have been modified.

P.S:
I want to say again,
as feature request,
(anyone at C74 working in august and reading this?),
that it would be really welcome that [thispatcher] output some msg when the patcher window size have been modified.


Well, thanks for this external pizza olives !

i tried [hi] but it does not output anything from my Spyker mouse.

Thanks Pizza Olives for the object. Works well!

Do you think that there is a way to know when the window has been moved?

I want to be able to store the new position only in this case.

For cycling guis, here is another wish for christmas...

Hi,
Thanks Pizza Olives for the object. Works well!
Do you think that there is a way to know when the window has been moved?
I want to be able to store the new position only in this case.
A dedicated object would be great. 

For cycling guis, here is another wish for christmas...
Many thanks,
Philippe.


Yes, in fact... I saw the discussion with Emmanuel on the DEV forum!

Getting the window size with [closebang] or even [freebang], is sometime to late in order to write the window position in a file. [Active] can be a solution but not in all the cases... And [metro] is really not the good choice to spy a window position.

A dynamic [thispatcher] would really be a good solution for us...

Anyway, thanks a lot for your investigations!

Hi Pizza olives,
Yes, in fact... I saw the discussion with Emmanuel on the DEV forum!
Getting the window size with [closebang] or even [freebang], is sometime to late in order to write the window position in a file. [Active] can be a solution but not in all the cases... And [metro] is really not the good choice to spy a window position.
A dynamic [thispatcher] would really be a good solution for us...
Anyway, thanks a lot for your investigations!
Keep the good work,
adessiatz, a reveire !


I'm curious if anyone has produced a similar object as pizza olives, but for Windows. If so, would you mind sharing? Sending the window getsize message every second is very clumsy and has a noticeable (albeit quite small) CPU impact.

been a while since this post - any developments on being able to get a notification when the patcher is resized? This would be pretty handy.

been a while since this post - any developments on being able to get a notification when the patcher is resized?  This would be pretty handy.

if Cycling74 hasn't replied to this, i wouldn't assume this would ever be added, as the OP came to understand eventually:

it would be a feature that taxed CPU but was useless most of the time(and if it had a toggle to activate/deactivate it in preferences, people would still complain about CPU issues)

if you want notification when window is resized, then you can provide a UI interface in your app that controls window resizing via thispatcher(and that way, while it's being resized, your app can also store the exact dimensions because the user enters them directly).

Screenshot 2023-11-07 at 6.55.06 AM.png

to have useless messages sended everytime, everywhere

 it would be a feature that taxed CPU but was useless most of the time(and if it had a toggle to activate/deactivate it in preferences, people would still complain about CPU issues)
if you want notification when window is resized, then you can provide a UI interface in your app that controls window resizing via thispatcher(and that way, while it's being resized, your app can also store the exact dimensions because the user enters them directly).

looking at the original question... what about updating the lcd size only on the next click into the patcher window and/or the lcd object.

if idle is ON in the lcd object, that could also be used, then the sizes would kind of update on "hover".

or, as a workaround (sorry), triggering the thispatcher query continously using a [qmetro 333]...

(why has mr. vanille bechamel deleted all his messages?)

or, as a workaround (sorry), triggering the thispatcher query continously using a [qmetro 333]...
 
 
(why has mr. vanille bechamel deleted all his messages?)

Just to make the bridge with a related topic: https://cycling74.com/forums/monitoring-whether-a-window-size-changes-in-js

This is only a Mac problem. On Win, mousestate is monitoring clicks even outside the Max window. Polling in js works well and I doubt that you see any change in CPU usage. The cleanest way is an external (C-API) where you can subscribe to instant patcher move / resize notifications (no polling needed).

thispatcher and mousestate : when is my patcher window size changed ?