Propósito

✔ Programação GLOBAL® - Quaisquer soluções e/ou desenvolvimento de aplicações pessoais, ou da empresa, que não constem neste Blog devem ser tratados como consultoria freelance. Queiram contatar-nos: brazilsalesforceeffectiveness@gmail.com | ESTE BLOG NÃO SE RESPONSABILIZA POR QUAISQUER DANOS PROVENIENTES DO USO DOS CÓDIGOS AQUI POSTADOS EM APLICAÇÕES PESSOAIS OU DE TERCEIROS.

.: Vitrine

Carregando artigos...

Views

Mostrando postagens com marcador Object Model. Mostrar todas as postagens
Mostrando postagens com marcador Object Model. Mostrar todas as postagens

VBA Excel Série - 02 - VBA ou MACROS

Muitos dizem que o VBA é o controle remoto do Excel. Se isso for verdade, então o que são as Macros ?


Quando a Microsoft divulgou "Ei ! Agora podem automatizar as suas tarefas simples e repetitivas, escrevendo programas personalizados com base nas funções das planilhas", isso pareceu assustador para alguns.

Assim que a equipe do Excel continuou a referir-se aos programas personalizados como macros. A palavra macro passou a significar um programa que os usuários podem escrever por si mesmos.

As Macros baseadas em função do início do Excel foram uma grande melhoria sobre o modelo inicial, onde as macros eram compostas por combinações de teclas. Mas realmente ainda tinham dois grandes inconvenientes para superar.

Primeiro, as macros do Excel eram muito específicas para o Excel - as funções pareciam-se muito com as fórmulas das planilha, sendo incapazes de se adaptar a outros aplicativos da suíte Microsoft Office, como o Word

Em segundo lugar, o número de funções aumentava a cada nova versão do Microsoft Office, e não havia, até o momento, nenhuma boa maneira de organizar ou agrupar as milhares de possibilidades.




Resolvendo a primeira limitação...

Para resolver a primeira das limitações das macros baseadas em funções específicas para o Excel, o pessoal de Redmond introduziu o VBA ou Visual Basic for Applications, começando no Microsoft Excel versão 5.

VBA funcionaria como uma linguagem de uso geral independente da aplicação. De repente, alguém que soubesse como trabalhar com qualquer versão do Microsoft Visual Basic teria uma grande vantagem para automatizar o MS Excel, e qualquer pessoa que aprendesse a escrever macros VBA no Excel transferiria esse conhecimento para outros tipos de programação Visual Basic. Além disso, embora o Excel fosse o primeiro grande aplicativo a usar o VBA, este não estava ligado diretamente a ele, Funcionaria muito bem com outras aplicações habilitadas para o VBA, como o Word e o Microsoft Office PowerPoint. E como pudemos constatar depois, até mesmo em aplicações fora suíte MS Office, e mesmo fora da própria Microsoft, como o caso do AutoCAD da Autodesk.


Tags: Excel, VBA, MS Office, macro, object model, modelo de objetos, Word, Autodesk, AutoCad, Powerpoint, 



Inline image 1

VBA Excel Série - 03 - VBA ou MACROS

Dando atenção a segunda limitação...
Para resolver a segunda limitação das macros baseadas em funções - pois haviam muitos comandos para se gerenciar eficazmente - o VBA foi implementado para trabalhar com um modelo de objetos. O termo modelo de objetos pode soar bastante assustador, mas é realmente apenas uma maneira lógica de organizar todos os comandos que podemos realizar num aplicativo. 

Em um modelo de objetos, cada parte diferente do aplicativo em uma planilha, ou num intervalo ou um ponto em um gráfico - torna-se um objeto. E cada objeto tem sua própria lista de funções. Podemos aprender mais tarde sobre o que um objeto é e como os objetos se relacionam com as funções, mas o ponto é que o modelo de objetos organiza todos os milhões de comandos possíveis em torno de como cada comando é usado, por exemplo, copiar e colar um intervalo de células, mas você não copia e cola pontos em um gráfico.

