Tree View Issue (Access 97)

Topic

New Reply

Hi,
I have an application that is developed in access 97 and uses the runtime version when I put it at a customers site. It is a marketing tool and people can do selections on their data and save these selections in the sqlserver database behind the access front end. These selections are displayed in tree views and work on over a hundred pc’s except at one customers site. I works fine on the server (which is windows 2000), but not on the desktops (which are XP professional with SP1). The issue is that when they open our program and try to view their selections in the tree view it is blank, if they go ino another tab in the application and then back to the selection tab the tree view is now populated. I have unregistered and re-registered a new mscomctl.ocx and this has made no difference. I have set up multiple test machines with XP on and cannot replicate the error. I have attached a zip of the screen shots to show what is happening. I hope someone can help me here

Many thanks,
Paul.

Reply | Quote

Replies

Since the TreeView does get populated after switching to another tab page and back, the Treeview control (in MSComCtl.ocx) does not seem to be the problem.

To make Access 97 work correctly on Windows XP, you must make sure that the latest updates for Office 97 and for Jet Engine 3.5 have been installed. Visit the Microsoft support site to get these if necessary.

Reply | Quote

(Edited by HansV on 25-Apr-03 10:41. attached picture was very large; cropped to show relevant portion only.)

No, no! This is exactly the same issue I am having! If you look closely at the treeview in the first picture Paul posted, the control has actually fallen out of it’s frame! I believe it’s due to being on tab controls. (Although you can’t see it, mine is on a hidden tab control). I’m using Access XP SP2 – does anyone know if Microsoft have a fix for this problem? I’ve scoured the MSDN and Technet sites for weeks… This does seem to be an issue only with the newer versions of mscomctl, as I don’t remember it happening in my system before I converted to XP.

I think we’re either going to have to revert to an older version of the OCX, or not use tabs (switch visibility in the foreground).

Regards,
Tim

Reply | Quote

If the Treeview or any subform or other control is too large to fit completely into the tab page when fully expanded then you will run into this behavior. Tab pages are a fixed size, so objects that are too large to fit completely on the page get shifted around and only partially displayed. There is no “fix” for this because it is normal and expected behavior for a tab control. Tabs are just a means of displaying only selected objects and hiding others, they are not intelligent controls.

Reply | Quote

Thanks Charlotte, I understand that if you expand the nodes then you’ll need to scroll to see everything in the treeview, but what’s happening here is that the treeview control itself is falling out of it’s “shell”, and appearing in the absolute top-left of the screen. This only happens after manipulating (adding nodes, removing nodes) during runtime, but even in design mode when I double click it to check it’s properties, it shifts to the top left (see picture). It’s really odd behaviour – I swear it wasn’t happening in the old versions of MSCOMCTL. It’s also happening with my listview. I’m running MSCOMCTL.OCX version 6.0.88.77, and this behaviour is happening in both Win2K and WinXP (both running Access XP).

Reply | Quote

I’m not sure where you got the version of MSCOMCTL.OCX – I’m running Office XP SP2 and I have version 6.0.81.77 – I have a pretty vanilla install with no extra apps or anything like .NET. You might try reverting to the earlier version and see if that fixes your problem. We routinely had problems with different versions of MSCOMCTL and it’s predecessor COMCTL32 and finally began using a third party control that doesn’t have umpteen versions floating around.

Reply | Quote

FWIW, I see the same behavior in Access 2002 (SP2) on Windows XP Home (SP1), and not only in conjunction with a tab control. The version of Mscomctl.ocx on my PC is 6.1.95.45; it came pre-installed on my PC (Dell, January 2003).

Reply | Quote

Thanks guys, I’ll try an earlier version (I’m going to try a few other tricks too, now that I know there’s no easy fix – will post my findings here) – can you recommend a good 3rd party treeview and listview control?

Reply | Quote

We’ve had good luck with the OCX controls from DBI Technologies. In particular, their treeview works on a rather different principle than the Microsoft one, but it loads and unloads much quicker, particularly if you are working with a nested treeview. We normally use the MS listbox, as we don’t seem to have any problems with it.

Reply | Quote

Thanks so much for your help guys. I am convinced now that there’s no bugfix for this, and that it’s either a work-around or use-a-different-product issue. However, for future generations, I will document my findings (and a rather nasty, but useable, workaround) here:
It seems to happen only on tab controls that don’t currently have the focus — you can do whatever you want if the treeview(s) are on the screen at the time of manipulation. This has also happened to me with listviews.
However, if you change to the tab, and it’s corrupt, you can switch to another tab and come back again and it should be right.

Now, for the nasty workaround: as switching tabs seems to correct the problem, when a tab is clicked you need to fire some code to switch off the tab and back on. Something along the lines of

‘to ensure the treeviews display properly
If tabWizard = 1 Then
DoCmd.Echo False
tabWizard.Pages(0).SetFocus
tabWizard.Pages(1).SetFocus
DoCmd.Echo True
End If

Thanks again guys,
Tim

Reply | Quote

Hi guys I’ve been off sick for a while so haven’t been able to try the fixes suggested. In the end I unregistered the mscomctl.ocx and registered an older version and this worked fine. But I will need to apply the workaround detailed so that I do not have this problem in the future.

Many thanks,
Paul

Reply | Quote