Thanks for the screenshots, Paul.

Ok, two separate issues here:

Are you using the *native* Windows 7 wallpaper slideshow or a 3rd party application?

Anyway, let me explain what is happening there:

Before Microsoft decided to change their own rules, any application (Windows included) that changed the wallpaper should/would notify all other applications that this has happened by broadcasting a special system message to all top level windows.

When everyone follows the rules, things work. When they stop following the rules, things start to break down, sometimes in unexpected ways.

Knowing what the current wallpaper is, is kind of expensive in terms of CPU usage. That is why that system wide broadcasted message was so important: it allowed you to only check for wallpaper changes when they actually happened.

The MS programmers behind the Windows wallpaper slideshow feature decided that maintaning backwards compatibility + following the rules by broadcasting the system was no longer important. So, if your application is waiting for that system wide message, which will never come, it will remain blissfully ignorant that the wallpaper as, in fact, already changed.

So, the next step would be to monitor which file is being used as the wallpaper say, every second. We would already be wasting CPU cycles by having to actually poll for changes to the filename of the current Windows wallpaper... but Microsoft did EVEN WORSE: they actually use *the very same filename* (App Data/Microsoft/Windows/Themes/TranscodedWallpaper.jpg) to store *different* wallpapers.

That is, instead of *pointing* to a different wallpaper file, they COPY the contents of the original file into TranscodedWallpaper.jpg. So, the *contents* of TranscodedWallpaper.jpg change, but the actual *filename* of the wallpaper remains the same.

Are you beginning to see the problem? Not only did they stop broadcasting wallpaper changed messages, they now require you to monitor the actual contents of the TranscodedWallpaper.jpg file for changes, because the filename itself will always remain the same (App Data/Microsoft/Windows/Themes/TranscodedWallpaper.jpg), even though the actual contents of TranscodedWallpaper.jpg have changed.

Having to regularly poll a file for changes in content is even more expensive in terms of CPU + Disk usage than regularly polling to see if a filename has changed (which was by itself already way more more expensive than only doing this when you got a system notification).

Now, if the above is expensive in terms of CPU usage, actually determining the dominant color of the current wallpaper (so you can use that as the tint color), well, now THAT is really, really, expensive. You have to scan the pixels in the wallpaper bitmap, and even though I use every trick in the book to make this as fast as possible while still remaining accurate, it definitely still is the kind of thing you don't want to do UNLESS YOU REALLY HAVE TO!

I could go on and things would get even more complicated to understand. Not everybody uses the Windows wallpaper slideshow feature, so you don't want to waste CPU cycles checking for something that will never happen on that user's system.

So, when the application notices that the current wallpaper filename is 'transcodedwallpaper.jpg' (which normally means the wallpaper slideshow feature is active, BUT NOT ALWAYS(!) ), it puts a 'watch' on the containing folder. This 'watch', a bit like a system notification, will go off when a file changes inside that folder, at which point we get the dominant color of the wallpaper again.

Because all this is very expensive in terms of CPU usage, as I explained above, it will only get done when strictly necessary.

If you use a 3rd party app that changes wallpapers without notifying the system (as Windows does) but that also uses a mechanism other than transcodedwallpaper.jpg, the Winstep application will not know that the wallpaper has changed.

And, as I said, getting the dominant color of a wallpaper bitmap is so expensive that it only gets done when the Winstep application knows or thinks the wallpaper has changed - which is why clicking Apply does not apply the new colorization either, it's still using the tint of whatever was the previous wallpaper.

As for the modules, those desktop meters are being displayed as *icons* (i.e.; no 'advanced skinning'). Desktop modules displayed as icons are NOT colorized (otherwise you would end up with things such as the Weather icon displaying current conditions being colorized, with pretty messy results).

One thing that I did think about doing (but ended up not implementing) was coloring the histogram graph lines (but not the actual background). That would already make sense.

Now that you reminded me the modules are icons, the not changing colors makes sense, thanks.

As for the wallpaper changes, I'm using the native Windows 10 slideshow. Maybe time for Winstep to implement an optional wallpaper slideshow so that you'll KNOW when the wallpaper changes?

Wait. Windows 10?!

Why was I convinced you were running Windows 7?

Under Windows 10 the system actually broadcasts a WM_SETTINGSCHANGE message when it changes the wallpaper, so I don't need to track changes to the Transcodedwallpaper.jpg file. I just rely on the system notification.

I tested this on a Windows 10 VM machine and again on a physical Windows 10 PC I have here. Under both systems the Winstep application knows when the wallpaper has changed because of this notification, and changes theme colorization appropriately.

We need more data from other Windows 10 users. Guys?

Hello?

Any Windows 10 users here to help confirm if the Windows 'wallpaper slideshow feature' + 'colorize with dominant color of desktop background' is working properly or not?

Please? Pretty please?

Win10 built in slide show
It does not work. when the wallpaper changes, the colors of the WExt elements do not change. I have tried with the shifting hues method and without.
The correct colorization does appear the settings preview, but does not translate to my desktop.

Jorge, you'll be happy to know that when my wallpaper changed, so did my Winstep colors.

Yay!

Thanks, Paul!