AlwayOnTop doesn't work properly after the patch has been restarted

vvvv gamma bug
,
1

To reproduce:

  1. Create a render (I created skia, but I don’t think it makes any difference).
  2. Click on the window title.
  3. Click ‘AlwaysOnTop’. Make sure the window is on top of the others.
  4. Click ‘restart’ or ‘recompile’.
  5. The window has lost its ability to be on top of others.
  6. However, the flag in the window title still has the status ‘enabled’.

I would also like to note that, for some reason, this flag does not turn on and off on the first try. Sometimes you just click on the menu item and there is no response.

1 Like
2

Should be addressed in upcoming by turning those pins into channels.

Regarding the second issue, yes, also seen that already while developing. Spent some time debugging it and culprit seems to be how we drive the Windows message loop. It somehow doesn’t like that we pump the message loop after each frame - which as it stands is needed for a lot of other things to work correctly. So no easy fix for now, I guess we’ll have to live with it for the time being.

1 Like
3

In version 7.1-0128, the behaviour remains the same.

After restarting or recompiling, the window with the AlwayOnTop flag no longer stays on top of everything. However, the flag remains enabled.

4

Interesting. Setting TopMost/AlwaysOnTop needs to be delayed for some reason. Fixed in upcoming.

2 Likes
5

Yep, noticed that to, i just put onopen → monoflop 1s on all that. I also try to remove windows touch helpers from window (white rect if you press and hold). Last gpt assumption was that it’s only possible before the window open, not sure but maybe would be nice to have some optional onCreate delegate to hook some stuff before window.Open()