Added a small quality of life improvement upon request from a user: support for US and ISO system date formats in the Alarm Manager, including locale-independent date validation.

This is turning into a maintenance release.

Stopped system tray monitoring from continuing to run after the last active tray instance was removed, which should have happened before but wasn't.

Also added Wi-Fi signal strength display to the network tray icon when permitted by the Windows location privacy settings (i.e. if "Location Services", "Let apps access your location" and "Let desktop apps access your location" settings are all enabled).

Microsoft should have exposed wifi signal strength without having to turn on the localization services, but alas, they did not and these are all disabled by default. So, if you want to see your network tray icon reflect the current wifi signal strength in the next release, you must turn those three settings on Windows Settings > Privacy & security > Location

Fixed incorrect Italian spoken-time phrasing, hour/minute ordering, and time-of-day announcements.

Only took me 3 years.

Also modernized the Winstep Update Manager a little bit:

Nice

One more thing I had on my to-do list for a very long time: most people probably never noticed, but the Net Meter module has a component called "Active Connections", which you can invoke, among other places, from the Net Meter module's right-click context menu.

This displays a panel that allows you to monitor all currently active TCP/IP and UDP connections. What was missing was the amount of bandwidth being used by each individual TCP connection, which I have now added.

The panel can be very useful for figuring out, for instance, whether something is communicating behind your back, who it is communicating with, and now, with this addition, how much data is being transferred.

The panel is showing. Active connections are in progress! Thank you very much!

I think I may have accidentally fixed the intermittent high CPU usage in WorkShelf under Windows 11, even when it was idle. Finally!

This has actually been a months-long search.

On my Windows 11 system with a 12900K processor, WorkShelf would normally sit at around 0.3% CPU or less, but from time to time it would suddenly climb to roughly 1.7% and remain there for a long time.

That may not sound like much, but it represents approximately 25% of one logical processor running at 5 GHz, which is far too much for an application doing absolutely nothing. Restarting WorkShelf did not fix the issue either.

Because the problem only seemed to happen under Windows 11, and never under Windows 10 or earlier, my initial suspicion was that it might have something to do with the way Windows 11 schedules work between the Performance and Efficiency cores of the 12900K.

Perhaps WorkShelf was occasionally being moved to an E-core and therefore appearing to use more CPU while performing exactly the same amount of work. The fact that the CPU usage could suddenly appear or disappear without any obvious change also seemed to support that possibility (I eventually ruled that theory out by forcing WorkShelf to run only on the 12900K’s P-cores through processor affinity, excluding the E-cores).

That sent the investigation in several wrong directions and made the true origin of the activity extremely difficult to identify.

Over the following months, I repeatedly combed through several areas of the WorkShelf code that seemed like possible culprits. Timers, system monitoring, animations, window handling, modules and other background operations were examined over and over again.

Along the way, I made many of those areas as lean and fast as possible, which was useful in itself, but none of those changes actually eliminated the mysterious CPU usage.

What made the problem particularly difficult to track down was that closing every module, dock and shelf did not make the CPU usage go away. WorkShelf releases resources when nothing is using them, so there was no obvious feature left running that could explain the load.

The culprit now appears to have been related to the system tray code. This also explains why the high CPU usage only happened under Windows 11.

Under Windows 10, Winstep applications can still access and display the real system tray icons. Windows 11 no longer allows this, so WorkShelf must instead use "cloned" tray icons for battery, network and volume, which mimic the behavior of the genuine Windows icons.

To display the same information as the real icons, WorkShelf has to retrieve that information itself. This means checking the available network adapters to update the network icon, and enumerating the audio devices to determine the current playback device, volume level and mute state.

Retrieving the battery state, on the other hand, is quick and easy, requiring only a single Windows API call.

Until now, this information was obtained by polling Windows once per second for as long as the tray was visible.

Polling is never as elegant or efficient as having Windows notify WorkShelf whenever something changes, but given the complexity and risks involved in working with COM objects and callbacks, it is much simpler and safer to implement. Notification callbacks are also not always available, or may not even exist for the particular information being monitored.

I had already improved the network tray icon code by polling it only once every 10 seconds, unless a change in IP address was detected (checking the IP address is quick and inexpensive) but I had otherwise left the rest of the tray polling code alone.

While monitoring WorkShelf with Process Explorer for an unrelated reason, I noticed that audio endpoint enumeration kept appearing once every second.

This finally pushed me to replace the audio polling code with Core Audio device-change notifications. If I could cache the relevant audio objects, there would be no need to enumerate them again until Windows reported an actual change, leaving Process Explorer with almost nothing to show during normal idle operation - always a good thing.

However, before doing that, and while looking through the tray code again, I noticed a potential bug in the tray timer usage counter, which determines whether the timer should continue running or be stopped.

The bug meant that the tray timer continued firing once per second after the last tray object had been closed, repeatedly triggering audio device enumeration even though nothing was using the tray anymore.

This explains why I could never find the culprit by closing every object one by one - the real culprit continued running in the background!

The timer itself was not particularly expensive, but every time it fired it caused WorkShelf to enumerate the Windows audio devices in order to update the cloned volume tray icon even when this was not being shown anywhere.

