Vista Tree-View control with auto-scroll style

[Jonathan Potter]

Hi,

I have been trying to use the new Vista Tree-View control extended style
TVS_EX_AUTOHSCROLL.

While this does work fine, there is a problem in that there seems to be no
way to discover the current horizontal scroll offset of the tree.

Normally when the tree has a scrollbar one can use GetScrollPos() to
discover the current scroll offset, but this fails if there is no scrollbar.
I need to know the scroll offset because I am doing custom drawing in the
tree.

Is there an (undocumented) way of discovering the horizontal scroll offset?

Thanks,
Jonathan Potter
GP Software

[Jeffrey Tan[MSFT]]

Hi Jonathan,

If there is no scrollbars in the TreeView control, what error code do you
get for GetScrollPos API? Is it 1447(The window does not have scroll
bars.)? If so, I think the simple solution is just detect this error code
and ignore it.

Does this make sense to you?

Please feel free to feedback your concern, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jonathan Potter]

Hi Jeffrey,

> If there is no scrollbars in the TreeView control, what error code do you
> get for GetScrollPos API? Is it 1447(The window does not have scroll
> bars.)? If so, I think the simple solution is just detect this error code
> and ignore it.
>
> Does this make sense to you?

Not really :)

GetScrollPos does not seem to return any error code. But even if it did I
think this is meaningless - because there is no scroll bar in the first
place (it has been disabled.)

The problem is, the TreeView control must have an internal record of its
horizontal scroll offset - however there seems to be no way for a client app
to obtain this.

Jon

[Jeffrey Tan[MSFT]]

Hi Jonathan,

Thanks for your feedback.

Ok, I will give it a research to see the best practise for this issue,

[Jeffrey Tan[MSFT]]

Hi Jonathan,

I have contacted the dev team for this issue, below is Raymond Chen's reply:

TVM_GETITEMRECT takes scrolling into account.

"Is there an (undocumented) way of discovering the horizontal scroll
offset?"

If it's undocumented you can't use it. If you try anyway, a lawyer will
eventually get in touch with you.

Hope this helps.

[Timo Kunze]

Jeffrey Tan[MSFT] schrieb:

> "Is there an (undocumented) way of discovering the horizontal scroll
> offset?"
> If it's undocumented you can't use it. If you try anyway, a lawyer will
> eventually get in touch with you.

LOL? Then maybe Microsoft should finally start to document things,
otherwise many programmers are criminals.

Just my 0,02 €
Timo
--
www.TimoSoft-Software.de - the home of ExplorerTreeView
"Those who sacrifice freedom for safety deserve neither."

[Jonathan Potter]

Hi Jeffrey,

Thanks for the response, I appreciate your efforts with this.

Raymond is partially correct, TVM_GETITEMRECT does take scrolling into
account, but only if the wParam parameter is set to TRUE. If wParam is set
to FALSE, to get the entire rectangle occupied by the item, it ignores
scrolling, and always returns a left offset of 0.

With wParam set to TRUE it does report the correct position but this is no
use, because it only returns the rectangle of the text label, not the entire
tree view item.

Additional to this, when processing the NM_CUSTOMDRAW message, the
coordinates provided in the TVNMCUSTOMDRAW structure also ignore scrolling,
and only report a left offset of 0. Therefore, without a visible scrollbar,
there appears to be no way to accurately determine the horizontal scroll
offset.

Regards,
Jonathan Potter

""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message
news:AmrjulCI...@TK2MSFTNGHUB02.phx.gbl...

[Jeffrey Tan[MSFT]]

Hi Jonathan,

Thanks for your feedback.

Yes, I have forwarded it to Raymond Checn, below is this further reply:
"Hm, yeah, the offset doesn't seem to be exposed in the paint path either.
Nobody in the shell team used customdraw + autoscroll, I guess. (As far as
I know, there's only one place that uses autoscroll and it doesn't use
customdraw.)"

Thanks.

[cptpe...@gmail.com]

It's been 13 years since this thread was active, and as far as I can see MS hasn't added anything to the API to fix this situation, which I've just recently been wrestling with myself. The combination of Custom-draw and auto-scroll doesn't seem that far-fetched to me, and I can't believe the problem has been such a low priority there in Redmond. Anyway, I figured out a kludge. When my TreeView is created, I obtain the text-rectangle of the first item in the tree:

HTREEITEM hFirst = TreeView_GetRoot(hwnd);
RECT rcFirst;
TreeView_GetItemRect(hwnd, hFirst, &rcFirst, true);

I then make a record of the initial rcFirst.left, and continue to monitor it every time drawing occurs. With each drawing, the same three lines execute, and the changes in the rcFirst.left values over time allow me to compute the true scroll position.

Cheers,
Christopher Taylor