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

Alexandre's icon

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,

Alexandre's icon

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 ?

Alexandre's icon

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.

Alexandre's icon

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..

Alexandre's icon

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)

Thanks,

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.

CACAFADE's icon
Alexandre's icon

Well, thanks for this external pizza olives !

yas's icon

what about using [hi]?

Alexandre's icon

> what about using [hi]?

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

Philippe OLLIVIER's icon

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.

Philippe OLLIVIER's icon

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 !

Anthony Prechtl's icon

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.

DRKOSS's icon

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.

Cheers

Marc Carlton's icon
Sapo's icon

Any news ?

Roman Thilenius's icon

what? 11Olsen is not here yet?

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?)

TFL's icon

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

11OLSEN's icon

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).