They say there are no dumb questions..scroll bar issue

[rmangel]

Hello all and thanks to Kinook for this excellent piece of new software. OK, I just downloaded a trial of Ultra Recall and am getting to know it. My first problem: the scroll bars on the various panes (Search, Data Explorer, Item attributes) do not work. I can tell there are additional items in each list but the scroll bar does not respond to my mouse. This has got to be some incredibly simple oversight on my part but I'm stumped as to how to correct this problem. Thanks for any help!

[kevina]

I don't know how Ultra Recall could be configured to give the bizarre behaviour you describe. When you say the scroll bars don't respond, what exactly do they do (or not do)? Do they appear disabled (grey) or simply won't slide, or??

What Operating System/Service Pack are you using? What version of Ultra Recall do you have installed (you can view this @ Tools -> About -> Install Info...).

[rmangel]

Hi Kevina,

I'm using XP Pro w/SP2. UR version is 1.2a. The scroll bars are not greyed out. When I try to "grab" it or click the up/down arrows they just do not respond.

For example: I click on web search in the search pane; the scroll bar in the search pane won't let me scroll back up to the search items at the top of the list. When advanced search is selected, I cannot scroll down thru the items in the child items pane. If I go down to the last child item I can see and select it then the child item below that will appear(in this case Folder, I click it, and Google then appears in the list below). I can continue like this down thru the list but cannot scroll down or back up. I have not changed any of the default settings that I'm aware of...I actually just started using UR today.

One other observation - the Item Details scroll bar works, both horizontal and vertical, but no luck with Search, Data Explorer or Search Results scrolling horiz or vertical.

Russell

[PureMoxie]

I'm experiencing the same issue. I also have XP SP2 and UR 1.2a.

My mouse scroll wheel works when the pointer is over the data explorer pane, but selecting or clicking in the scroll area doesn't scroll the pane.

rmangel, are you running WindowBlinds? That's the only thing I can think of on my system that might cause a problem.

[rmangel]

Thanks for your response PureMoxie. Yes I am running Window Blinds. I hadn't considered that as a culprit but I'll bet you're right on.

The mouse wheel is an acceptable work around for vertical scrolling but the horizontal scroll bars are still unusable.

I also don't understand why the Item Details pane scroll bars work fine but all the other panes do not??....

[srdiamond]

This behavior can be the result of a conflict with the skinning application WindowBlinds. I find that some of the schemes have this effect on UR and others don't, but most do conflict. You can set the scheme for UR as different from the others, if you don't want to use a UR-friendly generally throughout the system. A scheme that I find works with UR is called XP Copper, in case you want to test whether this diagnosis is accurate.

Maybe on your system it's something else, but it seems to me that the fact that this behavior is caused by Windowblinds probably indicates that if there's a different cause in your case, it probably is the result of some other software conflict.

Stephen Diamond


Originally posted by kevina
I don't know how Ultra Recall could be configured to give the bizarre behaviour you describe. When you say the scroll bars don't respond, what exactly do they do (or not do)? Do they appear disabled (grey) or simply won't slide, or??

What Operating System/Service Pack are you using? What version of Ultra Recall do you have installed (you can view this @ Tools -> About -> Install Info...).

[rmangel]

Thanks for your help Stephen and Chris. I simply excluded Ultra Recall from being skinned in the Window Blinds options...navigation works great now.

Russell

[srdiamond]

While probably 99% of Windowblinds schemes are incompatible, there are various excellent ones that work. Most of these are by the skin designer Essorant, one of the best. The converse isn't true though: most of Essorant's skins do NOT work.

Here are some excellent Essorant skins that work: Sinter, Ferix, bazoob, Intrastate, Phase_Change, vGreen.

Other good Essorant skins that work: Jinx, Melt.

Other very popular and contemporary skins that work, more recent than any of the ones above: Liquid2 (Dangereuse), DogmaX 4 (Brewman).

Some "archaic" skins that work, by Alexandrie: XP Copper, XP Coppery, XP Charcoal.

You can also instruct Windowblinds not to skin UltraRecall or to use another skin for it alone (from the above lists). Neither of these really works right, in that the appearance turns out worse than if you had not used Windowblinds. Things are combined or omitted in the process of filtering.

Users of Windowblinds in most cases will (imo) find Ultra Recall's Data Explorer unusable. How many will think to check the FAQ? The use of Windowblinds is sufficiently widespread that this must count as an impediment, and I'd suggest that the incompatibility be treated as if it were a bug, which it arguably is.

Stephen R. Diamond

[lerognon]

Hi,

I've been able to modify an incompatible skin to work with U.R.
- Go to stardock.com and download their free SkinStudio
- Load your skin
- Go to Controls/TreeView Expander
- Delete the Image
- Save & reload the modified skin