And THIS appears to have been what caused the high CPU usage.

NextSTART too was probably affected by the same repeated audio device enumeration, it simply uses so little CPU when idle in comparison to WorkShelf (which is constantly monitoring modules, updating information and performing other background housekeeping) that the additional load never became obvious.

It also explains why the problem was so difficult to catch in the debugger. The CPU usage was not being caused by one long-running section of WorkShelf code. Instead, it consisted of many short bursts of work inside Windows and the audio drivers.

By the time I interrupted execution, the actual audio enumeration had usually already finished, so the debugger would stop somewhere harmless-looking rather than inside the code responsible for the load.

It was only some time after fixing the timer bug and implementing the Core Audio callback that I noticed WorkShelf was no longer occasionally peaking at 1.7% CPU usage while idle.

I may still be speaking too soon, but in several days since these changes were made I have not seen it get anywhere near 1% (it stays well below 0.3%).

After months of searching through all the places that seemed most likely, it would be rather fitting if the actual solution came from accidentally stumbling across the problem while working on something else.

On my laptop, the minimum CPU load from WorkShelf reaches 2.3%. The operating system is Windows 11, with a 64-bit x64 processor.

I don't believe it!!!!!!!! Seems I spoke too soon

PC just came back from sleep with WorkShelf using more than 1% CPU again <bangs head on wall>

This is very strange. The tray audio core issue fit the symptoms like a glove and explained all the weirdness, Also, WorkShelf going above 1% and staying there seems to happen WAY less often AND mostly it does not go as high as before.

@Jorge

I feel silly asking this but I looked for a help section and looked through your FAQ's before posting. As such, if it does not exist then I suppose if feasible it might be a new feature, or not possible at all. If I knew, I would not ask as follows:

Is there a way to save the Nexus position per theme in Winstep? I have looked but it all seems to be Global? It possibly does and I am simply looking to do it in the wrong place. If it does not exist, and if possible, then a request it becomes if it will not be a nightmare.

Thanks

No, there isn't, and I don't even understand why you would want that. Dock position is a user preference, not a theme attribute.

Only objects that get their position saved per-theme are the *desktop* modules, and those only for a very good reason: because they are "floating" objects and their shape and size varies wildly between themes. Without saving their position per theme, they would have to be re-arranged every time you switched to a different theme (what is an optimal arrangement for a particular theme could be completely wrong for another theme, with modules now overlapping others and so on...)

Docks, shelves, etc, on the other hand, are normally docked to screen edges, and because their size depends mostly on icon size (which does not change when you switch to a different theme) their sizes and positions remain relatively stable.

And if you are thinking about a dock visually matching a specific "spot" in a wallpaper, that would never work either because docks all have different icons sizes and number of shortcuts in them, all selected by the user according to his preferences, and not by a theme or theme author (not to mention different screen resolutions, the fact that you can have multiple docks, etc).

And it's not happening now nor have I really seen it happening again. If it does still happen from time to time, at least now it seems to be happening way less often that before.

So I think fixing the core-audio enumeration did have a big impact on this. Either way, very, very, strange.

New Betas of v26.7 (Beta 3) are out:

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

Nexus Ultimate beta:
https://www.winstep.net/ultimate-beta.zip

Nexus free beta:
https://www.winstep.net/nexus-beta.zip

This is a beta and MUST be installed ON TOP of a full v26.6 OR LATER installation. Do NOT uninstall anything first, just exit all running Winstep applications and run the beta setup file.

There is no need to backup your settings first, but it does not hurt if you do either.

###

v26.7 so far has been mainly a maintenance release (only addition is the ability to also optionally open folder menus on mouseover, like you already could with sub-docks and grid stacks). Fixes some bugs related to PWAs and Chromium browsers on per-user installations, multi monitor profiles sometimes being incorrectly applied on systems where the monitors were not horizontally aligned, incorrect rendering of the tab text in the Alarm Manager on non-Western systems, and a couple more other misc fixes and stability improvements.

Beta 3 adds the following:

* Support for showing WI-fi signal strength in the network tray icon. PLEASE NOTE: signal strength is ONLY shown if in Windows Settings -> Privacy & Security -> Location -> a) Location Services are enabled, b) Lat apps access your location is enabled and c) Let desktop apps access your location is enabled.

* Added US and ISO date support to the Alarm Manager.

* Active Connections dialog of the Net Meter module now shows per-connection bandwidth usage information.

* Fixed incorrect Italian spoken-time phrasing by the clock module.

* Next Desktop Background internal command (for Windows wallpaper slideshows) now correctly works on Windows 11 systems.

* Improved performance by not continuously polling core audio for device enumeration when the tray is visible in a dock or taskbar etc under Windows 11 AND also by not running the tray timer in the background even if no tray instance was present., More importantly, this should also have fixed random continuous high CPU usage on Windows 11 systems - but I need feedback on this ASAP, please.

* Other misc fixes, improvements and additions - please see application changelog.

I was actually thinking about convenience to be 100% honest. some themes (anyone's) it may work better for them at the top, bottom or sides for example and like the Modules Winstep simply remembers where the user last left it in the theme (not globally). Nothing as complicated as you are suggesting. But thanks, I do not feel quite so silly now, it just doesn't.