TreeView_DeleteAllItems problem

[BOB MECHLER]

Seems like it shouldn't even be an issue but I've found that sometimes issuing a single TreeView_DeleteAllItems(hwnd) doesn't update the treeview display that it has actually deleted all the items. I noticed this with less than 50 entries and two levels.

The TreeView_DeleteAllItems is immediately followed by filling the treeview with a different set of items. It's used as a sub menu listing of programs.

Navigating the left treeview updates upon SelectItem the contents of the right treeview. On treeviews that have more members than will fit if everything is expanded it seems to clear anything visible and most of the time the rest are visible. Once the new items for the treeview start inserting it finally goes away but in the meantime it seems like pretty annoying unnecessary scrolling and redrawing.

I've tried creating another identically sized treeview and doing shows and hides while doing two TreeView_DeleteAllItems. This trades one kind of flicker for another.

The best solution so far is two TreeView_DeleteAllItems size it to 0,0 and resize when its done redrawing the new treeview items. (still noticeable)

Anyone else know a faster way to do this or one that doesn't flicker.

Here is the definition of the treeview control. Maybe there is an equate that needs tweaking.

A faster way to load the treeviewitems might help but there aren't more than 50 items to load.

The right treeview might load and unload up to 20 times if the user uses the up and down arrow on the left treeview.

        CONTROL ADD "SysTreeView32", hdlg,%ID_TREE2, "", 196, 5, 165, 198, _
         %WS_CHILD OR %WS_TABSTOP OR %WS_VISIBLE OR %TVS_HASBUTTONS OR _
         %TVS_HASLINES OR %WS_CLIPCHILDREN OR _
         %TVS_LINESATROOT OR %TVS_SHOWSELALWAYS OR %TVS_TRACKSELECT OR _ 
         %TVS_DISABLEDRAGDROP,%WS_EX_STATICEDGE

BOB MECHLER

[Michael Mattias]

doesn't update the treeview display that it has actually deleted all the items. I noticed this with less than 50 entries and two levels.

The TreeView_DeleteAllItems is immediately followed by filling the treeview with a different set of items.

If you are processing your delete and your add in response to the same notification message, that would be the expected behavior, as the WM_PAINT generated by the change of items will not be processed until the current message processing has completed. (code not shown).

But it you want to ensure the user sees the tree in its 'empty' state before you refill it, just force a redraw of the control after the delete. (That applies to changing the contents of ANY control, not just treeviews). UpdateWindow() should handle it.

MCM

[BOB MECHLER]

Thanks,

Bob Mechler

[Michael Mattias]

What you might want to do is what I do sometimes... post yourself a message when you want the screen refreshed.
i.e instead of

 
         CASE %WM_COMMAND 
              SELECT CASE LOWRD(wPAram) 
                   CASE  %DELETE_AND_RELOAD 
                        CALL DeleteAllITems 
                        CALL Refresh__screen
                        CALL LoadNewITems 
...

you could do this...

%PWM_RELOAD  = %WM_USER + 1 
....

         CASE %WM_COMMAND 
              SELECT CASE LOWRD(wPAram) 
                  SELECT  CASE  %DELETE_AND_RELOAD 
                       CALL DeleteAllITems 
                       PostMessage  hWnd, %PWM_RELOAD, Param_Val, param_val

...   CASE %PWM_RELOAD 
         CALL LoadNewItems

...

Mostly I do this because there are times I need to "load only" (eg at startup) and I don't want to replicate the "load" code.

I guess in this case PWM_LOAD_ITEMS is almost a substitute for CALL Loaditems(), except because it's POSTed, the screen refreshes if needed before starting.

Very handy on WM_CREATE or WM_INITDIALOG... both of which are processed BEFORE the screen is ever shown. By ending your WM_CREATE or WM_INITDIALOG processing by posting a message, the user will at least be looking at a screen when the initial load occurs.

I don't know if you have ever started a program and it kind of sits there with the APPSTARTING mouse cursor (the combination pointer and small hourglass) but nothing else on the screen and wondering if the darned program is doing anything, but I sure have. At least by getting a blank or default screen in front of the user while you are doing some kind of startup task which might take a while, the user knows the program is actually doing something.

MCM

[BOB MECHLER]

Thanks, Michael. Good advice.

My actual problem had to do with what you alluded to before when I tried to take control of some of the arrow keys to skip over the level one nodes. This (feature?) that I was asked to try, wasted a day or two of my time.

After placing some judicious msgboxes, I saw that I was inadvertently causing many multiple calls to the TVN_SELCHANGED event. Eventually with all my fooling around it broke permanently. You tried to warn me.

Turns out when I was selecting the first item in the treeview (GetRoot) to make it look nice, it highlighted it in light gray. The quality assurance person didn't like that. We've compromised and now I just do a second Select with a %null parameter for the item and the highlight is removed.

              hTree2& = GetDlgItem(hdlg,%ID_TREE2)
              TreeView_Select hTree2&,TreeView_GetRoot(hTree2&),%TVGN_CARET
              TreeView_SelectItem hTree2&,0

Bob Mechler