Sure you loose the little customization of the Internet Explorer Tree at the same time. But you don't have to exclude U.R. from W.B. any more.

Regards
Eric

[srdiamond]

What is the 'Internet Explorer Tree'?

[srdiamond]

Originally posted by lerognon
Hi,

I've been able to modify an incompatible skin to work with U.R.
- Go to stardock.com and download their free SkinStudio
- Load your skin
- Go to Controls/TreeView Expander
- Delete the Image
- Save & reload the modified skin

Sure you loose the little customization of the Internet Explorer Tree at the same time. But you don't have to exclude U.R. from W.B. any more.

Regards
Eric

This does work, which I find is very good news. To elaborate a bit on the method, you need to select the tree view expander, right click, and choose "remove section." The "Treeview Expander" element then becomes gray, because the element cannot be romoved. Although you have selected "remove section," you have only removed the removable part of an otherwise mandatory section.

What you remove is a small bitmap, which represents the collapsed and uncollapsed states of an Explorer tree (Windows Explorer not just Internet Explorer). Each Windowblinds scheme typically has its stylized way of representing the collapsed and expanded states of a tree node. When you remove the bit map, the representation just reverts to the Windows default, which is a plus and minus sign.

[Why does UR's Data Explorer choke on the Windowblinds tree bitmap? The conflict does not occur merely because this interface element is changed. If you take an MS Style (which can be applied in various ways, the easiest being the tgtsoft utility), it may change the expander icon, but there's no conflict. Put the MS Style in Skin Studio and convert it to Windowblinds format and the result is that the same interface element creates a conflict in Data Explorer.]

[srdiamond]

Knowing what to look for, it seems easy to see something of the nature of the conflict between WB and UR. If you load a conflicting WB skin and look at the Data Explorer, you see that the tree expander icons are way too big. Either UR doesn't read the size correctly or WB fails to adapt to the small print in Data Explorer.

[This suggests a test that I haven't tried. If you increase the size of the font in Data Explorer, will it work right? The user can't currently do the experiment. Could that be the problem? Does WB expect (because of some mis-synaling) that the host application will have the internal resources to size fonts? In other words, WB should be set so that it omits UR from skinning the expander icon, because it can only skin sizable fonts? A non-programmer's guesswork, fwiw.]

[kinook]

Thanks for the details on workarounds. We have submitted the issue to the vendor of our tree component and the makers of WindowBlinds. The tree vendor won't investigate because they (understandably) don't explicitly support third-party Windows extensions such as WindowBlinds.

The only way this will get fixed is if the WindowBlinds folks make their product more compatible with plain vanilla Windows so that the tree component works properly under WindowBlinds. We haven't heard much from them on the issue yet. Their contact info is support@stardock.com (reference Ticket ID AKC-878389, SftTree/DLL WindowBlinds incompatibility).

[srdiamond]

Originally posted by kinook

The only way this will get fixed is if the WindowBlinds folks make their product more compatible with plain vanilla Windows so that the tree component works properly under WindowBlinds. We haven't heard much from them on the issue yet. Their contact info is support@stardock.com (reference Ticket ID AKC-878389, SftTree/DLL WindowBlinds incompatibility).

They say it's on their list. The problem, however, is not an incompatibility between the Windows component and Windowblinds, unless my assumption is wrong that the "Windows tree expander" is a single Windows component. If there were an incompatibility between that component and Windowblinds, the problem would occur whenever it Windowblinds encountered a Windows tree, whereas the only place it occurs that I know of is in the UR Data Explorer. The Windowblinds people tentatively seem to confirm my impression that the implementation in UR is faulty due to its not allowing the expander to be sized. It is actually visible that the expander in the Data Explorer gets too large with Windowblinds. But this doesn't happen in any other Windows trees, and plenty of them exist. It even works in programs which don't allow the user to change the font size, and the font size is as small as in UR.

Unless there are multiple Windows expander components that are inserted in different programs, this seems clearly an issue the tree manufacturer ( or grower, as it were) is responsible for. Blanket refusal to take responsibility for compatibility with third party programs seems unreasonable, where the incompatibility is the result of a component's failing to perform properly.

[kinook]

The tree component (SftTree/DLL by SoftelVDM) draws and operates properly on all Windows versions without WindowBlinds installed. It's only when WindowBlinds is running that there is a problem (and there are actually two problems -- sizing of the +/- button and improper drawing/responsiveness of scrollbars in some situations).

There may be something about the tree control that is less compatible with WindowBlinds than other tree controls, but I can certainly understand this tree vendor's position that they can't possibly support all third party Windows extensions such as WindowBlinds. The burden is on these third party vendors to make their environments fully compatible with plain vanilla (no third party extensions installed) Windows, so that applications that operate correctly there also operate correctly with the extensions installed.

I have no idea how WindowBlinds actually hooks into Windows to provide its functionality, but if they can provide specific technical info that demonstrates that the tree vendor is doing something improperly (incompatible/incorrect WRT plain vanilla Windows APIs), we would be happy to forward the info to the tree vendor in hopes that they will investigate further.

[kinook]

The bad news is that it's still unclear whether the blame for the problem lies in the tree component or WindowBlinds (or perhaps a combination and/or Windows APIs that defy their documentation).

But the good news is that with a little inside info from the WindowBlinds support team and some astute investigation from a UR user (who took the time to download and toy around with the problem tree component), we have found a way to work around the tree +/- button drawing issue. (It also turns out that the scrollbar drawing problem only affects the trial version of WindowBlinds; the WindowBlinds people are still investigating to see if that can be rectified.)

The workaround will result in the +/- button in the tree not honoring any WindowBlinds skin customizations (I'm not sure how common that is) and always using its own button images under WindowBlinds, but at least it will draw in the correct size. Look for another release with this fix on a web site near you in the next few days. And thanks for everyone's input.

[srdiamond]

Originally posted by kinook
It also turns out that the scrollbar drawing problem only affects the trial version of WindowBlinds

Sounds good, except for the above, which isn't true. (Actually, I'm not completely sure I know what "scrollbar drawing" means, but if the problem referred to is the inability to scroll using the scrollbar in Data Explorer, the problem affects the registered version of WB.)

[kinook]

Originally posted by srdiamond
Sounds good, except for the above, which isn't true. (Actually, I'm not completely sure I know what "scrollbar drawing" means, but if the problem referred to is the inability to scroll using the scrollbar in Data Explorer, the problem affects the registered version of WB.)
Which version of Windows and WindowBlinds and skin are you using? What exactly do you mean by 'inability to scroll'? Dragging and scrolling the scrollbar thumb? Click the up/down buttons? Clicking the non-thumb portion of the scroll bar?

