Prevent Updating of TreeView Control

[ADezii]

I have Code in the Click() Event of a Command Button that alternately Expands and Collapses all Nodes of a TreeView Control. The Caption for this Button, as well as the Logic to not allow Recursive clicking of the Command Button is controlled by a Private, Boolean Variable declared in the Form containing the TreeView. This process of Expanding/Collapsing all TreeView Nodes is not exactly visually pleasing. Is there any Method that will not allow the updating of the Control? I guess I am sort of looking for some form of Pseudo Code similar to:

TreeView1.ScreenUpdating = False

[Peter Swinkels]

Hi adezii,

I did a google search but couldn't think of the correct search terms. Could you upload your code or animation so I can see what is going on?

[LaVolpe]

Try this...

API & constant declaration

Private Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Const WM_SETREDRAW As Long = &HB

Just before expanding/collapsing everything:

SendMessage TreeView1.hWnd, WM_SETREDRAW, 0, ByVal 0&

After expanding/collapsing everything:

SendMessage TreeView1.hWnd, WM_SETREDRAW, 1, ByVal 0&

[ADezii]

Thanks for the Reply, but the Data is actually sensitive. It is basically a TreeView Control with up to 5 Levels deep. The full programmatic expansion and collapsing of the many Nodes is not something that I want to see, it is rather annoying.

[ADezii]

Thanks LaVolpe, will definitely give this a try - knew this wasn't going to be an easy fix, but I figured it at least the TreeView Updating would at least be tolerable.

[LaVolpe]

With the treeview controls (v5 & v6) in your toolbox, v5 is definitely coded to work with that WM_SETREDRAW message. I haven't used v6 treeview in quite some time and don't know if it is also coded for that message. If so, there should be a dramatic reduction in amount of updates that are painted on the screen. If not and you are using v6, might want to consider using v5 instead? Two versions are not that similar, code-wise. v5 doesn't have all the built-in bells & whistles, i.e., exposed properties, that v6 has.

Edited. Another way to reduce the amount of updates, takes more effort. It is better, visually, but I don't think as nice as with WM_SETREDRAW and harder to implement.

- When expanding, expand from the deepest child levels to the highest parent levels. Any deeper levels not already visible are expanded without any screen updates. When their parent nodes are eventually expanded, they'll expose the already expanded child nodes.

- When collapsing, collapse the top parent nodes first, then the child nodes. Once the parent is collapsed, collapsing the children happens without screen updates.

[ADezii]

@LaVolpe:
Thanks for all of your expert advice. I ending up taking a much simpler approach, thus avoiding the API. Prior to Expanding/Collapsing all of the Nodes, I actually Hide the TreeView prior to, then Show it after Code execution. Now, instead of seeing a progressive Expanding and Collapsing of Nodes, all you see is a momentary flicker which I definitely can deal with. This approach actually worked much better than initially intended. I posted the Code for reference purposes.

'Expand all Nodes
Dim MyNode As Node

frmTree.Hide    'Hide the TreeView, do not see the expansion

For Each MyNode In Me![TreeView1].Nodes
  MyNode.Expanded = True
Next

frmTree.Show    'Show the TreeView again
  
Me![TreeView1].SetFocus
SendKeys "^{HOME}", True

'Collapse all Nodes
Dim MyNode As Node

frmTree.Hide    'Hide the TreeView, do not see the collapsing

For Each MyNode In Me![TreeView1].Nodes
  MyNode.Expanded = False
Next

frmTree.Show    'Show the TreeView again
  
Me![TreeView1].SetFocus
SendKeys "^{HOME}", True

TreeView1.Nodes(1).Expanded = True    'stubborn Node

[ADezii]

@LaVolpe:
I finally got around to you suggestion in Post# 3 pertaining to the Redrawing of a TreeView Control when Expanding/Collapsing, and it is a very smooth transition. The problem not as I see it is that it works great in a 32-bit Environment. I can assume that when porting to a 64-bit Environment, the SendMessage() API Call, with the 32-bit Declaration will crash the PC. VB6 does not appear to accept the VBA Compiler Constant. How can I then account for this in my SendMessage() Declaration. Thanks in advance.

P.S. - Just realized that I probably really confused the issue at hand, and I do apologize for that. The main question is:

What is the proper method of Declaring the SendMessage API() Function, or any API Function for that matter, in a VB6 Standard Code Module, so that it will work on both 32 and 64 bit Systems?

[LaVolpe]

Your VB compiled application always runs in a 32bit process. SendMessage, anyway, when sent from 32bit process to a 64bit process is adjusted by the O/S from what I understand.

Edited: Are you doing this from MS Office? If so, ignore my comments above.

[ADezii]

Are you doing this from MS Office?

Not sure what you mean, I am creating this App in VB6 Professional.

Your VB compiled application always runs in a 32bit process. SendMessage, anyway, when sent from 32bit process to a 64bit process is adjusted by the O/S from what I understand.

Evidently, you are correct. I created a Package and installed it on a Windows 10 (64-bit) PC and it worked with the following API Declaration. I honestly did not expect it to work.

Public Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long

I would have expected the Declaration in 64-bit to be something similar to:

Public Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As LongPtr, ByVal wMsg As Long, ByVal wParam As LongPtr, lParam As Any) As LongPtr

P.S. - I do thank you again for all of your help. As stated previously, I've been away from VB for a long time with most of my efforts working with Microsoft Access Relational DBs. Without your help, it would have taken me a lot longer to get where I am at now.