rseiler

@Manoes Wow, so you figured out that reverting to a build from 7 April 2022 (!) stops that window position problem from being one? Not sure how you did that, but I guess that's one way of showing SaB's involvement. I can't remember when the problem started, exactly, but a year ago is reasonable, though if you said two years ago, I might think that reasonable too. It's been too long either way.

@Manoes It's not just Explorer. It's most programs that I use, though much more position than size. Is that related to SaB though? If so, I didn't realize that, but I also haven't tested without it. Using this makes it less of a hassle: https://github.com/caoyue/WindowResizer I wish we had something similar for the tray icons all being hidden with each build upgrade. I've been experimenting with backing up and restoring these two areas, but no joy so far. I have no idea if it's even valid to do this between builds: HKCU\Control Panel\NotifyIconSettings HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify On the good news front, SaB 3.6.4 has an unannounced feature: it doesn't throw a build warning (i.e. disabling itself and making you re-enable) for 23xxx anymore.

Is the same mechanism used for the build compatibility check, which results in SaB being disabled, the boot halted, and then the user being required to answer a question about whether they really want to run SaB? If so, then "can't" would answer that question, too. If not, the question of whether there's a way to prevent the above remains.

Is there a way to suppress the Windows build check? Because if there is, perhaps via the Registry, it would be nice if that was revealed.

I'm not sure what 9/10 means, but yes, I'm talking about the SaB dialog that comes up very early after a new build install warning you about running it and essentially requiring you to opt-in if you want to run it. If that was meant to happen, it should have happened when going from 23403 to 23419, too. It definitely did not then, and that was just a week ago.

Though come to think of it, it didn't happen for earlier 23xxx, as I'd never seen this before, which makes me wonder which behavior is intended. Also, the timing of it, which was pretty early in the boot, may have contributed to the fact that the keyboard didn't work until after another reboot. Might have been a fluke, but I'd never seen that before either.

Is it expected that SaB 3.6.3 should display a compatibility opt-in warning message after a build upgrade to 23xxx (seen with 23424)? If so, is there a way to make it just opt-in by default and not ask? It's probably warranted for 25xxx but arguably not 23xxx.

Yeah, it looks like taming PastIconsStream and IconStreams, at the very least. Probably iffy.

Yes, I had the same idea. Finding where it is shouldn't be too hard. I'm beginning to wonder now if I was actually using SaB back when I was doing build updates every week (before recently, I mean), and perhaps I wasn't (time flies), which wouldn't make this a recent change at all.

Does SAB have any involvement with remembering whether a system tray (notification area) icon is shown or hidden? I ask because I've noticed when going to 23403 and now from 23403 to 23419, that almost all of them are hidden. Yes, dragging back out the ones you want works, but this will reset again with the next build upgrade. While I do know that this never used to happen in previous years, I haven't been doing build upgrades in recent months to be able to narrow when it started--or even if SaB has anything to do with it. Using 3.6.3

Given the new channel situation, has anyone tried the first 23xxx build (23403) yet, which is the first build on the new Dev channel? I know Dev wasn't recommended for use with SaB in the past, but Canary is really what Dev used to be (even more so), and the new Dev is like a slightly more aggressive Beta channel and is thought to be the 23H2 track. Before, Dev wasn't necessarily on any track, it was more for feature experimentation, like Canary is now. This all seems to suggest that new Dev might generally be OK with SaB, certainly more than old Dev. What do you think? https://blogs.windows.com/windows-insider/2023/03/06/whats-coming-for-the-windows-insider-program-in-2023

In case it's relevant, I noticed this crash, seemingly out of the blue and isolated in the sense that I don't recall it happening before:

Is the dragging up or down of pinned items in Explorer (Quick Access section) supposed to work with SaB, at least on 22H2? It looks like you can drag them, but nothing happens. Seems to work fine in Sandbox, which of course is vanilla 22H2.

You mean this setting? It doesn't seem to exist in the UI any longer, and it's not one that I've changed in recent memory in any case. https://www.tenforums.com/tutorials/25233-use-large-small-taskbar-buttons-windows-10-a.html But I checked TaskbarSmallIcons: it's on 0. Update: After playing around trying to figure this out from the perspective of another install (also with a vertical toolbar, which I think is key to seeing this problem), I found that if I unlocked the taskbar and made it slightly wider than it had been that the date then appeared. I'm not exactly sure if something in this area changed with 22621.608, but instead of leaving it wider I put it back to its normal width and went into calendar settings in Control Panel to set "Short date" to "M/d/yy" from "M/d/yyyy." That takes up much less room so it fits fine now.

Wondering if this is just me, and if not, if there's a way to correct it. The time but not the date is showing directly on the taskbar (unless you hover over that area) when it used to show both. SaB: current W11: 22621.608 (it's possible that it started with this version, since this issue is fairly recent, but I'm not sure).

You have great faith. When the Windows team over the course of nearly a year ignores the #1 request, and doesn't even talk about, it's not a great sign. And there are more where that came from.

Hi. I have the latest version on 22000.613, but the problem I've noticed started a couple months ago. I didn't think anything of it at first, because it doesn't happen most of the time, but I thought I'd ask here: Every once in a while, when I go to run something on Start (and I'm just talking about top-level things immediately visible), when I click the item it takes perhaps 5 seconds to launch whatever it is. That's not normal, since it's usually instant. I thought it might be Defender playing games, so I was going to make an exception for Startallback in Defender, but I don't actually know that that's even possible, since there doesn't really seem to be a Startallback process to make an exception for. Or is there?

What is the rest? I just compared the two, and aside from the useful addition of the time in the Win10 one (the only place you can see seconds), they're all but identical.

Just curious, with the great Control Panel migration continuing: https://www.ghacks.net/2021/12/18/microsoft-migrating-windows-control-panel Are we also affected or are they not truly gone? I'm not on the Dev build, but of course that change is coming for mainstream Win11 eventually.

I thought the same thing about public=Public when first going through the settings, and I see now that I did uncheck it for that reason. So, in my case it doesn't matter for search in my profile, which is in the default location. So, I'm not exactly sure what to think, but I think it's safe to assume that something wasn't accounted for with that setting relative to your uncommon scenario. Does MS still consider that an "unsupported" config, btw? I think at some point such a relocation caused big problems when it came to Windows upgrades, but that's a bit hazy now.

Interesting. Since I've never seen this, and it's not an underlying issue (i.e. doesn't happen without SaB), is it possible that it relates to a particular combo of SaB settings that I don't have? Maybe try "Set default values" in SaB's Start menu config area, though I don't know how comprehensive that is? BTW, 3.1.2 just dropped, so give it a try.

Wouldn't that relate more to your indexing situation? Perhaps go into Control Panel and rebuild it. I've yet to find an issue with search.

Version 3.1 22 November 2021 Center start menu with classic taskbar Central segment only (Dock-like) taskbar perk IME mode context menu works with classic taskbar Support for Dev build ~22500

No, still happens after reboot, though not right away. Vertical taskbar, if that matters. Reverted to 3.0.5, since not always knowing which programs are running at a glance is not really workable.

Which is: Version 3.0.6 15 November 2021 Language switcher can use Windows 10 flyout Tweaked taskbar buttons default look and position Fixed segments in exotic cases BTW, what is meant by "taskbar buttons," exactly? One thing I've noticed with this release is that the taskbar icons don't consistently have the visual indicator next to them indicating that the program is running as opposed to merely pinned. Not sure if that's just because I haven't rebooted yet after installing, but it's an odd problem that comes and goes but which I've never seen before. When it happens, hovering the mouse over the icon "refreshes" it.