Português |
English and Others |
DECOMPILADOR E COMPACTADOR DE
|
|||
Este utilitário Decompila e Compacta código do Microsoft® Visual Basic® for Application (VBA) salvo pelo Microsoft Access®, Excel®, PowerPoint® ou Word, reduzindo o tamanho do arquivo e a probabilidade de conflito de compilação entre diferentes versões do Microsoft® Office enquanto limpa também lixo de compilação acumulado durante a fase de projeto que freqûentemente geram erros e lentidão na carga. É um limpador de código VBA em qualquer tipo de arquivo do Access, Excel, PowerPoint ou Word. Útil para desenvolvedores usarem antes da distribuição dos arquivos e também para usuários finais que experimentarem problemas ao carregar projetos VBA de terceiros, pois o VBADecompiler pode limpar estes projetos sem desproteger o projeto VBA e sem invalidar assinatura de código a partir do arquivo fechado no disco e aberto em um ambiente do aplicativo livre da influência de suplementos de aplicativo, suplementos de COM e outros projetos pré-instalados. Itens a seguir nesta página: O que significa decompilar e compactar em VBA Vantagem de salvar código VBA decompilado e compactado Boas práticas para aumentar a estabilidade de códigos em VBA Novo Office 2007 e posteriores (32 e 64-bit) Executando via Linha de Comando Características:- Decompila e compacta o projeto VBA salvo em qualquer tipo de arquivo do Access, Excel, PowerPoint e do Word, inclusive add-ins; - Decompila e compacta projeto VBA protegido por senha sem desprotegê-lo e sem invalidar assinatura de código; - Decompila e compacta (limpa) código VBA em módulos Padrão e em qualquer módulo de Classe, inclusive módulos por trás de objetos de Formulário, Planilha, Pasta de Trabalho, Slide e Documento; - O arquivo decompilado e compactado é salvo de acordo com a versão padrão instalada do aplicativo, mas, se houver mais de uma versão instalada, uma outra pode ser indicada; - Pode, opcionalmente, manter a data e a hora do arquivo original; - Cria um backup do arquivo original e, opcionalmente, sem subscrever o backup anterior; - Pode, opcionalmente, registrar a atividade em um arquivo de log; - Não requer instalação; - Este utilitário consiste de um único arquivo executável que usa a biblioteca do Office instalado, nenhuma biblioteca ou configuração extra é necessária; - O utilitário não altera a configuração de qualquer outro aplicativo. Ele não ocupa a memória do Access, nem do Excel, nem do PowerPoint e nem do Word como add-ins e COM add-ins fazem; - Salva automaticamente á última configuração para ser usada como padrão na próxima execução. Todas as opções, inclusive o path da pasta, são salvas em um arquivo INI criado próximo ao arquivo VBADecompiler.exe ou, quando não for possível, na pasta temp do Microsoft® Windows®; - A decompilação e compactação podem ser executadas a partir da interface gráfica do utilitário ou silenciosamente a partir de linha de comando. A linha de comando suporta todas as mesmas opções da interface gráfica do utilitário; - Você pode gerar linha de comando completa a partir da interface do usuário e transferir para Àrea de Transferência do Windows para ser colado em qualquer lugar, tal como no argumento da função Shell de um código VB ou VBA, em um atalho do Windows ou na caixa de diálogo do comando Executar do Windows. Veja exemplos no item Executando via Linha de Comando abaixo. Download:Testado em biblioteca instalada do Office para Windows, versões 2002(XP), 2003, 2007, 2010 (32 e 64-bit), 2013 (32 e 64-bit), 2016 (32 e 64-bit) e 2019 (32 e 64-bit) em instalações MSI-based e Click-To-Run do Office 365™ de serviços baseados na nuvem.
O Que Significa Decompilar e Compactar em VBAEm outras linguagens de programação, decompilar normalmente significa reverter um código compilado para o seu código fonte. Em VBA ele tem um significado diferente. Para tentar entender, vejamos, sem muitos detalhes, como funciona a compilação no VBA. Entre o texto legível por humano digitado no VBE e o código binário nativo (específico para a CPU na qual o código é executado) podemos identificar pelo menos quatro estados de código (E1, E2, E3 e E4) e três compilações (C1, C2 e C3) como mostrado abaixo. Exceto no primeiro estado, todos os estados de código são binários. O código no estado E1, texto, só existe enquanto é visualizado no VBE. Cada vez que a tecla Enter é pressionada, depois de digitar uma linha de código, o texto nela é imediatamente compilado a nível de VBE para o estado E2, Op-code. Op-code permanece na memória e é armazenado permanentemente no arquivo ao salvar. O Op-code no estado E2 é compilado para o estado E3, P-code/Ex-code, em nível de VBA, quando o comando Run (F5) ou o menu Debug/Compilar é executado. P-code/Ex-code também permanece na memória e pode ser armazenado no arquivo. O compilado P-code é serializado na memória em adição ao Op-code e isto é chamado de Ex-code. O código no estado E3, P-code/Ex-code, é compilado para o estado E4, Native code, a nível de sistema operacional, ao executar o comando Run (F5), mas não permanece na memória e nem é salvo no disco. A primeira compilação, C1, é bidirecional. O texto é convertido imediatamente em Op-code ao ser digitado como mencionado acima e o Op-code é temporariamente convertido a texto no vôo enquanto é visualizado na janela do VBE. A segunda compilação, C2, de Op-code para P-code/Ex-code, é a compilação do VBA que nos interessa aqui. Diferentemente de outras linguagens, onde o código original e o código compilado são salvos em arquivos distintos, aqui todo o código persistente é salvo em um mesmo arquivo. Além disso, P-code/Ex-code não é estático, quando um novo código é digitado no VBE ou quando objetos são inseridos ou alterados, P-code/Ex-code será decompilado (ignorado) e não será substituído até o projeto ser executado (F5) ou compilado (menu Depurar > Compilar). Ao rodar um projeto VBA, se o interpretador do VBA encontrar código compilado em um arquivo que não corresponda ao ambiente no qual está rodando no momento, uma versão do aplicativo diferente por exemplo, o VBA decompila também para recompilar no vôo adaptando-o às novas condições. Ao decompilar, o código compilado não é removido imediatamente da memória e nem do disco, ele vai ser substituído à medida que o código for sendo executado. Por exemplo, se em um projeto houver 50 Subs em vários módulos e apenas o Sub1, que chama o Sub15, for chamado, então apenas estes Subs tem os respectivos códigos compilados substituídos por novos na opção padrão Compilar ao ser solicitado. Ao decompilar, o código decompilado a ser substituído pode ser removido da memória e do disco para compactar o projeto. Isto reduz o tamanho do arquivo e, portanto faz o arquivo carregar mais rápido. Infelizmente, o VBA não fará isso automaticamente embora permita que isto seja feito. E é isso que este utilitário faz; ele decompila e compacta projeto VBA salvo no disco pelo Access, Excel, PowerPoint ou o Word. Na verdade, é um limpador de código VBA. Entre os aplicativos do Office, só o Access foi provido pela Microsoft com o argumento de linha de comando ‘/decompile’. Este argumento ainda não está formalmente documentado, mas há muitos artigos na Web sobre sua utilidade. Veja, por exemplo: http://support.microsoft.com/kb/819780/pt-br http://support.microsoft.com/kb/814858/en-us http://support.microsoft.com/kb/279334/pt-br http://www.microsoft.com/technet/archive/office/office97... http://www.granite.ab.ca/access/decompile.htm Vantagem de Salvar Código VBA Decompilado e CompactadoSalvar compilado ou salvar decompilado e compactado: qual o melhor? A priori, a vantagem de salvar compilado é que ele possibilita uma melhor performance ao rodar. Sem a necessidade de compilar, a execução começa imediatamente. Isto era verdade quando os computadores tinham velocidade de clock de 150 MHz, mas hoje, com a velocidade comum de 2500 MHz de clock e com aumento insignificante na velocidade de leitura de disco, compilar é extremamente mais rápido do que ler o projeto com o dobro do tamanho a partir do disco. E porque o VBA só compila código à medida que ele é chamado pelo aplicativo, a performance é aumentada. Quando um projeto se destina a rodar em diferentes versões do aplicativo, não há nenhuma vantagem em compilar o código, porque ele será decompilado se a versão na qual ele for rodar for diferente da versão que o compilou. Nestas circunstâncias, código compilado pode apenas causar erros e lentidão ao carregar. Um projeto decompilado e compactado também resulta em arquivos significativamente menores, facilitando a distribuição. Por exemplo, para testar este utilitário, decompile e compacte o arquivo ATPVBAEN.XLA que vem com o Office. Você verá que protegido e instalado ou não, seu tamanho será reduzido em cerca de 67 %. Conclusão: Se um projeto for para ser sempre carregado pela própria versão que o salvou, não faz muita diferença entre as duas opções. Mas, se o projeto for para ser carregado por diferentes versões do Office, é altamente recomendado que seja salvo em estado decompilado e compactado. Boas Práticas para Aumentar a Estabilidade de Códigos em VBAEm minha experiência, as seguintes quatro práticas ajudarão a criar códigos mais estáveis quando rodando em deferentes versões do aplicativo (buids, línguas, OS etc.): 1) Salvar projetos decompilado e compactado; 2) Evitar referenciar projetos VBA. Melhor carregá-los com o método Open, usar o método Run e talvez descarregá-los imediatamente com o método Close; 3) Evitar o método ‘early binding’ para referenciar um objeto em Automação toda vez que for possível. Use-o durante a fase de projeto, mas altere para o método ‘late binding’ antes de distribuir o aplicativo. Tenho programado em VBA desde que ele foi incluído pela primeira vez no Office. À medida que o tempo passou e os clientes começaram a usar deferentes versões do Office, comecei a experimentar problemas durante o processo de carga de projeto VBA. Uma vez que adotei as três práticas acima estes problemas foram quase eliminados. 4) Evitar muito código diretamente no evento open, o melhor é transferir todo o código necessário para um Sub em módulo standard e então chamá-lo de lá. No Excel, por exemplo, ficaria assim: E ainda fica mais estável se usar o método OnTime, assim: Tenho experimentado instabilidade em código no evento open especialmente no Excel 2003 e no Word 2003 e mais recentes. Novo Office 2007 e posteriores (32 e 64-bit)A priori, todas as considerações acima continuam válidas em projetos VBA salvos nos novos formatos de arquivo zipado do Office 2007 e posteriores (32 e 64-bit). Apenas a taxa de redução no tamanho final do arquivo no disco pode parecer menor devido à compressão zip, mas internamente a taxa de redução continua semelhante aos formatos de arquivo das versões anteriores do Office, significando agora, além de menos dados para carregar, menos dados para descomprimir. Executando via Linha de Comando:A decompilação e compactação podem ser executadas a partir da interface gráfica do utilitário ou silenciosamente a partir de linha de comando. A linha de comando suporta todas as opções da interface gráfica do utilitário. Você pode gerar linha de comando completa a partir da interface do usuário e transferir para Àrea de Transferência do Windows para ser colado em qualquer lugar. A decompilação via linha de comando é útil para você automatizar suas decompilações, por exemplo, você pode: 1 - Criar um atalho no Windows para decompilar um projeto com apenas dois cliques
Supondo que você queira criar um atalho na área de trabalho do
Windows (pode ser em qualquer pasta) para decompilar seu projeto
VBA em SeuApp.xls, então: 2 - Fazer seu projeto VBA auto decompilável através de um evento BeforeClose Antes de fechar, seu projeto pode chamar o VBADecompiler.exe que espera o arquivo do projeto ser liberado para então iniciar a decompilação. Você pode definir condições para a chamada. No código a baixo, o projeto VBA será decompilado ao fechar desde que tenha algo por salvar: 3 - Criar seu gerenciador de decompilação em bat, vbscript, VBA etc.; O código VBA abaixo decompila todos os arquivos XLs na pasta indicada.
|
|||
|