Visual bugs with Windows 11 & Windowblinds/Start11

[Solf]

Hi,

I've been a happy TC user since something like version 4 (decades?). However recently I've had to try and to use Windows 11. And I've ran into some significant visual issues there (using both Windowblinds + Start11 which seem essential to making Win 10/11 even remotely usable to me). I've tried all of the TC v11 versions and some of v10 versions -- they all seem to be similarly affected.

I do realize that integration with 3rd party skinning software and fixing bugs is a very dicey proposition; so I'll include suggestions for workarounds which seem like they should be easy to implement and would mostly fix the issues I've encountered.

Progress display gets stuck on full(-ish) on the taskbar

When TC (or other programs such as browsers) performs operations such as copying or deleting it apparently 'publishes' the progress of the operation to the OS -- so that the OS can draw the progress on the taskbar button. In case of TC on Windows 11 (and with Windowblinds + Start11) it somehow seems to get stuck at maximum (or close to it) -- i.e. after operation completes the taskbar button still displays the 'in progress' status and it never goes away. This is very distracting given the skin I like to use has a very visible indication of task progress.

To be clear -- this doesn't happen with other programs (e.g. browser), so it's at least partially specific to TC. It also works fine on Windows 10 (also with Windowblinds but w/o Start11)

Suggestion for easy workaround: an option to disable this integration in TC would solve most of the problem for me (i.e. for TC to not report 'progress' operations to OS). I won't be able to see progress on the taskbar (for TC), but it's not a huge loss.

My current workaround: change skin to not display progress on taskbar at all (for all apps).

Lister/viewer scrollbars are not drawn properly

Most of the time (although not always) scrollbars in built-in viewer are not drawn properly -- meaning they are completely all over the place in terms of appearance, there's something deeply wrong going on with Windowblinds skinning. This is using maximized viewer window.

If I un-maximize viewer window, it gets even worse, but I don't usually use that, so I'm not too worried about this.

The scrollbars render fine on Windows 10 (w/ Windowblinds) in maximized viewer window. They very much break if I un-maximize viewer, but I basically never do that, so I don't really notice.

Suggestion for easy workaround: I've noticed that if viewer gets opened without scrollbars (e.g. 'wrap text' on to avoid horizontal scrollbar and small file to avoid vertical scrollbar), then it renders properly; if after viewer is already open scrollbars 'appear' (i.e. by disabling 'wrap text' and, for example, by editing file to be longer and reloading it in viewer via F2) -- then they always appear and render properly. So the workaround could be to have an option to always initialize viewer window without scrollbars first and then enable scrollbars after a short (hopefully imperceptible) delay.

