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.