As robust as the system is, I occasionally have to dip in and add a new feature or tweak one of the existing ones.
Last week I opened up the project to add a few new interfaces and came across a rather frustrating bug – not with Visual FoxPro but with some of the ActiveX controls that I use.
I make extensive use of “Microsoft’s Common Controls” and have done for over twelve years.
I use all sorts of controls in my Visual FoxPro applications but Microsoft’s Listviews and Treeviews are so ingrained in my CRM package that most people wouldn’t recognise it as FoxPro at all.
I have a few handy subclasses of Listviews set up for use, so imagine my surprise when I drop one onto my latest form and try to add a couple of new columns, only to be told that I had entered an “Invalid Property Value”.
It was then that I noticed that the “Alignment” drop down list was empty, no default value and no contents.
Now I won’t say that this was a show-stopper. I could still add columns programmatically and the overall application didn’t seem to be affected in any way. Listviews and Treeviews still operated as expected in the live application – I just couldn’t use the Properties dialogue to change anything that required an entry from one of the drop down lists.
After the weekend there was no response on either forum so I tried a change of tack, googling instead for Microsoft updates that may have affected MSCOMCTL.OCX (one of the physical files that provide Microsoft’s Common Controls Library).
As it happens, I haven’t edited any of my Visual FoxPro applications for a good couple of months. Most functionality is held in SQL Server 2008 and new features tend to be held back for inclusion in new web based applications.
There was a security update, released August 14th 2012, MS12-060. Apparently, a vulnerability in Windows Common Controls could allow remote code execution.
Microsoft have released fixes themselves:
But, to be fair, I used the manual fix without any problems. A couple of sources suggested this and it worked a treat for me.
- Unregister your mscomctl.ocx from wherever yours is kept (System32 or SysWOW64).
- Rename your current version to something temporary.
- Copy an older version to the same folder.
- Register it.
- Unregister it.
- Rename the copy of the older version (or delete it).
- Rename the original to mscomctl.ocx.
- Register it one final time.
I’ve also created a batch file to do this on my client PCs, in case they do start to have issues with the various Lists and Trees used in the platform.