With the new sub-dock height, it happenes quite oftenly that the sub-dock is opening in the background, behind the dock icons.
Maybe it was always like this - with the higher dock position you wouldn't have noticed it.
Right now, I'd like to have the higher position back.
Just out of curiosity - why didn't you just add a sub-doch height setting to the sub-dock settings? Hard to implement? I don't think that it would make it more complicated however. It's a sub-menu anyway.



upload pic


I've also had some crashes, maybe 5 or so, within a few days. But I couldn't reproduce them.
Before, it only crashed when changing the monitors sometimes.
In the crash dialogue, there are the buttons "retry" and "abort". Retry doesn't do anything, and abort closes Workshelf.
Is there something I can do before pressing abort, to identify the cause of the crash?

Why did you wait until the official release to report these issues, Toni?

Anyway, lets hope the crashes are gone on the official release.

The sub-dock opening behind the parent dock should not happen at all given that the parent dock window is the 'owner' of the sub-dock window, and Windows should ensure that proper z-order is maintained.

It doesn't happen here, for instance. Do you mean that it happens there *sometimes* but not always? Can you figure out a pattern or a cause for when it does happen? Is anyone else having this happen?

Perhaps you could send me a backup of your settings to the Winstep support email address, so I can check them out myself and see if I come up with anything.

Sorry about that - I was quite busy the last days. Also didn't knew when the beta period will be finished.

So, just as writing this, I did a quick test, since most crashes occured while using the shelf.
And it just crashed when changing the tab. I have the feeling that it has something to do with folders.
Most times it crashes when changing from or to the tab that contains folders.
It has 14 folders, of which 2 are on an external hard drive.

About the z-position - it seems to be random... Just opended a sub-dock about 50 times while changing the focus in between. It was like, the 6th time, the 10th time, the 30th time... Can't see any pattern. But I'll continue my tests...

Yes, I've identified the cause of the crashes! Definitely the folder tab.
I just quickly clicked through all the tabs - except the folder tab - for about a minute like a maniac - nothing. As soon as clicking the folder tab and quickly another one -> crash.
Repeated the whole process with about the same result. This time it took about 2 or 3 seconds after clicking the folder tab, and the other tabs that I've clicked in the short time before the crash were kind of frozen. The tabs have changed, but not the icons.

It's the external drive. As soon as you click on a tab that contains folders on an external drive, you must not click anything until the drive is completely finished speeding up, otherwise Workshelf crashes.
Removing the external folders from the tab fixes it...

Update on the z-order - you don't have to change the focus.
Opening two sub-docks alternately leads to the same result...
And it really seems to be completely random.

Can somebody confirm this issue, before I start to uninstall stuff?

Thanks, that kind of makes sense.

I say 'kind of' because of two things: the code loop that retrieves icons for the Shelf is supposed to run without interruptions, i.e.; until that code completes running, nothing else in the WorkShelf application is supposed to run. That is why I implemented a feature in which the Shelf, if icon retrieval on that loop is taking too long, stops retrieving further icons and displays generic icons instead for the remainder of the loop. It then exits the loop and later goes through those generic icons via a timer routine, replacing them one by one with the proper icon. Similar to what happens with document thumbnails, I'm sure you've seen it happen before.

This way the Shelf remains responsive when you switch to a new tab even if retrieving *all* those icons would take a long time. Everything is nice and fluid.

Now, it seems to me that something outside of WorkShelf (related to icon retrieval) is unexpectedly causing the loop that should not be interrupted to actually be interrupted. Let me be clear: this should not happen. But apparently it sometimes can, and if it does then you become able to switch to a new tab while the loop is still busy retrieving icons for the previous tab. Result: you crash.

To prevent this in v17.12 I actually disable the Shelf window while in this critical loop so that even if it gets interrupted, the Shelf will not register any mouse clicks and act upon them. I had to do this because under Windows 10 something similar could happen when retrieving icons for the new UWP Apps tab - if it took too long, something would go wrong, the loop would get interrupted and you would see weird stuff, such as an icon appearing at the top left corner of the Shelf and lots of 'blank' generic document icons appearing instead of the proper icons.

So, unless it's something else, what you are describing could potentially happen previously to v17.12, but it's not supposed to happen at all on the official release.

Why don't you just disable parent dock magnification when sub-docks are open instead of uninstalling v17.12? Dock Properties -> Behavior -> Sub-Docks -> uncheck 'Allow parent dock magnification when sub-docks are open'.

I didn't mean to uninstall Winstep. If nobody else has the issue, than it could have been a conflict with something else I have installed. Which I'd then had tried to figure out.

However, I've found the cause: mouse movement!
If the cursor moves - even a tiny bit - within the short time span in which the sub-dock opens, it goes to the background.
With a slippy mouse pad and a high-DPI mouse, micro movements (like 2 pixels) are quite inevitable when clicking.
Disabled parent dock magnification now.

Actually, thinking better about this, I don't think that is where the interrupt happens. There is another critical code loop before it, the one that fetches the actual contents of a tab (not the icons, but the items in that tab, etc...). If that gets interrupted too, chances are you crash.

One question though: the tab that held the folder shortcuts to the external drive, is it a Regular type tab? Or a Folder type tab?

Good catch! No idea why it happens, but I kind of managed to reproduce it here if I violently shake the mouse pointer over the parent dock while the sub-dock is still playing the open animation. However, if I mouse over the sub-dock and then back into the parent dock, the z-order seems to sort itself out?! Can you test this there too, please?

Unfortunately I have the official 17.12 installed. But this specific crash is most probably not related to recent changes. I've always had issues with the folder tab. But mostly heavy lags and some rare crashes. It just seems to have gotten worse recently. Like less lags in exchange for more crashes.
Can't say for sure... Maybe it's just because I'm navigating faster meanwhile, because I got used to the folder order.
Lags and crashes with the shelf were there all the time however - which most probably were related to the external drive all the time.

Now that you mention it... it's actually set to regular. Have overlooked this. I'm changing to folder now and testing again...

EDIT: (final)
It works! No crashes anymore with the external drive, when using a folder type tab that links to a folder where you put all your folder shortcuts in.
The spinup time doesn't affect the shelf anymore at all.

So - don't add shortcuts to folders on an external hard drive to a regular type tab!

Yes, can confirm this. As soon as the parent dock icon magnifies, the sub-dock jumps to the foreground with a short delay - some tenths of a second.

Ahah, yeah, Folder tab types in the Shelf are like 'windows' into real folders in your hard drive. However, the only reason I asked is because I needed to know which code path to check in the first critical loop (each tab type runs different code).