Ошибка could not load an object because it is not available on this machine

Ошибка «Could not load an object because it is not avilable on this machine» при вызове любого пункта меню программы «АТТЕСТАЦИЯ-5.1» в большинстве случаев возникает из-за не корректно установленного компонента MSCAL.ocx.

1. Для диагностики данной проблемы необходимо выполнить вызов календаря в любом протоколе (создать любой протокол и нажать кнопку «Дата оценки» на панели инструментов). Если календарь не откроется, тогда необходимо выполнить действия, описанные в пункте 2.

2. Установка компонента:
2.1. Закрыть все программы.
2.2. Перейти в каталог установки программы «Аттестация-5.1» ( «C:Program Files..Аттестация-5.1»).
2.3. Запустить файл mscal_update.exe (с правами администратора), как показано на рисунке.
2.4. Пройти установку файла обновления.

Далее, запустите программу и проверьте вызов календаря (п.1).

3. Если проблема не решится с использованием данного материала, необходимо отправить диагностическую информацию на адрес att_support@mail.ru.

Для получения диагностической информации необходимо перейти в каталог установки программы «Аттестация» ( «C:Program Files..Аттестация-5.1»)и запустить файл diag_att_ctls5.exe.

Признак корректной установки компонентов:

Test 1: execute code 101
Test 2: execute code 201
Test 3: execute code 301
Test 4: execute code 401
Test 5: execute code 501
Test 6: execute code 601

Если коды по какому-либо тесту отличаются, значит существует проблема в установке компонентов.

4. Дополнение: Было зафиксировано несколько случаев проявления данной ошибки из-за блокировки установки компонентов программы во время инсталляции дистрибутива (setup.exe). В связи с этим, если проблема не решится с использованием рекомендаций по п.2 необходимо выполнить повторную установку дистрибутива (setup.exe) в режиме отключенного антивирусного ПО и повторно отправить/проверить результаты диагностики по п.3.

5. На рисунке изображен файл с именем «mscal_update.exe», на другой системе расширение «.exe» может не отображаться. В этом случае имя файла будет «mscal_update».

We are using a set of Excel files on several machines in our company. These files contain a VBA application which utilizes a couple of ActiveX control objects from mscomct2.ocx library (namely, MonthView and DateTimePicker). ActiveX objects are to be displayed in UserForm. Unfortunately the portability of these files seems limited in a very peculiar way.

There appears to be 2 groups of machines:

• Group A: I can create a Excel file containing MonthView on such machine and work with it on any Group A PC. But when I try to open this file on any machine from Group B, I’m getting a Could not load an object because it is not available on this machine error. However, files with the same ActiveX created on Group B machines work normaly on A machines.
• Group B: File with an ActiveX in question created on these machines work everywhere (i.e. on any A and B machine). But, as I said earlier, B machines give the error mentioned above when the file with ActiveX saved on A machine is opened.

In one sentence: files created on A machine work only on other A’s, files created on B’s work everywhere!

The strangest thing here is that every machine has mscomct2.ocx registered (once again: I can create the form with the MonthView on any machine in question!). The .ocx itself is in place on each machine and the whole set of registry keys is present (CLSIDs for controls classes, IIDs, typelib ID…). In addition, the data in these registry keys seem to be the same on A and B group machines (GUIDs, ProgIDs, versions etc.). There are slight differences in description strings (values like «Microsoft MonthView Control 6.0 (SP6)») on some machines but this does not seem to affect the situation (some machines in B group have such descriptions different but files created on them still work everywhere).

Naturally, thanks to Murphy’s law, the machine I use to edit these Excel files belongs to Group A, so files saved here are ‘unportable’ to B machines…

The OS and Excel versions don’t seem to affect the situation. For example, one of B machines is working under Win 7 64 bit (Excel 2007), while most others group A and B machines are Win XP Prof (32 bit) SP3, with Excel 2003 installed. So it seems that OS and Excel versions don’t affect compatibility and the problem is somehow connected with ActiveX.

The only ActiveX-related difference between A and B groups I found is the file version of mscomct2.ocx: at least several of A machines have version 6.1.x.x, while Group B has 6.0.x.x. I don’t see how can such difference cause problems (ActiveX are COM objects after all, and according to registry key values, the exposed typelib, com objects and interfaces seem to be the same in all cases). Nevertheless I tried to replace my 6.1.x.x ocx with 6.0.x.x version… and ran into more trouble. What I did is:

1. regsvr32 /u mscomct2.ocx — completed successfully
2. Replaced the mscomct2.ocx with file of 6.0.x.x version
3. regsvr32 mscomct2.ocx — completed successfully

After these steps I tried to make an Excel file with single form containing the MonthView. But when I tried to place a control in the form I’ve got a messagebox with error Class not registered. This is really strange cause everything seem to be registered: the control class, its interfaces, typelib (yes, I’ve checked the registry to be sure). But still the error was there.

After that I did the unregister/replace/register procedure again to go back to my original 6.1.x.x file. That took me back to the original SNAFU situation: I could again install ActiveX to user form and use it, but the Group B machines still gave the error on files saved by my machine.

I assume that the problem of files-with-ActiveX portability and the problem of ocx registration are somehow connected, but I don’t see how. Perhaps there are some additional requirements for registration of an ActiveX in Excel VBA which I don’t know…

The only thing I need is to have the ActiveX object contaned in my Excel file compatible with other machines. Can anyone help me with that?