Devido ao modelo de objetos, o VBA não precisa de nenhum acesso interno especial ao Excel. Em vez disso, o Excel expõe as suas capacidades para o mundo exterior por meio do modelo de objetos e o VBA conversa com este modelo.




Isto significa que uma macro Excel VBA pode controlar não apenas o Excel, mas também qualquer aplicativo que forneça um modelo de objetos. Todos os aplicativos do Microsoft Office, e vários outros aplicativos da Microsoft e não-Microsoft, oferecem modelos de objetos apropriados.



O VBA que vem com o Excel não é a única linguagem que pode se comunicar com o modelo de objeto. Qualquer linguagem que suporte automação pode controlar o Excel. Você pode controlar o Excel não só com o VBA hospedado pelo Excel, mas também com o VBA hospedado pelo Word, com o Microsoft Visual Basic versão 6, ou mesmo com uma linguagem como C++. Com uma camada de tradução simples, você também pode falar com o modelo de objeto do Excel da Microsoft. NET aplicações escritas em C# ou Microsoft Visual Basic. NET.



Tags: Excel, VBA, MS Office, macro, object model, modelo de objetos, C++, C#, DOT NET, 




Inline image 1

VBA Excel Série - 01 - VBA ou MACROS


Calendário Compacto para 2014


Muitos dizem que o VBA é o controle remoto do Excel. Se isso for verdade, então o que são as Macros ?

Qual é a diferença entre o VBA e as Macros

Tudo isso parece mesmo muito confuso. Em essência, uma macro é um programa no computador que dá instruções automatizadas para este executar.

As macros originais eram uma forma de utilizar alguns caracteres que representassem uma série de instruções. Esta era chamada de macros, pois a saída era muito maior (macro) do que a entrada.

Para sermos bem sinceros, as primeiras versões de macros para as planilhas, realmente expandiram uma seqüência bem curta de caracteres para uma longa série de ações. Eram apenas atalhos para os comandos da interface do usuário, acessos rápidos aos menus na diversas versões do Excel

Por exemplo, se estivesse trabalhando com o MS Excel e dentro da sua interface digitasse R (de " Range"), N (para "Name") e C (para "Criar"), você poderia digitar RNC dentro da macro para automatizar este processo repetitivo. 

Esta abordagem era muito intuitiva, mas permeada por fraquezas inerentes. Pense: Não somente eram difíceis de ler, mas também não se adaptavam bem a uma interface gráfica do usuário. Quais teclas digitadas você usaria para representar o clique num retângulo com o mouse? Isso também impedia ou tornava difícil melhorar a interface com o usuário, pois qualquer alteração na estrutura do menu comprometeria qualquer macro criada anteriormente, porque estava intrinsecamente ligada à interface da versão em uso. E tal compatibilidade precisava ser migrada para as versões futuras.

Para resolver estes problemas, as primeiras versões do Excel continham um novo tipo de linguagem de programação, uma que era independente dos nomes de comandos da interface do usuário. 

Por exemplo, no Microsoft Excel versão 4 (Excel 2013 é a versão 14), podíamos copiar um intervalo de pelo menos três formas diferentes:

Pressionando Ctrl + C

Clicando no botão Copiar na barra de ferramentas Padrão, ou 

Clicando em Copiar no menu Editar

Todos esses métodos foram representados pela mesma instrução = COPY ().

Muito bom! Esta nova linguagem de programação não era tecnicamente uma linguagem de macro no velho sentido de expandir alguns caracteres em uma seqüência de instruções. Era tecnicamente um conjunto de funções, exatamente iguais as funções usadas para executar tarefas nas células das planilhas. Mas ainda precisaria evoluir um pouco mais...


Tags: Excel, VBA, MS Office, macro, object model, modelo de objetos,




Inline image 1

VBA Advanced - Compreendendo o Early Binding e o Late Binding - Early Binding & Late Binding



Blog Office VBA | Blog Excel | Blog Access |

Sim, o desenvolvimento da linguagem VBA nos permite abordagens distintas. E é bom que isso ocorra, pois nos possibilita variância, adequação, e certa liberdade na escolha do caminho que percorreremos em busca de uma solução plausível para o nosso cliente.