My current workaround: it seems like re-logging windows account (and thus reloading windowblinds) may sometimes fix the issue (although I'm uncertain how long such fix will stick) -- there's probably some race condition somewhere or something.


If anyone has experience with this or any suggestions -- they will be very much appreciated!

Thanks!

[ghisler(Author)]

I think you should report this to WindowBlinds - Total Commander works fine with all regular Windows themes.

[umbra]

Could the first issue ("Progress display gets stuck on full(-ish) on the taskbar") be related to https://www.ghisler.ch/board/viewtopic.php?t=81900 ?

[ghisler(Author)]

No, this is about the progress shown in the Windows task bar. The progress bar does not have a paused or stopped state, just a percentage position. My guess is that the WindowBlinds implementation cannot handle the case where the progress bar position decreases. Normally it only goes up from 0% to 100%, but this ignores the case where there are multiple copied files going from 0% to 100% and starting again at 0%.

[Solf]

Apologies for delayed answer, didn't realize I didn't configure the board to notify me via e-mail.

I do agree that the problems are likely primarily related to something that WindowBlinds does.

However it is also probably related to things that Total Commander does -- I will list some of my thoughts below.

Primarily I really have no hope/expectation of WindowBlinds doing anything about the problem if I report this to them. I might be wrong about that and I might try that route yet, but my expectation is that any interaction problem between two pieces of software (as I believe this to be the case) is highly unlikely to get any attention beyond "it's the other piece of software's issue".

I also fully understand that both you and WindowBlinds developers are unlikely to be particularly interested in troubleshooting this kind of a weird edge case. This is why I suggested the workarounds in my original post in the hopes that they might be rather trivial to implement and you might be willing to make a build with them to see if that fixes the problems.

In any case -- I really appreciate all the work you did on TC and it's been a tremendous help for me over all of those years. I hope I'll find a way to keep using it even with Windows 11. Thank you!

---

---

My thoughts/observations on the TC+WindowBlinds behavior:

- This stuff (taskbar progress & scrollbars) work fine with almost all programs (e.g. firefox, notepad++, etc.); however for Total Commander it breaks badly for some reason.
- I just tested taskbar progress with copying a single large-ish file (i.e. it should never go backwards) -- it still very much gets stuck for TC. At least once I observed a situation where it would disappear at the end (as it should be) and then come right back and get stuck at something like 95% progress.
- The scrollbar thing... this is also probably related to something that TC does (and just to be clear, I'm not saying TC is doing something 'wrong', it's just something 'unexpected' so to say).
-- First of all, scrollbars work completely fine inside TC main window itself -- it's purely in viewer/lister window where they break badly.
-- They work fine when viewer is maximized AND scrollbars get enabled after the viewer is already open (such as by making file larger and doing F2 refresh) -- this seem to possibly relate to such things as controls initialization order or something?
-- If viewer is not maximized, then scrollbars break in a very weird way -- e.g. toggling text wrap on/off (so the horizontal scrollbar should appear/disappear) makes viewer window bigger each time -- and scrollbars are not rendered properly at all in any case. This seem to possibly relate to the sizing of window (e.g. taking into account space to be taken by scrollbars and possibly trying to render them outside the visible window? -- but it's a pure speculation on my part).

What is possibly related is that I disable font-smoothing and run 125% scaling via Windows10_DPI_FIX.exe (which forces actually usable scaling, not a blurry mess (in e.g. inireloc.exe) that standard scaling does).

[ghisler(Author)]

You could try using the internal progress bar instead of the Windows one:
Open the file wincmd.ini via Configuration - Change settings files directly.
Then add a new line under the [Configuration] header with content:
NewStyleProgress=0

Then Total Commander will draw the progress bar by itself. However, this only applies to the forecground copy dialog. The background copy dialogs always use the Windows progress bar.

[Solf]

You could try using the internal progress bar instead of the Windows one:
Open the file wincmd.ini via Configuration - Change settings files directly.
Then add a new line under the [Configuration] header with content:
NewStyleProgress=0

Then Total Commander will draw the progress bar by itself. However, this only applies to the forecground copy dialog. The background copy dialogs always use the Windows progress bar.

Thanks for the suggestion.

Unfortunately it doesn't seem to help -- the behavior appears unchanged regardless of this setting (the progress bar still gets stuck at 'almost full').

Is there a way to try disabling it completely?

[ghisler(Author)]

Then it's not a WindowBlinds problem. I have seen this with some drives where Windows writes everything to the disk cache immediately and then flushes the data to disk when the file is being closed. I do not know when this happens, but you could try a different copy method in Configuration - Options - Copy/Delete.

[Solf]

I am not sure how do you mean that?

The progress bar appears to function properly (i.e. it advances properly etc.) it just doesn't 'go away' properly when operation is finished.

It also happens when copying e.g. large-ish file to an USB flash drive (for which I can't even enable the write caching at all) -- the operation takes ~30 seconds, progress bar is updated very much normally to the end (on the taskbar), it's just doesn't go away when copy completes (shows basically 100% filled bar).

When I tried to enable NewStyleProgress=0 as suggested -- I saw absolutely no difference in how the progress was displayed. Am I supposed to see something different? Maybe somehow I didn't get the option working?

[ghisler(Author)]

USB flash drive

That's what I meant with "some drives": The progress bar only shows the read operation in this case, the data all goes to a cache (in RAM). Windows then writes the data to the flash drive when TC closes the file. That's why it stays at 100% for a while. If your flash drive has an LED, it should be flashing during that time.

[Solf]

Sorry for the delayed answer, I was traveling.

I did some more testing and I don't think this is related to specific drives.

- It doesn't happen when not using WIndowBlinds/Start11 skin -- i.e. using default Windows11 taskbar -- it shows progress correctly and then it 'disappears' correctly.
- The 'stuck progress' also happens when I cancel the copy process midway through (using single big file) -- it gets stuck at the point where it's cancelled.
- It happens with all the different drives I was able to test.

It truly seems like there's some incompatibility between what TC is doing and what WB/S11 expect.

[ghisler(Author)]

Well, TC follows Microsoft's development instructions, so the progress bar should work with any theme. It just seems that WindowBlinds doesn't support a progress bar which can get shorter. I don't really see a way to fix this except for closing and re-opening the progress dialog after each file, which is unfeasible.

[Solf]

I'm not sure why do you think the progress bar gets shorter in those cases? As I mentioned, it happens when copying a single file or even canceling copy-in-progress (of a single file).

Is it difficult to make a test build with progress reporting disabled?

[umbra]

2ghisler(Author)
I realize that you have already dismissed my previous comment (https://www.ghisler.ch/board/viewtopic.php?p=457178#p457178). But since you cannot find any other issue that could explain the reported behavior, maybe there is some relation?