How to detect (break) when some window.top is changed?

it would be so much awesome to be able to break on a variable or property change …
if anyone has a workaround for this one ?
for one of my property it’s quite easy, make a computed property and break on the set method
but for a framework property like window.top ?
thanks.

You might be able to subclass Window and make a computed property that references Super.Top or whatever property you’re concerned about.

Don’t do that. Shadowing properties is only going to cause you trouble in the long run.

2 Likes

it’s only temporary for debugging purposes … so I’ll try it !

I get the position of my app’s windows from a préférence file at startup, so I set the window top by program.
and since my upgrade to actual xojo, as my app is still api1, I have some weird errors like the top of the windows that slowly go down… so I would like to trace when top gets a new value…
I will use Tim’s trick to debug this, then to follow Greg’s advice, remove that problematic code.

sorry Tim but after trying this, it seems that super only applies to methods, and not to properties.
so this nice trick is impossible to apply …
any other bright idea for this ?
thanks.

Cast?

Cache Window.Top and use the Window.Move event to check if it changed…

Norm had to point that event out to me as in over 20 years I never used that event and did not realize it existed!

-Karen

1 Like

Derk is right, it would be more like Window(Me).Top. But you’ve had better suggestions. I didn’t know about the Moved event either.

1 Like

maybe use a timer and use a Break
if FindError=true and self.Top <> LastTop then Break
add System.DebugLog CurrentMethodName in few related methods.

what do you mean with this ?

Store that value in WIndos Property, in the Move event ?

ok so i used norman’s trick with window(self).top
it works, it stops when the window top is changed.
but on my particular case, it did not stop when the window gets a +36px offset and slowly moves down the screen…
I’m still convinced that it happens because I’m on actual xojo and big project and API1
I couldn’t make a test project with the bug, and if I even could make one
as it is API1 IT WOULDN’T BE FIXED ANYWAY !!!

I found a workaround for this, adding 36px at the right time, it’s not a solution, but it works, waiting for the time I update the project to API2, which will take some time.

thanks to all the participants. included Norman …

have you set the border in a resize event, which maybe raise a new resize event?

So your window walks down ? Could this be the toolbar offset? Did you try to use Window.bounds somewhere?

the problem is with the top of the window.
a resize event would change only the width and height ?

Yes I use the window.bound to take into account the toolbar height.
but I traced the code in that section and the changing top does not come from there.
I also check the menubar height, that became a source of problems when I had hi-dpi involved.

the window is moving down by 36px each time I open it. with a toolbar or not it’s the same.
the toolbar is 55px height, so not a multiple of 36 ?

1 Like

I’ve always learned to not expect anything to be as you expect it to be. So there is nowhere you call “.Top =” so that it becomes different? Maybe an animator or something?

norman’s trick window(self).top = value in a setter of a subclass works fine
I am able to stop anywhere the top is set.
but none of them adds 36 to the window’s top …

no worry, I have a workaround, and if by any chance we could pinpoint this bug, as I’m sure it is somewhat related to api1 it will never be fixed …

1 Like