Falaremos sobre 2 métodos de programação que dizem respeito ao uso de objetos no VBA, os quais são definidos na fase de declaração das variáveis:


Early Binding (Ligação Atual)  
No método Early Binding as variáveis são declaradas com o tipo de dados assumirão antes de serem invocadas.

Late Binding (Ligação Tardia)
No método Late Binding as variáveis são declaradas como objeto e assumem seu tipo na primeira vez que uma atribuição é feita ao mesmo.


Suponhamos que fôssemos automatizar uma aplicação MS Outlook a partir do MS Excel:
Primeiramente precisamos ter acesso ao Modelo de Objetos (object model) do Outlook.

Segundo, para manipularmos um objeto do Outlook, precisamos vê-lo e isso só é possível através de 2 métodos, isso mesmo, conhecendo os métodos Early Binding e Late Binding.

Para "encapsularmos" o Outlook (Client) na nossa aplicação Excel (Host). O OB (Object model) armazenado no arquivo OLB (Object Library) precisa estar vinculado ao Excel.

CheckBinding
Podemos fazer isso através do menu Ferramentas no VBE, especificamente em Referências. A caixa de diálogo Referências será mostrada com uma lista de arquivos com os quais podemos nos ligar. É provável que a lista seja bastante longa e cheia de opções que você nunca vai usar.

Inline image 2

