I have a theory I am working on.. after testing a change to the file the other day, I decided to keep playing, which I think not only fixes this (or at the very least forces a refresh) to fix most of the taskbar preview bugs.

I have been playing with the JSM file. I basically think we can prevent most of the bugs from occurring if every time we make a change, do a task or look at or close out of taskbar previews that we recount the number of tabs, and force a reordering and re-draw. Basically instead of one or two code paths, bolt it to all them. like going from 10FPS to say 30FPS. It would I think increase the CPU cycles overall, but I think for me it fixes have a dozen bugs. I have the JSM file. Let me know (you can email directly) I was thinking of opening a new bug to investigate that.

My theory stems from issues trying to create accurate reports and tools for people. An example would be that had to force an Access database to do more frequent refreshes than the standard database code paths, because my users were using the database in code path scenarios that didn’t force some sort of update/refresh/recalculate step. Then noticing issues because I didn’t add that type check into the system. It did slow down the database, but it was worth it.

So I had to push access to update the data as much as possible to eliminate the case of the data doesn’t look right.

I think the Wintaskbar JSM needs to do this as well. I can upload a test file that we can review what I’ve been trying. Though, I remember you have a bug open about invalidating more often, but I wasn’t sure if that is directly what I’m trying to do since what I think I’m doing is forcing more array updates after we do any task like close/add/drag/activate/select a preview/close down the panel, etc.

thanks,
cuz84d