Kolcha
commented
4 months ago TL;DR: it is very unlikely to be fixed, I'm not intended to invent just another hack for it.
"stay on top" option is unreliable anymore, sorry. this is known issue since ~2015, and parts of it is somewhere in Windows itself, another part is in surrounding apps (mostly JS-based, which are Chromium browser + website inside) with their fullscreen invisible windows. just try Winamp (or any other 10+ years old app) what worked perfectly many years ago, you will see the same issue!
fullscreen windows are another story. regardless of the fact that Win API documentation says that there are no such thing as "fullscreen windows", this is not completely true. in most cases fullscreen windows have some undocumented flags set, and they definitely treated in special way. DirectX windows (games and video players) even more special, usually to draw something (like FPS counters for example) above such windows, it must be drawn in special way (unknown to me). if some application can appear above such things, this is most likely coincidence rather than feature, and this is just another indirect confirmation that the many things related to rendering have changed in Windows even since Win 7.
situation with my clock is even worse as it uses Qt, and Qt also has its own quirks related to this. I can't find this information now (as documentation degraded), but previously Win API documentation stated that window must be visible when you are changing any style flags, but Qt requires completely opposite - windows must be invisible. that leads to impossibility (at least using standard API) to change window flags on runtime, fortunately it works somehow if you set these flags only on initialization (that's why app restart is required to enable/disable this simple option). and nobody cares as this is "not required" by anyone, because primary focus is JS-based API, which even doesn't assume such things, because it is assumed that there is only one fullscreen window and nothing more.
I'm not a Win developer, neither even active Win user (I just using it for very specific tasks maybe once in month or even rarely), and don't want to deal with all its quirks (especially when there is obvious software quality degradation observable in general past 10 years, especially for commercial products). with my previous Digital Clock 4 I implemented and re-implemented many different hacks (found across the internet) to get this feature work +/- reliably, but most of them just stop working after some time (with Windows updates and so on). I'm just tired of it, and this is not a way how it should be (and was even at least at the beginning of Win 7 era and even earlier).
the trick you proposed (with updating topmost property periodically) also was implemented in older clock at some point of time. it may "help", but this is very likely will lead to another bug and visually unpleasant situation - clock will appear on top for a while and then disappear, just because Windows can maintain only one topmost window (again, no information can be found in current documentation, but it was there before, and practice confirms this), and this is "only one" is very likely one of those invisible fullscreen windows created by something Chromium-based, and it is very likely it also has similar hack with periodic checking to "keep" this topmost flag. so, no reliable way to do something with it.
I can try to port hacks from older clock, but this is completely no guarantee that they mitigate issue somehow, the effect may vary from nothing (hacks have no effect anymore) to even worse (as I described above), and effect will vary from system to system and may change during the time with no changes from my side.
kissandfly
If another application is also set as topmost, it cannot be overlapped. I believe to fix this, you need to refresh the topmost window status every few seconds. For example, when another application goes fullscreen, it sets its own topmost position, causing the digital clock to be pushed below.