Treeview nodeClick doesn't fire when clicked

[argonautical]

We are using the treeview common control in an MS Access form. I've encountered a situation with a user where when he clicks a node in the tree, the nodeclick() event does not fire, yet the tree is still fully navigable. He can open and close all the branches, but the background code that picks up the nodeclick() just doesn't fire. However we have buttons on the screen that, thru code, find the next node and "click" it through VBA. That works fine and the resulting nodeclick() code does fire in that case, just not when the user uses the mouse to click it.

I'm struggling for how to even begin troubleshooting this. It's one thing to have an error happen that I can trace thru, but when something doesn't happen and no event is triggered, how might I track down where the failure is? BTW, this is a Windows XP/Office 2007 PC.

BACKGROUND:
We were hit hard by the MS12-060 patch issue as documented in the following KB: http://support.microsoft.com/kb/2748410
We're still dealing with users that are opening the database for the first time since August and discover it won't work. In troubleshooting the problem, another administrator did "something" to the PC. Unfortunately I don't know what they did but I do know it had to do with the MSCOMCTL.OCX library, which is the exact same library the treeview comes from. I've confirmed the filesize/date and it is still the correct common controls library version. Otherwise the entire database is functional and working fine.

Any ideas?

[NeoPa]

Has the setting to trust add-ins been reset by any chance? A2007 makes security very complicated to manage sensibly, and this is one issue that might cause such symptoms.

[argonautical]

hmm, that's a good one to look for, thanks. I'll check so see if it is different on that PC than the others.

[TheSmileyCoder]

Try putting the following in a .bat file and run it from the users pc:

reg delete hkcr\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 /f
 
if exist %systemroot%\SysWOW64\cscript.exe goto 64 
 
%systemroot%\system32\regsvr32 /u /s mscomctl.ocx 
 
%systemroot%\system32\regsvr32 /s mscomctl.ocx
 
exit
 
 
:64 
 
%systemroot%\sysWOW64\regsvr32 /u /s mscomctl.ocx
 
%systemroot%\sysWOW64\regsvr32 /s mscomctl.ocx
 
exit

I have also attached the file (rename it from .txt to .bat)

[TheSmileyCoder]

I have had many users have the problem with the MS patch, and one thing I noticed is that it seems to hit in very in-consitent ways. On some PCs the treeview was partly functional, on others no funtionality at all, the db wouldn't even open.

[argonautical]

Thanks TheSmileyCoder. We've experienced and seen the exact same behavior. I has already removed the problematic registry key and registered and unregistered the library. That's the process that has worked consistently (luckily) for over a hundred users, and as soon as I did that, this guy's database did stop toss out errors. However this is the first time we've seen that the errors stopped, yet part of the treeview control just plain doesn't work. Like I said, everything appears to be working fine and as designed except for the nodeclick. Having a tough time running it down.

NeoPa, I did confirm the add-in trust settings and they are still set the same as mine (yet my PC doesn't exhibit the behavior), so I think it must be something else.

Unfortunately I'm not allowed to have admin access to the PC because we're in a huge enterprise environment. I'm strongly suspicious that an administrator did something on their own prior to me giving them the instructions for how to fix the MS12-060 patch issue. So once we had them patch it correctly the known errors went away but this missing nodeclick event remains.

[TheSmileyCoder]

OK
I presume you have allready tried hitting up the user with a new frontend?

Access 2010 has a new tab specific for Active x security settings. I don't know if Access 2007 has this as well, and I have never had the need to look in it, but may be worth a shot.

[argonautical]

Yep, put an entirely new copy of the database on their PC and that copy exhibits the same behavior. And if I move their problematic DB to my PC it doesn't act that way. So I'm confident it is isolated to his PC and is not something internal to that actual MDB file.

Thanks for the pointer about ActiveX security. From what I know that's all controlled via group policy and not directly in Access so it'll take some time for me to get someone to do that for me. But have you ever seen a setting like that only disable part of a control's behavior? The treeview control works perfectly in every other use, just not the nodeclick. I would think that if it was a security setting being disabled, it'd be breaking the whole thing rather than just one event. Does that sound logical or am I overthinking it?

[TheSmileyCoder]

It does sound logical. But just like you I am perplexed, and to be honest shooting in the dark. Do you have other treeview events that work as intended when triggered by the user and not by code?

Is it both keyboard and mouse input that fails to trigger the nodeclick event? Can the mousedown/mouseup be triggered?

[argonautical]

Thank you! Yes, other events do work fine from the GUI side, but I had my head down so much I didn't think to put in new event triggers to confirm all events are actually showing up in VBA. I'll work in that direction and see what I can find. Thanks again for the suggestion, hopefully that'll pan out.

[NeoPa]

Good work between you guys. I would simply add that it is worth looking through all the security settings, rather than just the Add-In one I referred to earlier. Make sure it trusts the VBA project etc. I'm sure you already have, but it doesn't hurt to have it documented in the thread. Others my find their way here in future and need more details spelled out ;-)

Argonautical:
From what I know that's all controlled via group policy and not directly in Access so ...

Group Policy covers various things across a Domain including Users, Servers, PCs etc. It is another level of control, but it is still controlling the same items that are already present in the Users, Servers & PCs. This means that direct control in Access is not incompatible with Group Policy control. Both can, and do, pertain to the same settings on your PC. However, in many cases it is possible for GP settings to be mandatory and thus unable to be changed except via GP. What I am trying to say is that it isn't true to say that using GP necessarily precludes the normal interface, but sometimes it can of course.

[argonautical]

Great point NeoPa. I was thinking that some of the ActiveX and other security controls were only accessible through GP in Access 2007/WinXP. I guess that may not be the case, but either way you make a valued point for anyone following up on this issue. Thanks!

[NeoPa]

Glad to help where I can :-)

If you do find any settings within Access that are exclusively controlled by GP then you will know because trying to change/set them will result in a message informing you that the particular setting is under the control of the GP and you need to speak to your administrator if you want it changed. I don't have an example to hand, so can't post the exact message, but it isn't ambiguous. You'll know.