Tree Scrollbar Issue

[IdeasVacuum]

PB5.20 Beta12 WinXP x86
Just hit a problem I wasn't expecting - the Tree scroll bar, at 100%, does not reveal the bottom of a (large) fully-expanded tree? I have just tried it by building a tree of my drive C. That's 24577 folders and 233693 files. The whole tree is built, I can programmatically select multiple items on it and later collect those selections, even if they are not displayed.

Edit: MSDN: Version 4.71. TVGN_LASTVISIBLE Retrieves the last expanded item in the tree.

Code: Select all

#TVGN_LASTVISIBLE = 10

Procedure TreeTop()
;------------------
Protected hwndTV.i = GadgetID(#MyTree)
Protected  hItem.i = SendMessage_(hwndTV, #TVM_GETNEXTITEM, #TVGN_ROOT, 0)

                     SendMessage_(hwndTV, #TVM_ENSUREVISIBLE, 0, hItem)
EndProcedure

Procedure TreeBtm()
;------------------
Protected    hwndTV.i = GadgetID(#MyTree)
Protected     hItem.i = SendMessage_(hwndTV, #TVM_GETNEXTITEM, #TVGN_LASTVISIBLE, 0)

                        SendMessage_(hwndTV, #TVM_ENSUREVISIBLE, 0, hItem)
EndProcedure

Perhaps not a surprise, TreeTop() works, but unfortunately TreeBtm() does not.
Anyone else encountered this issue and fixed (or fudged) it?

[JHPJHP]

I just wrote this whole thing on how it's a limitation with the MS Treeview Control, back-by some URL-links & various quotes, and ended up deleting it after performing some additional tests...

Ok this is my third rewrite I just finished writing that it was an editor issue: jaPBe vs the original one, but with further testing I've narrowed the cause, and solution / work-around.

Enable XP skin support / Enable modern theme support... -- DISABLED (under Project Options / Compiler Options):
Loop 10000 shows 638
Loop 15000 shows 5638

Enable XP skin support / Enable modern theme support... -- ENABLED (under Project Options / Compiler Options):
Loop 10000 shows 10000
Loop 15000 shows 15000
...
Loop 100000 shows 100000 (700,000 items) I wouldn't suggest testing this - took forever

Test Example:

Code: Select all

Procedure TreeBtm()
  Protected hwndTV.i = GadgetID(0)
  #TVGN_LASTVISIBLE = 10
  Protected hItem.i = SendMessage_(hwndTV, #TVM_GETNEXTITEM, #TVGN_LASTVISIBLE, 0)
  SendMessage_(hwndTV, #TVM_ENSUREVISIBLE, 0, hItem)
EndProcedure

If OpenWindow(0, 0, 0, 180, 180, "TreeGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  TreeGadget(0, 10, 10, 160, 160)
  SendMessage_(GadgetID(0), #WM_SETREDRAW, #False, 0)

  For a = 0 To 10000
    AddGadgetItem(ID, -1, "Normal Item " + Str(a), 0, 0)
    AddGadgetItem(ID, -1, "Node " + Str(a), 0, 0)
    AddGadgetItem(ID, -1, "Sub-Item 1", 0, 1)
    AddGadgetItem(ID, -1, "Sub-Item 2", 0, 1)
    AddGadgetItem(ID, -1, "Sub-Item 3", 0, 1)
    AddGadgetItem(ID, -1, "Sub-Item 4", 0, 1)
    AddGadgetItem(ID, -1, "File " + Str(a), 0, 0)
    SetGadgetItemState(0, a + 1 + b, #PB_Tree_Expanded)
    b + 6
  Next
  SendMessage_(GadgetID(0), #WM_SETREDRAW, #True, 0)
  TreeBtm()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

[IdeasVacuum]

That is good research JHPJHP, you tried things I hadn't thought of, but I have the XP Theme checked by default. I'm going to try your big test to see what happens on my machine (maybe the size of each item could also make a difference) - are you compiling ASCII or Unicode?

[JHPJHP]

Both ASCII and Unicode tests performed, but as of yesterday only in Windows 7 - 64bit...

I didn't have access to an XP box yesterday, but tested it today and the results are what I was getting without the option I mention in the pervious post being enabled.
(I compiled to exe on my Windows 7 box the 10000 node test, and all rows were viewable. Moving the exe to my XP workstation it only showed 638 nodes.)

So maybe the research I did earlier wasn't completely useless after all - this seems to be a Micro$oft-ism with earlier versions of the control, but was corrected / enhanced in later releases of Windows.

With two of the tests I performed, one with 10000 nodes, and other with 15000 - you would expect that 10000 nodes had more of a chance to display correctly, or at least they would both show the same results. [conjecture] But because of the INT16 limitation you get 638 showing for 10000 and 5638 showing for 15000. The following quote may explain it, but I put a post into the Bugs - Windows forum just in case:

http://social.msdn.microsoft.com/Forums ... 2644-items

The Nodes.Count is a signed 16-bit Integer, which means the Nodes range from -32768 to +32767...
By putting in so many Nodes, when you go past +32767, the next Node Index is -32768, then the next one is -32767, then -32766 and so on...
Your Node number is not the maximum limitation of the Treeview Control, it is the Int16 bound to the control overflowing, then counting up again from -32768.

[IdeasVacuum]

I can confirm that only 638 nodes are displayed on my XP box too. Not sure about Microsoft's logic there, why on earth did they not add a 32bit Tree before? From your Win7 x64 results, it sounds as though it's been fixed for Win7. Most of my customers however are using CAD/CAM apps and are still on WinXP x86, though there are signs of migration to Win7 x64.

From MSDN I see that the control's only enhancement of note is tree size. Makes me wonder if a Win7 32bit tree could be built on WinXP.