On Windows XP SP2 (running in Virtual PC 2004 SP1) w/ the WindowBlinds 5.0 trial and the DogmaX4 and Airframe skins, I was able to reproduce the following scrollbar behavior: the data explorer tree scroll bars were not drawn properly (underlying desktop/application shows through where scrollbars should be) and do not respond to any mouse clicks. When I installed the full, licensed version of WindowBlinds v5.00[b].010, both problems went away (the skinned scrollbar displayed properly and responded to mouse clicking and dragging).

[srdiamond]

Originally posted by kinook
Which version of Windows and WindowBlinds and skin are you using? What exactly do you mean by 'inability to scroll'? Dragging and scrolling the scrollbar thumb? Click the up/down buttons? Clicking the non-thumb portion of the scroll bar?

On Windows XP SP2 (running in Virtual PC 2004 SP1) w/ the WindowBlinds 5.0 trial and the DogmaX4 and Airframe skins, I was able to reproduce the following scrollbar behavior: the data explorer tree scroll bars were not drawn properly (underlying desktop/application shows through where scrollbars should be) and do not respond to any mouse clicks. When I installed the full, licensed version of WindowBlinds v5.00[b].010, both problems went away (the skinned scrollbar displayed properly and responded to mouse clicking and dragging).

I'm talking about the failure to respond to mouse clicks. I never noticed the problem with the desktop showing through. I have the licensed version, downloaded this week, but it is v5.0.0.0 So it sounds like this was a very recent change.

---

I have downloaded the current public licensed version, and it's still at 5.0.0.0. Did their tech support send you that update or is there a public beta that I'm unaware of?

[kinook]

Originally posted by srdiamond
I'm talking about the failure to respond to mouse clicks. I never noticed the problem with the desktop showing through. I have the licensed version, downloaded this week, but it is v5.0.0.0 So it sounds like this was a very recent change.
Anybody who is still experiencing this behavior with v1.4a, please post the versions of Windows, WindowBlinds, and the skin you are using.

I have downloaded the current public licensed version, and it's still at 5.0.0.0. Did their tech support send you that update or is there a public beta that I'm unaware of?

I used StarDock Central with default settings to install.

[srdiamond]

Originally posted by kinook

I used StarDock Central with default settings to install.

I just learned of Stardock Central yesterday. As of yesterday, the latest beta has advanced by one over the one you posted. 5.0 [b] .0.1.1, or however that's done.

All problems with UR now appear to be solved. The proper Windows expander now displays, at the right size, and the scroll bar can be operated by clicks.

[kinook]

That is excellent news. The update resolved the +/- sizing issue in my tests as well. It's better than the workaround we had planned to implement, since the +/- button can now honor the WB skin. Thanks.