Perdeu o VBA ao fazer o downgrade do Excel 2013 para o Excel 2010

3

Estou no Windows 7. No passado, usava o Excel 2003. Instalei o Office 2013 e descobri que meu Office 2003 estava intacto e consegui executar as duas versões. Fiz atualizações em algumas planilhas usando o Excel 2013 e o código VBA.

Fui informado de que precisava usar o Office 2010 (não vou explicar os motivos), por isso, desinstalei o Office 2013 e instalei o Office 2010 (licenças corporativas). Quando abro as planilhas que modifiquei usando o Excel 2013 em 2010, recebo uma mensagem do Microsoft Visual Basic for Applications:

Class not registered. Looking for object with CLSID:(AC9F2F90-E877-11DE-9F68-00AA00574A4F)

Quando eu clico em Ok, recebo a mensagem do Excel

Excel found unreadable content in name_of_spreadsheet.xls. Do you want to recover the content of this workbook?

Se eu selecionar SIM, recebo uma mensagem que diz

Excel was able to open the file by repairing or removing the unreadable content. Lost Visual Basic project. Repairs were made to PivotTable report, One or more invalid conditional formats were removed from the workbook and Lost ActiveX controls.

Agora o código do VBA não foi encontrado. A pasta de trabalho é aberta e parece normal, mas os botões que executam o VBA não funcionam e, ao abrir o VBA ( Alt + F11 ), não vejo nenhum dos módulos.

Eu tentei executar o FM20.dll usando regsrv32.exe e recebi uma mensagem dizendo:

The module fm20.dll failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found".

Mas eu corri o regsrv32 do subdiretório em que o FM20.dll estava.

Presumo que meus problemas tenham a ver com a perda do projeto Visual Basic e / ou controles ActiveX.

O que preciso fazer para encontrar o código VBA que estava lá antes de remover o Excel 2013 e instalar o Excel 2010?

    
por Jeff Tolman 21.08.2013 / 00:20

3 respostas

3

Eu tive um problema semelhante. Eu usei um arquivo fm20.dll diferente de outro computador que não tinha sido "atualizado" para 2013 ainda. Registo de fm20.dll correu bem e meu problema foi embora. Parece que o arquivo fm20.dll estava corrompido. Qualquer VBA que tenha Userforms parece ser afetado. O erro do Excel 2010 que recebi foi: "As macros visuais básicas para aplicativos (VBA) para esta pasta de trabalho estão corrompidas e foram excluídas. A corrupção de macros provavelmente existe no arquivo atual. Para recuperar as macros, abra uma cópia de backup deste arquivo se você tiver um. " Um teste simples de abrir uma pasta de trabalho do VBA com apenas o código, que funcionou, e um arquivo simples com um Userform que tinha um rótulo sem código, que falhou, levou-me ao arquivo fm20.dll. Eu recebi a mesma mensagem tentando registrar o arquivo fm20.dll no sistema de problemas, dizendo que o arquivo era ruim. Copiado um novo fm20.dll de um bom sistema, o registro correu bem, o problema foi embora.

    
por 04.12.2013 / 19:28
2

O Office 2013 instala o VBA 7.1. Com ele, um versões atualizadas do FM20.dll - que por sua vez, tem uma dependência sobre os redistribuíveis VC10 - especificamente msvcr100.dll. Quando o VBA 7.1 é desinstalado - ele não remove o FM20.dll - mas o aplicativo que o acompanha provavelmente removerá o redist VC10. Quando isso acontece, FM20.dll está quebrado. Não é que seja corrupto - é apenas incompleto. (Eu rastreei isso usando a ferramenta Visual Studio, Depends.exe)

O problema é que a reinstalação de um aplicativo que usa o VBA 6.x - não substituirá essa versão mais recente do FM20.dll e, portanto, o arquivo permanecerá quebrado.

Parece que é um bug no instalador do VBA 7.1 que não limpa este arquivo. Você tem que opções alternativas. Exclua FM20.dll e repare seu aplicativo antigo - ou instale o VC10 redistribuível.

    
por 12.05.2015 / 18:40
1

Esta postagem de blog me ajudou a corrigir esse erro: link

VBA Error: Class not registered. Looking for object with CLSID:{AC9F2F90-E877-11CE-9F68-00AA00574A4F}

I know, I know, it's such an obvious error, right? I mean, really, is there anybody left in the Dynamics GP world that wouldn't scoff at you for asking about this obvious class ID?

So I recently created a new development virtual server for a new project, something I've done dozens of times without issue. But for some reason, this time I ran into a few strange problems with Dynamics GP. One of them was this VBA error:

enter image description here

This was on a fresh Windows Server 2008 x64 virtual server, SQL Server 2005 SP3, and Dynamics GP 10 FP1, with SP4 installed. I did not have Visual Studio or Office installed, which I'm pretty sure is the reason for the error.

The error occurred whenever I tried to import a user form file into VBA, or whenever I tried to insert a new user form.

I later found that this error is apparently a variant of the one described in MBS KB Article 961568:

"Errors occurred during load" or when you import a package file that has a user form: Class {C62A69F0-16DC-11CE-9E98-00AA00574A4F} of control frmXXX was not a loaded control class.

At the time, I knew that this likely meant that a DLL wasn't registered on the server, but although those lovely GUIDs are a joy to see, they convey nothing to the average human as to which DLL is not registered.

As a shortcut, I switched over to a server that I knew did not have any problems with user forms in VBA and searched the registry for that GUID. That search told me that the problem was that the FM20.dll file was not registered.

After Googling for that file name, I learned that FM20.dll is a file needed to allow VBA to work with windows forms. This lovely KB article describes it's usage, but emphasizes that FM20.dll is "NOT redistributable" (they had to make the NOT all caps and bold for those of us who were unclear and confused about the lowercase non-bold version of the word 'not'), and that it can only be obtained by installing one of several Microsoft applications that happens to distribute it.

It must have taken a team of high priced lawyers thousands of dollars of billable hours to come up with that brilliant scheme that would surely prevent someone from copying a single DLL file and manually registering it. Looking to avoid the wrath of those same summer intern legal scholars, I did not simply copy the DLL from another machine and register it on my new server. Instead, I used the link in that same KB article to download the ever-so-popular "Microsoft ActiveX Control Pad", which installs the much coveted FM20.dll for me.

(Of course, the MBS KB article says to simply copy the FM20.dll file from an MS Office CD. Skirting the rules, are we, MBS?)

And, with that, the error went away and I was able to insert user forms and import form files into my VBA project.

One note--if you are working on Windows Server 2008 x64, the 32-bit file is installed in the C:\Windows\SysWOW64 directory.

    
por 24.06.2016 / 09:20