What is this control called or found?

mor10

Member
Local time
Today, 13:22
Joined
Feb 15, 2016
Messages
37
I saw the control pictured below on an MS Access form on the web today. I have never seen one like this before or know how to include one on one of my forms. Does anyone have information where to find this control?

Screenshot 2022-07-07 103924.jpg


Is it a built-in control, or a third party control, if so from where?

Morten
 
I believe it is a Treeview?
 
I think you are looking at part of a Treeview control.
There are several threads discussing Treeview. Search the topic for more info.
See this thread.
 
I've got an idea that Treeview was discontinued or something.

However one of the members here @MajP has his own version, which, judging by the quality of @MajP 's work, will be something worth having a look at.
 
If I recall the issue correctly, UG, the original Treeview was an ActiveX control and a lot of those were eventually de-emphasized. You can still find them in ActiveX libraries but they are no longer Access "canon."
 
Yes, I found it and playing with it, I find it a little confusing to use, but it is early days.
 
I've got an idea that Treeview was discontinued or something.
Treeview is alive and well and was updated to function with 64 bit systems, so if you install Access 365, you'll get a version of MSComctlLib.ocx that works with 64 bit versions. One thing to watch out for, however, is that the .HitTest method of the Listview and Treeview controls (and perhaps others) may need an offset. Here's some code to detect and adapt to 64 and 32 bit systems, and users' machines that might have other offsets...
Code:
Public Function HitTest64(obj As Object, X As Long, Y As Long) As Object
'   Because this routine might be called multiple times during the lifetime
'   of the application, therefore we try to minimize processing done here
'   by figuring out values in advance, and saving them.
    Static K As Byte    ' this is zero on first reference
    
    If K = 0 Then       ' this block should only run once
        #If Win64 And VBA7 Then
            K = 15      ' this is the typical offset for 64-bit installactions
            If MachineName = "SomeMachineName" Then K = 10   ' this machine has unique offset
        #Else
            K = 1       ' this is the typical offset for 32-bit installations
        #End If
    End If
    
    ' Here we run the HitTest method of the object with the given offset.
    ' obj might be an MSComCtl.Listview or MSComCtl.Treeview
    Set HitTest64 = obj.HitTest(X * K, Y * K)
End Function
When the HitTest method offset is wrong, when you click an item in the List or Tree, the wrong item is selected.
Here is a sample of how you might use HitTest64 ( assumes m_tree is an object reference to a MSComctlLib.Treeview)...
Code:
Private Sub m_tree_MouseMove(ByVal Button As Integer, ByVal Shift As Integer, ByVal X As stdole.OLE_XPOS_PIXELS, ByVal Y As stdole.OLE_YPOS_PIXELS)
    Dim nd As MSComctlLib.Node
    
    Set nd = HitTest64(m_tree, X, Y)
    If Not nd Is Nothing Then
        ' do processing with selected node
    End If

End Sub
 
MarkK,
Thanks for responding. I recently saw a post by June7 in response to a poster that included a treeview control. I referenced this in post #7 above. I have O365 with Access and the database and treeview works fine. A little confusing considering many say Treeview is no longer available.
I think a lot of people (definitely me) are/were unaware of the "Treeview is alive and well and was updated to function with 64 bit systems".

Thanks again!
 
From the library name, it would appear that it was moved to the Common Controls library that includes File Dialog and Print Dialog as well as a few other familiar mechanisms.
 
@MarkK
Just a quibble about this line
Code:
   #If Win64 And VBA7 Then

64-bit systems ALWAYS run using VBA7 so you only need one or the other.
From your code, I suspect just #If Win64 is appropriate here but I've not tested it
 
From the library name, it would appear that it was moved to the Common Controls library that includes File Dialog and Print Dialog as well as a few other familiar mechanisms.
There are two different libraries.
"Microsoft Common Dialog Control" (comdlg32.ocx) contains File, Print, Font, and Color Picker Dialogs.
"Microsoft Windows Common Controls" (MsComCtl(2).ocx) contains TreeView, List View, and several other controls.
 
One thing to watch out for, however, is that the .HitTest method of the Listview and Treeview controls (and perhaps others) may need an offset. Here's some code to detect and adapt to 64 and 32 bit systems, and users' machines that might have other offsets...
That's interesting; I wasn't aware of this issue.
The factor 15 makes me think that this is a conversion from Pixel to Twips. Usually 15 Twips are one Pixel.
However, with modern high res. displays it is increasingly common that other factors than 15 are required for the conversion.
If my assumption is correct, you can determine the correct factor for the conversion by querying LOGPIXELSX with the GetDeviceCaps function. That would make that ugly, hard-coded dependency on certain computer names obsolete.
 
64-bit systems ALWAYS run using VBA7 so you only need one or the other.
From your code, I suspect just #If Win64 is appropriate here but I've not tested it
That's a fair quibble Colin, thanks. I think you are correct.
 
MarkK,
Thanks for responding.
Yeah, you bet. I was surprised when I was troubleshooting this problem that I couldn't find any references to it online. Stepping through code I could see that .HitTest was not returning the correct node. It was a heart-stopper at the time, because I've deployed a lot of Treeview and Listview controls.
 

Users who are viewing this thread

Back
Top Bottom