A ligação (bindingOLB é chamada ligação inicial (early binding). É early (cedo) porque expomos o modelo de objeto durante o momento do design e não no tempo de execução. 

No exemplo acima pode observar a versão do Microsoft Outlook 9.0 Object Library. A parte 9.0 do nome será diferente se você estiver usando uma versão diferente do Outlook. Incidentalmente, o nome do arquivo OLB que aloja esta biblioteca é msoutl9.olb. Você pode ver o caminho onde ele é armazenado na parte inferior da caixa de diálogo.

Apenas selecionar uma referência nesta caixa diálogo não fará absolutamente nada. Algumas vezes simplesmente seleciono a referência e fecho a caixa de diálogo apenas para encontrar o erro de compilação: Tipo definido pelo usuário não definido (User Defined Type not Defined). Quando você receber esse erro, a primeira coisa que deve verificar é que tenha definido a referência corretamente.

Uma vez que tenha passado por este processo, pode criar um procedimento como este:

Sub CheckBinding()

    Dim olApp As Outlook.Application

    Set olApp = New Outlook.Application

    MsgBox olApp.Name

End Sub

A ligação (binding) tardia (Late) tem o mesmo efeito que o Early Binding. A diferença é que você efetua a ligação da biblioteca em tempo de execução (run-time). Não precisa usar as Referências previamente, mas sim as funções GetObject ou CreateObject. O código abaixo faz a mesma coisa que o CheckBinding acima, mas usa o Late Binding.

Sub CheckBindingLB()

    Dim olApp As Object

    Set olApp = CreateObject("Outlook.Application")

    MsgBox olApp.Name

End Sub

Na maioria dos exemplos que usamos aqui o CreateObject será muito útil. É usado quando precisamos criar uma nova instância do Outlook e usamos o GetObject se quisermos fazer referência a uma instância já em execução do Outlook.

Para enviarmos um e-mail, criarmos uma tarefa, ou diversas outras atividades, não importa se usamos uma instância nova ou existente. Usaríamos o GetObject se desejássemos mostrar algo no Outlook, por exemplo, um calendário. Nesse caso, não iríamos querer dois Outlooks executando só para exibir um calendário.

O código a seguir usa Late Binding para exibir a pasta do calendário na instância existente do Outlook, criando uma instância, se não houver uma.

Sub DisplayCalendar()

    Dim olApp As Object
    Dim olNs As Object

    On Error Resume Next
    Set olApp = GetObject(, "Outlook.Application")

    If Err.Number = 429 Then
        Set olApp = CreateObject("Outlook.application")
    End If

    On Error GoTo 0

    Set olNs = olApp.GetNamespace("MAPI")

    If olApp.ActiveExplorer Is Nothing Then
        olApp.Explorers.Add _
            (olNs.GetDefaultFolder(9), 0).Activate
    Else
        Set olApp.ActiveExplorer.CurrentFolder = _
            olNs.GetDefaultFolder(9)
        olApp.ActiveExplorer.Display
    End If

    Set olNs = Nothing
    Set olApp = Nothing

End Sub

Detalhando

Talvez para os que estão iniciando no VBA exista muita coisa acontecendo no código acima. E saiam já daqui! Não viram que o tópico é Advanced? Brincadeiras à parte, vamos olhar para as seções pertinentes uma de cada vez:

 Dim olApp As Object
 Dim olNs As Object

Na seção de declarações de variáveis usamos o tipo de dados Object. Com a Early Binding usamos Outlook.Application para dimensionar (Dim) a variável "olApp". Mas, sem um conjunto de referência, o VBA não saberá o que significa Outlook.Application porque ainda não expusemos o modelo de objeto. Portanto, quaisquer objetos que utilizarmos a partir do modelo de objeto do Outlook, devem ser declarados com o tipo genérico Object.

On Error Resume Next

Set olApp = GetObject(, "Outlook.Application")

If Err.Number = 429 Then
   Set olApp = CreateObject("Outlook.application")
End If

On Error GoTo 0

A função GetObject gerará um erro se não houver uma instância do Outlook, por isso usamos On Error Resume Next para ignorá-lo. Em seguida, testamos um erro específica, o qual se tiver ocorrido usaremos CreateObject. Redefiniremos o tratamento de erros com On Error GoTo 0, de modo a não disfarçarmos quaisquer erros no final do procedimento.

Porquê 2 métodos?

Ambos os métodos têm vantagens e desvantagens. A Late Binding é mais lenta do que a Early Binding porque ocorre durante o tempo de execução. Quando fazemos o trabalho durante o design, o código será executado mais rapidamente. Quando você está escrevendo o código usando a Late Binding, perde algumas conveniências. Mais especificamente, não ver o Intellisense mostrando as propriedades e métodos de objetos quando os digita. Além disso, o navegador de objetos (F2) não apresenta nenhum dos objetos do Outlook. E por fim, não terá a vantagem de usar constantes internas na Late Binding. Veja o código abaixo:

olNs.GetDefaultFolder (9)

O código ficaria assim numa ligação prévia:

olNs.GetDefaultFolder (olFolderCalendar)

olFolderCalendar é definido numa constante dentro do modelo de objeto do Outlook que não será exposto, se você não tiver definido uma referência. Embutidos constantes podem tornar o código muito mais legível e mais fácil de depurar.

Tudo parece fazer muito sentido e ser muito bom para a Early Binding, mas a Late Binding tem uma vantagem muito grande que não pode ser negligenciada. Ao se efetuar a Late Binding, não importa qual seja a versão do Outlook instalada, o VBA vai usar o nome da classe fornecido com GetObject ou o CreateObect ("Outlook.Application" no nosso caso) e encontrará o modelo de objeto correto para referência.

Ao discutir a Early Binding acima, vai notar que definir uma referência ao Microsoft Outlook 9.0 Object Library porque eu estou usando o Outlook 2000. Se fosse enviar um procedimento para alguém que estava usando uma versão anterior do Outlook, o código seria um fracasso, porque não teriam essa biblioteca objeto específica instalada. 

Para tirar o máximo proveito do ambiente de desenvolvimento VBA e ainda escrever um código robusto, devemos escrever o código com Early Binding, mas mudá-lo no final, antes de distribuí-lo. Mesmo que escreva apenas para uso pessoal, não faz sentido não convertê-lo no final. Algum dia terá um computador diferente ou enviará este código para o seu irmão e não vai funcionar porque eles vão ter uma versão anterior.


Referências:
Dick´s Clickshttp://www.dicks-clicks.com




Tags: VBA, Advanced, Early Binding, Late Binding, OLB, Object Library, MS Outlook,  Object Model, Object Library, msoutl9.olb, Microsoft Outlook 9.0 Object Library, GetObject, CreateObject, CheckBinding, 



diHITT - Notícias