Thanks for sharing your detailed trouble-shooting.

At one point I had done some heavy engineering of the C:\Windows\System32 directory, with respect to the ref edit library. There were different versions of this file, with different dates and different file sizes. For a while if I replaced whatever was there with the version that came with 2003, all was cool. But then this became unreliable, and I was forced to remove the RefEdits from my dialogs.

I implemented an Alternative to Excel’s Flaky RefEdit Control which used text boxes and the InputBox function to get the user-selected range. But this is not as nice as the RefEdit, when the RefEdit works.

It seems that the RefEdit has stabilized after a number of 2007 and 2010 updates, so I have found a New RefEdit Approach that adds RefEdits on the fly when the dialog loads; if there’s an error, the RefEdit couldn’t load and wouldn’t work anyway, so I revert to the kludgey textbox/InputBox approach. This will roll out with my new utilities later this year.

I have been designing an Excel application that utilizes a very, very heavy userform, replete with 8 different tabs probably 100+ controls (many of which are added dynamically at runtime, depending on user input). The only controls i’m using at the moment are the default Microsoft Forms 2.0, the reason being that they are free (albeit a little antiquated). I’m developing in Excel 2003, but also testing simultaneously in 07 and 10.

I have faced the frustrating issue not with RefEdit but with ListBox instead, when setting the RowSource property. Unspecified error, cannot set rowsource property. It’s a similar problem, with the memory issue every now and then. I have NEVER been unable to solve an issue faced while coding VBA applications, usually because someone posts about it with a resolution. But for the longest time this one eluded me. My application was unable to set the rowsource with a named range even after clearing the list, and it returned this error without any explanation.

I have solved the problem for my particular case.

What I attempted is a risk, because I am altering files in the C:\Windows\System32 directory on which the Office programs depend for functioning. But it worked for me. I’m operating on Win XP Professional, using MS Office 2003 AND 2010 installed on the same system.

There are two files of interest in that directory. One is called “FM20.DLL” and the other “FM20ENU.DLL”. I would assume the latter file is an English-only version, and may not exist in others’ systems. My contention is that MS screwed up these files somehow when they published the newer versions of Office. Don’t ask me how, or why, or what exactly these files do. To my judgment, they are the setup/config files for all of the default userform controls used by VBA userforms. Probably set the memory allocation for them.

Anyway, I found that when I had Excel 07 and 10 installed on the system, even if I was using 2003, the application would fail when trying to set the row source property. I took the following steps to resolve:

1. I uninstalled all office versions. Rebooted.

2. I re-installed 2003 and took a look in the System32 folder, and noticed that these files were last modified in 2010, meaning that they remained left over from the Office 10 installation.

3. I copied these files to the desktop only for back-up purposes.

4. I deleted these two files. Excel should be closed.

5. I opened up MS Excel 2003, and it greeted me with an installation screen before fully opening up. It installed something successfully.

6. I opened up the C\Windows\System32 directory and looked for those two files. They had a date modified of 2007. Good news. Vintage.

7. I copied them to a separate folder in my desktop for back-up.

8. I installed Office 10 and looked again and saw that the two files had a date modified of 2010. I replaced these files with the backups of the 2007 files (which were installed by 2003).

I now have no issues with unspecified errors in my userforms. At your own risk, perhaps give that a try. Worked for me for a similar issue.

Apparently the VBA developer used a special control which is not part of the Office VBA package but instead came from Visual Studio. This can be done, of course, but different installations may store the VS components in different places. So again, the problem is a dialog (UserForm) using a control that VBA can’t find or can’t implement.

Fortunately you were able to find the component and fix the problem.

I am no VBA expert but had this “painful” error occurring on one computer belonging to an user working in my company.

She needed to generate report from a macro workbook.

I could isolate the issue when I tried to run the modules one by one. I could pop this error message very easily when I tried to run an “UserForm” from the VBA project.

This UserForm is called when they click on a button in the spreadsheet after they filled the criteria they need. It launches a “ComboBox” in which are reported the criteria they previously written in the cells.

I followed this solution :
In the VBA editor, stop the VBA Project then open Tools>References and Browse for a *.ocx ==> C:\windows\system32\mscomct2.ocx

Then save the file.

The error message no longer popped to our sad faces…

Maybe this is irrelevant for you now but thought nice to let a comment on this.

1) COM add-ins. Adobe and BlueTooth sneak into Excel. Others are third party trial add-ins. As far as I can tell, any COM add-in is bad news.

2) Trying to run Office and windows 7 with just 2 gig of memory. 4 gig is marginal. 8 is nice.

3) Running 64 bit Excel and any other Office application at the same time. Three instances.

Another frustrating Microsoft Moment. Glad you figured it out in time to answer a flurry of frantic phone calls from your users.