As I’ve said, one of the first things I’m doing in Beta 1 is completely reworking the options dialog. This is obviously going to change a very large number of strings, which is why I didn’t want to release the translation template until then. But, this whole process is taking a whole lot longer than anticipated, and I know a lot of international users are suffering as a result. So, I’m caving. Here it is. I’ll say it again just to be unequivocal: any translation based on this file will be incompatible with Beta 1! But, it’s going to be a while before we get there (I’d say mid-January at the earliest), so if people want to start translating this one, so be it. Send me your translations and I’ll add them to the SourceForge file listing. I’m sorry for not doing this months ago; stubbornness is not one of my better qualities…
Also, just to clear up any misconceptions about the hittesting thing: I’m not going to delay releases while spending massive amounts of time reverse-engineering the ItemsView object, when I could be implementing new features or fixing more important bugs. I’m still going to work on it in the background, but don’t worry: I know how to prioritize. I may be a perfectionist, but I am not completely without pragmatism!
Greek, Russian, and Chinese language templates have been added to the Sourceforge file listing. Thanks to George Georgiou, Alexander Shalamov, and easyt (respectively) for their contributions.
Let’s talk about the scrolling lag bug. It’s the end of an era here, as I finally have a bit of closure. Brace yourselves, this is a long one, and it doesn’t have a happy ending, I’m sorry to say.
As I’ve written about before, one of the chief difficulties in making QTTabBar work on Windows 7 was the fact the good old clunky-but-heavily-documented ListView control was replaced with the new smooth, sleek, and totally-undocumented ItemsView control. The biggest problem is that there was no apparent way to figure out what item the mouse was over, which is important for tons of things that QTTB does.
At first the problem seemed insurmountable, but then I stumbled upon UI Automation, which seemingly solved all my problems: It allowed me to hit-test the ItemsView accurately, and even allowed me to get the bounding box of each item (something required in order to know where to position the blue arrows). Best of all, the method was even documented!
Unfortunately, it turns out that UI Automation itself is directly responsible for the unresponsiveness that users have reported. It turns out that every single individual query degrades Explorer’s performance slightly, but permanently. After many queries, it becomes slower and slower and slower, and restarting the Explorer process is the only way to “reset the counter.”
Posting on various Microsoft developer forums about the problem yielded no useful results. One forum poster suggested I contact Microsoft Support about the issue. That sounded like a good idea, until I saw the $99 price tag. Pay Microsoft to fix their own bug? It think not. However, after some more Googling, I discovered a claim that Microsoft Support will not charge you if the issue you’re reporting turns out to be an actual bug on their end. I contacted the support line about this (yes, there’s a support line for the support line) and to my surprise, the representative confirmed this. So, I typed up a nice little report and sent it in.
I was contacted my Microsoft’s Rob Caplan about the issue, and after some back-and-forth, he confirmed it was a bug on their end. We looked for some workaround, but in the end, the only feasible one was “Just use the old ListView,” which I’m not happy with. So, we went through the process of filing an official hotfix request. That was about 2 months ago. Finally, just a few hours ago today, Rob called me to inform me that the hotfix request had been rejected on the grounds that the “use the ListView” workaround is good enough, and the problem is apparently deep enough that a fix would too complicated. Game over…
So, what can we do about it? Well, as I said, the problem only affects the ItemsView, so if you use the older ListView control, you will not experience this problem. In addition, I made several changes from Alpha 3 to Alpha 4 to minimize the number of queries made. In particular, if you don’t want to sacrifice the ItemsView, you can disable Subdirectory Tips (or at least put them on Shift-only) and that will greatly reduce the number of queries made (which will greatly slow the speed at which the lag builds up). Past that, all I can recommend is to use AutoHotKey to make a “restart explorer” hotkey to clear things up when it gets bad.
There is hope, however, albeit slim. The ItemsView is controlled by an undocumented COM interface, which I have succeeded in gaining access to. In essence, I have a whole bunch of functions with no name or parameter definitions. One of them is likely in charge of hittesting. If I can figure out which one it is, and how to call it, then all problems will be solved. Of course, even assuming I’m successful, making use of an undocumented COM interface is a REALLY BAD idea in general, as Microsoft could change it without warning. But in the absence of all other options, it looks like the only way left. Either way, I will certainly keep the Automation code around though, so we’ll have something to fall back on.
I’m sure some will say, “Scrolling lag? I don’t even know what you’re talking about!” or “Yeah I notice it, but it’s not that big a deal to me…” Sometimes I envy people like that, who are able to ignore or overlook annoying problems like this one. But me, I’m a perfectionist, and I will not feel at ease until this problem is completely eradicated. I just hope I can do so before Windows 8 comes out and inevitably breaks everything again!
I just wanted to post and let everyone know that I’m not dead, even though I haven’t touched QTTabBar in the last few weeks. My workload this semester has turned out to be absolutely brutal, leaving me little time for anything else. Alpha 5 has actually been almost ready for a while now, I just need to find the time to stabilize it just a bit more so I can push it out the door. I appreciate your patience, everyone. The good news it that my next semester is looking like it’s going to be very light, so I will have a lot more free time to devote to this project once the current semester is out of the way.
I’m getting a lot of bug reports in the blog comments. This makes things difficult for me, as blog comments are not very organized and easy to forget about, especially since there’s no way to enable email notifications. So if you have a bug to report, please please please use the Trac. Not only does it make it easier for me to fix your bug, but it makes it easier for me to respond to you with a possible workaround or at least confirmation that I can reproduce your problem.
Today I’m happy to announce QTTabBar 1.5 Alpha 4. Hit that link to your right to go grab it. This release features a lot of bugs fixed and functionality restored. Please accept my apologies for not getting it out the door sooner; I really didn’t intend for Alpha 3 to last this long.
At this point, pretty much everything that’s going to be restored has been restored. With the exception of the Desktop bar and maybe a couple other minor things, as of this release, we’re finally caught up with Quizo’s version. You know what that means: time to start adding new things! In addition to bug fixes, Alpha 4 features our very first brand new feature. Behold!
That’s right, quite possibly the best part of Windows Vista, “Display column headers in all views” is now available to Windows 7 users! You can find the option on the Misc tab of the Options menu.
Unfortunately, this release will still exhibit the scrolling lag bug. I actually have quite a story to tell about it: what it is, what causes it, and how I’ve been battling it for the past month. I’ll be talking about that in the next post. For now, what you need to know is that if it’s bothering you, you can switch back to the old SysListView control. This is now built into QTTabBar, also on the Misc tab.
If you followed that guide to activate the SysListView that required messing with the registry, I thoroughly and completely recommend undoing it now! The reason I say this is because the registry hack is very flakey and very difficult to revert. Plus, it does not affect some types of folders. The option QTTabBar provides is much easier to toggle, affects all folder types, and doesn’t cause any weird side-effects.
You may be wondering why this thing is still in Alpha when it’s as stable as it is. Well, there’s one more feature that I want to tackle before really moving forward to the Beta series: opening new tabs from the folder tree. Originally, that feature was supposed to be part of Alpha 4, but I decided against it. I have a really cool way to get my hooks into the control, but I’m worried the method I have in mind might set off some of the more paranoid antivirus programs. As such, I’m going to release an Alpha 5 pretty soon just for that feature, and we’ll see if anyone’s antivirus starts screaming bloody murder. If there are no complications, it’s on to Beta 1!
Thanks again for everyone’s support!
Here’s the changelog for this release:
======= 22.214.171.124 Alpha 4 =======
General stability improvements, more exception logging code added
Changing environment variables on x64 systems no longer crashes Explorer
Tabbar/Toolbar positioning now works correctly on XP
Search box no longer mysteriously shrinks when focused
Closing dialogs in Win7 such as the Firewall dialog works correctly
Subdirectory Tips appear and disappear when they should, drag and drop into them much easier
Opening a new tab by navigating on a locked tab opens the tab in the correct location
Minimize to tray no longer crashes Explorer
Full Row Select can be enabled/disabled when the SysListView32 is used
Tabs are restored only on the first instance, not on subsequent instances
Libraries can be dropped into
Desktop Bar restored for XP/Vista
F2 rename selection functionality restored
SelectionChanged plugin event fires correctly
Cursor looping reimplemented
"Use old ListView control" option enabled
"Display column headers in all views" option enabled
UPDATE: If the installer is giving you “error registering assembly,” please redownload it, as I have corrected the problem. Sorry for the inconvenience. There is no need to redownload if you didn’t get this error.
Hi all. Bad news, I’m afraid. It looks like the Desktop Bar isn’t coming back in the foreseeable future. XP and Vista users needn’t worry; it worked in Quizo’s version so of course it will work in mine. But Win7 users are out of luck: Microsoft removed a critical undocumented feature that the Desktop Bar relied on.
In order to do anything useful with Explorer, you need a way to access the IFolderView interface of whatever window you want to control. In regular Explorer windows, this is achieved by requesting it through the IShellBrowser interface, which is supplied to QTTabBar as part of the whole toolbar package. But the desktop bar can’t get it so easily. In Quizo’s version, the IFolderView interface for the Desktop was acquired through a secret, undocumented message: WM_GETISHELLBROWSER. This message returned a reference to the Desktop’s IShellBrowser, and from that, you can get the IFolderView, just like regular Explorer windows. And that works great on XP and Vista, so I had no reason to expect it wouldn’t on 7. So, after slaving away for the last few days making massive code rearrangements to get the Desktop Bar functional again, I’m ready to plug it in and see it fly. I hit Run, and it immediately crashes… What could be the problem? I take a look, and surprise surprise: WM_GETISHELLBROWSER was returning absolutely nothing. I ran it on XP and Vista to test it, and the good news is that it seems fully functional again on those platforms. But it looks like Microsoft removed that little undocumented feature in Win7, so now I have no way of getting that critical interface, which means nothing will work. Sigh…
I have a few ideas as to how I might get the interface some other way, but they all involve some major coding with no guarantee of success, and I don’t want to delay the next release while I search for a method that may not exist. So, bottom line, the next release won’t have a functional Desktop Bar on Win7. Oh, well… Truth be told, we should be counting our blessings that this thing works at all. There were some dark days before I found out about UI Automation where I was pretty convinced it was a lost cause. Thankfully however, the major features all survived, and things will only get better from here. Work is progressing smoothly, and the next release is almost ready. Thanks to all who sent in bug reports, and even more thanks to those who have donated.
In case you don’t know what the Desktop Bar is, it’s a component that provides QTTabBar features such as subdirectory tips (blue arrows), preview tooltips, tracking of recently opened files, etc, for files and folders on the Desktop. It also provides a menu that can be accessed from the Taskbar to open tab groups and such.
Sorry again for the sparse updates. I’m sure some people are paranoid that I, too, am going to suddenly vanish without a trace. But rest assured, I’m very much alive. I’ve actually been on vacation his past few weeks in a place with slow-as-a-snail internet. The scenery was worth it though.
Anyway, I just wanted to say that I know about the scrolling lag bug. I wanted to wait until I had a more concrete resolution, but it’s taking a lot longer than anticipated. I’ll make a nice, long, detailed post once I have more information. The short version is this: it is completely Microsoft’s fault, and unless I can get them to fix their own bug, there will be nothing I can do about it short of forcing QTTabBar to use the old SysListView32. I have a few leads as to how to accomplish this that I’m working on. I’ll keep you all posted.
Greetings everyone. Sorry about the lack of updates recently. Such is the life of a grad student!
Anyway, I’m happy to announce that the plugin library seems to have survived the transition mostly intact, and all existing plugins need only to be recompiled with their source code referencing my version of the plugin library to work again. I’ve added the Quizo-written plugins to the repository, and uploaded compiled binaries to the SourceForge download page. Here’s a link, for your convenience. From what I can tell, the only plugin-related thing that’s currently broken in Alpha 3 is the “selection changed” notification, which only the FileTools plugin uses (to disable buttons when no files are selected). This will be fixed in Alpha 4, which, by the way, will most likely be the last Alpha.
The plugin library itself needs to be prettified and documented before I can pack it up into a nice little SDK, but anyone who wants to can check it out from the repository and start making their own plugins right now.
On an unrelated note, due to the rising level of comment spam, I’ve had to set up a captcha for comments. Sorry for the inconvenience.
You know where to grab it. This release should be much more stable and less quirky than Alpha 2. In addition to bug fixes, I’ve restored Tab Locking functionality. Here’s the change log, which is now a part of the repository.
In other news, I’ve decided that I absolutely hate the SourceForge tracker system. As such, I’ve enabled the infinitely better hosted app Trac, which will be replacing it. All existing defect tickets were already fixed, so I didn’t port them over. I did copy over the enhancement requests. If you authored one of them, please add yourself to the CC list for the ticket to be notified about any changes regarding it. I’ll keep the SourceForge trackers active for a few more days, but I’ll be deactivating them soon.
Last time, there were a few people who posted bug reports in the blog comments. Please don’t do that, as it makes it difficult to keep track of them all. If you find something wrong with this release or want to request a new feature, please open a new Trac ticket for your issue.
Many thanks go out to all those who submitted bug reports for Alpha 2. I’d also like to profusely thank all those who have donated money; your contribution really means a lot to me.
Good news, everyone!
The CPU-leaking bug has been found and fixed. Many thanks to all those who sent in debug information, and especially big thanks to Mark Wessel, who figured out exactly how to reproduce it and assisted with a few debug builds. Apologies to those who offered to help and got no response; I think my SourceForge mail is broken somehow. (My experience with SourceForge has been less than shining lately.) Anyway, I want to fix just a few more things before the next release, but Alpha 3 should be arriving soon.
For the interested, I’ll post the gory programming details a little later.