Delphi. Editorial .NET. Delphi Delphi Delphi. Delphi. Desafio The Club. Dicas. Legenda

Transcrição

1 setembro 2011

2 setembro 2011

3 índice Editorial Delphi.NET Esse mês de setembro, como já se Metodologia tornou tradição, tivemos o lançamento 04 da mais nova versão do Delphi, intitulada XE2. ágil - Extreme Programming 05 Autor:Thiago Cavalheiro Montebugnoli Criando componentes no Windows Forms 10 Autor:Luciano Pimenta Delphi Delphi Delphi Injetor de DLL Delphi XE2 - novidades Fast report - XE2 Autor: Eduardo Massud Autor: Antonio Spitaleri 22 Autor: Antonio Spitaleri Delphi Dicas Desafio The Club Métodos RAVReport - de A a Z - Dicas Delphi - Cruzada Legenda Iniciante Intermediário Avançado setembro

4 Bem-vindo Esse mês de setembro, como já se tornou tradição, tivemos o lançamento da mais nova versão do Delphi, intitulada XE2. Para que vocês fiquem atualizados com essa nova versão, esse mês trago dois artigos sobre o Delphi XE2. Na primeira, Delphi XE2 Novidades, mostro uma visão geral das novidades da versão e o que foi incluído na mesma em relação a componentes de terceiros. Na segunda matéria, Fast Reports Delphi XE2, mostro a utilização do gerador de relatórios Fast Reports na nova versão do Delphi. Lembrando que o Fast Reports agora é nativo no Delphi. Av. Profº Celso Ferreira da Silva, 190 Jd. Europa - Avaré - SP - CEP Informações e Suporte: (14) Internet Cadastro: cadastro@theclub.com.br Suporte: suporte@theclub.com.br Informações: info@theclub.com.br Skype Cadastro: theclub_cadastro Skype Suporte: theclub_linha1 theclub_linha2 theclub_linha3 Em nossa seção.net, Luciano pimenta nos mostra como criar componentes em aplicações Windows Forms. Voltando ao Delphi, nosso consultor Eduardo Massud vem com o artigo Injetor de DLL. Nesse artigo ele nos mostra como podemos incorporar o código de uma dll em um aplicativo em execução. Nossa colaboradora Leonora Golin traz um manual do Rave Reports, mostrando os métodos que podemos utilizar nessa ferramenta no artigo: Métodos Rave Report A a Z. Para fechar, Thiago Montebugnoli nos traz um artigo muito interessante na área de análise de sistemas no artigo: Metodologia Ágil Extreme Programming. Boa leitura a todos e até outubro! Copyright The Club Megazine 2009 Diretor Técnico Marcos César Silva Diagramação e Arte Vitor M. Rodrigues Revisão Eliziane Valentim Colunistas Antonio Spitaleri Neto Bruno Alcarás Eduardo Massud Leonora Golin Luciano Pimenta Thiago Cavalheiro Montebugnoli Impressão e acabamento: GRIL - Gráfica e Editora Taquarituba-SP - Tel. (14) Antonio Spitaleri Neto - Editor Chefe antonio@theclub.com.br Reprodução A utilização, reprodução, apropriação, armazenamento em banco de dados, sob qualquer forma ou meio, de textos, fotos e outras criações intelectuais em cada publicação da revista The Club Megazine são terminantemente proibidos sem autorização escrita dos titulares dos direitos autorais. Delphi é marca registrada da Borland International, as demais marcas citadas são registradas pelos seus respectivos proprietários. 04 setembro 2011

5 Delphi Metodologia Ágil Extreme Programming Um pouco do conceito Neste artigo estarei abordando a Metodologia Ágil Extreme Programming, traduzindo para o português como Programação Extrema. Esta Metodologia de desenvolvimento de softwares tem como base as empresas que sofrem constantes mudanças, e conseqüentemente tendo como estratégia o acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de softwares. A Extreme Programming, conhecido também pela sigla XP, concentra os esforços da equipe de desenvolvimento em atividades que geram resultados rapidamente na forma de software intensamente testado e alinhado às necessidades de seus usuários. Outra característica seria a organização e a simplificação do trabalho, combinando técnicas comprovadamente eficazes e por fim eliminando atividades redundantes. Tem como finalidade reduzir o risco dos projetos desenvolvendo softwares de forma iterativa e de boa qualidade. Entende-se como iteratividade como o processo chamado na programação de repetição de uma ou mais ações. Descreverei os quatro valores deste tipo de Metodologia Ágil, tais como: FeedBack, Comunicação, Simplicidade, Coragem. Especificamente neste artigo explicarei também algumas práticas, tais como: Cliente Presente, Jogo de Planejamento, Stand Up Meeting, Programação em Par, Código Coletivo, Código Padronizado, Design Simples, Teste Orientado a Testes, Refactoring, Integração Contínua, Releases Curtos. Os Valores 1-) FeedBack É importante ressaltar que existem dois tipos de FeedBack, o do cliente em relação ao desenvolvedor e o do desenvolvedor em relação ao cliente. Cliente x Desenvolvedor Neste primeiro o Cliente aprende com o sistema que utiliza e com isto consegue reavaliar o produto recebido, podendo realimentar a equipe de desenvolvimento com as suas reais necessidades, conduzindo o desenvolvimento de seu produto, estabelecendo prioridades informando aquilo que é realmente importante. Desenvolvedor x Cliente setembro

6 O Feedback dado pelo desenvolvedor ao cliente, o mesmo aponta riscos, estimativas e alternativas de design. Em poucas palavras, este retorno é o aprendizado do desenvolvedor sobre o que o cliente deseja. É interessante salientar a compreensão das necessidades dos usuários, sendo uma das atividades mais difíceis e importantes de serem realizadas pelos desenvolvedores de softwares. Uma das características do Extreme Programming seria a organização de ciclos curtos de feedback, possibilitando aos usuários solicitar funcionalidades e aprender sobre elas através de software funcionando em prazos curtos. Irei salientar que esta técnica envolve a priorização de poucas funcionalidades a serem implementadas de cada vez, buscando a simplificação das mesmas na medida do possível. Conseqüentemente a equipe segue adiante apenas se o resultado estiver correto, existindo alguma falha, as mesmas serão corrigidas rapidamente antes de efetuar o desenvolvimento de novas funcionalidades, tendo sempre um software livres de Bugs e códigos desnecessários. Figura 01: Resultado de uma comunicação falha. 2-) Comunicação Para que o Feedback funcione com sucesso é necessário ter uma boa comunicação entre as partes envolvidas, que ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados. Os projetos de Software envolvem a presença de pelo menos duas pessoas, um usuário e um desenvolvedor, portanto a comunicação entre elas é essencial para uma boa conduta. Uma das características do Extreme Programming seria o envolvimento ativo de seus usuários, tornando-os parte integrante da equipe de desenvolvimento. Isto significa que o usuário estará sempre presente no local onde os desenvolvedores trabalham, possibilitando o acesso rápido às informações ali trocadas. Poderá ocorrer o inverso também, a equipe de desenvolvimento poderá trabalhar dentro da empresa onde o software está sendo desenvolvido. Outra característica seria a quantidade de pessoas envolvidas no projeto, quanto maior o número de pessoas torna-se mais difícil para as pessoas saber o que os outros estão fazendo e como não sobrepor, duplicar ou interferir no trabalho um do Figura 02: Gráfico de utilização do Software. outro, por este motivo o XP procura contar com um número reduzido de pessoas. Abaixo segue a Imagem que é muito comum em exemplo de XP. Ela demonstra o que acontece quando a comunicação entre as partes é falha. Veja a figura ) Simplicidade Um dado interessante para abordarmos seria a quantidade de tempo desperdiçado no desenvol- vimento de software, os projetos freqüentemente investem grande parte dos recursos em esforços desnecessários. Veja o Gráfico abaixo para podermos entender melhor. Veja a figura 02 Podemos observar que apenas 20% do que foi desenvolvido realmente é utilizado, ou seja, 80% do nosso tempo gastos com análise, programação foi jogado no lixo. Um erro comum cometido pelos desenvolvedores seria a implementação de funcionalidades adicionais na tentativa de antecipar 06 setembro 2011

7 o que o usuário certamente irá solicitar no futuro. Os desenvolvedores que utilizam a metodologia XP procuram implementar as funcionalidades priorizadas para cada iteração com a maior qualidade possível, tendo o foco somente naquilo que é essencial. Procuram fazer apenas o feijão com arroz para que o software funcione corretamente. Os princípios da Extreme Programming se baseiam de que as funcionalidades extras adicionam complexidade e não a flexibilidade, sendo assim procuram adiar a inclusão de qualquer funcionalidade até que ela realmente seja priorizada pelo cliente. 4-) Coragem No desenvolvimento de softwares existem alguns medos que assombram tanto os desenvolvedores quanto aos clientes, veja abaixo alguns dos principais: Os desenvolvedores Ser solicitados a fazer mais do que sabem fazer; Fazer coisas que não tem sentido; Não receber definições claras sobre o que precisa ser feito; Sacrificar qualidade por causa do prazo de entrega; Ficar tecnicamente defasados. Os clientes Não obter o que pediram; Pedir coisas que não irão utilizar; Pagar muito pelo software; Focar apenas nas suas primeiras decisões e não serem capazes de realizar mudanças. Na realidade estes temores existem e a equipe de XP os reconhece buscando formas para lidar com os mesmos. Uma das técnicas utilizadas em XP seria adotar iterações curtas, isto protege sua equipe dos clientes que temem não obter o que pediu. Normalmente estas iterações curtas duram de uma a três semanas. O desenvolvimento iterativo também ajuda a lidar com o medo que o cliente tem de pagar demais por muito pouco. Ao receber funcionalidades Figura 03: Release e Iteração no XP. com freqüência, em prazos curtos, o cliente passa a ter diversas oportunidades de avaliar o trabalho da equipe com base em feedback concreto, ou seja, irá ver o software funcionando. Resumindo, o desenvolvimento iterativo da equipe procura resolver praticamente todos estes temores encontrados tanto na parte do cliente quanto a do desenvolvedor. As Práticas 1-) Cliente Presente O XP sugere que o cliente esteja no dia-a-dia do projeto, acompanhando todos os passos do desenvolvedor, onde sua ausência representa sérios riscos no decorrer do projeto. A presença do cliente ao longo do desenvolvimento viabiliza o ciclo contínuo de feedback entre ambas as partes, permitindo que sejam realizadas pequenas mudanças de uma forma rápida ao longo do projeto. O desenvolvedor sabe exatamente o que o cliente deseja de uma forma muito rápida. Outro benefício desta proximidade seria uma melhoria na relação de confiança entre as partes envolvidas, tendo como resultado positivo no decorrer do projeto. 2-) Jogo do Planejamento Planejar o que implementar é uma das atividades mais importantes a serem conduzidas durante o desenvolvimento de um sistema. Este planejamento é realizado várias vezes durante o projeto, seria o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja os releases e as iterações. Para entendermos melhor, o que seria uma estória? Estórias são as funcionalidades que o cliente espera receber na aplicação que será construída, que em outras abordagens seriam chamadas de requisitos, casos de usos ou pontos de função, sendo registradas em chamados cartão de estória pelo cliente em uma linguagem simples e comum, o suficiente para a compreensão de todos da equipe de desenvolvimento. E uma iteração? Para um fácil entendimento, uma iteração é o tempo disposto a fim de gerar a implementação de um determinado número de estórias. Normalmente as iterações são curtas, durando em média uma semana. E um release? Representa um marco no tempo no qual um conjunto coeso de funcionalidades é finalizado e lançado para consumo de seus usuários. Neste espaço de tempo do release a equipe trabalha com iterações curtas e fixas. As imagens 03 e 04 abaixo nos auxiliam no entendimento destes conceitos. Veja a figura 03. Veja a figura ) Stand Up Meeting É uma reunião rápida pela manhã, com aproximadamente 20 minutos, onde seus integrantes setembro

8 permaneçam preferencialmente em pé. Segundo estudos, uma reunião em pé é mais rápida evitando bate-papos paralelos fazendo os integrantes irem diretamente ao assunto. Esta reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e também permitindo que os participantes priorizem atividades do dia que se inicia. Este tipo de reunião força a aproximação dos desenvolvedores de forma diária e contínua, diminuindo os tempos de feedback na medida que toda manhã cada desenvolvedor reporta suas atividades executadas no dia anterior. 4-) Programação em Par É dada programação em par, pois o XP exige que todo o desenvolvimento do projeto seja efetuado em dupla. Esta é uma técnica onde dois programadores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles seria o responsável pela digitação e o outro acompanha o trabalho. Esta técnica implementa uma das diversas redes de proteção nos projetos XP, reduzindo os riscos de eventuais falhas. Outra característica importante da programação em par seria o processo de inspeção, pois isto se torna uma parte natural do dia-a-dia da equipe de desenvolvimento, diminuindo os problemas que possam ocorrer no futuro. Estas revisões em pares representam uma das formas mais eficazes para encontrar os denominados Bugs, pois às vezes um erro para um programador pode passar despercebido, tendo outro do seu lado estes tipos de problemas tem suas chances bastante diminuídas. Outro fator importante neste tipo de programação é o diálogo constante entre os participantes, isto é, discutem novas idéias e abordagens. É com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através de troca de experiências. Após algum tempo trabalhando em dupla todos os desenvolvedores conhecerão todas as rotinas do sistema e estarão prontos para qualquer modificação ou para auxiliar algum programador iniciante. 5-) Código Coletivo Figura 04: Release, Iterações e Estórias no XP. Todas as classes e métodos pertencem à equipe e qualquer membro da equipe pode melhorar o que for necessário, ou seja, o desenvolvedor tem acesso a todas as partes do sistema. Esta prática tem como conseqüência um código revisado e testado por diversas pessoas e caso encontre algum problema este código poderá ser alterado por qualquer pessoa da equipe. 6-) Código Padronizado O XP recomenda a adoção de um padrão de código desde o início do projeto. A adoção de um padrão ajuda a simplificar a comunicação entre os membros. Esta também é uma prática muito importante, pois em uma tarefa futura qualquer membro da equipe poderá modificar o código. 7-) Design Simples Alguns itens são indispensáveis para os usuários de um software, tais como: Que o mesmo faça a coisa certa, seja fácil de utilizar, funcione corretamente e por fim possa evoluir com o tempo. As práticas do XP se complementam formando um conjunto para atingir estes objetivos. É adotado Releases seguidos de Iterações Curtas os quais implementam um número pequeno de estórias, dando para o cliente um feedback rápido permitindo que o cliente saiba se o sistema está fazendo a coisa certa e se está funcionando. As equipes procuram assegurar que o design seja mantido simples e eventuais flexibilidades sejam adiadas até que se tornem efetivamente necessárias em função das estórias solicitadas pelos usuários. Uma característica importante é que os desenvolvedores não tentam prever mudanças no futuro e nem procuram antecipar as flexibilidades que serão necessárias. O Design deve ser simples, porém atendendo todas as necessidades do cliente acima descritas. 8-) Desenvolvimento Orientado a Testes Todo código implementado deve coexistir com um teste automatizado, garantindo o pleno funcionamento da nova funcionalidade. É com base nestes testes que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele. Trata-se de uma técnica preventiva utilizada durante todo o projeto e a manutenção, ou seja, o programador evita os problemas que no futuro poderão acarretar em problemas muito maiores. Desta forma os testes automatizados procuram comprovar que as solicitações dos usuários estão sendo atendidas de forma correta. 08 setembro 2011

9 O XP se concentra em dois tipos de testes: Teste de Unidade Tem por objetivo verificar se os resultados gerados por cada classe estão corretos. Estes tipos de testes são escritos antes de cada método produzido, seria uma forma para verificar se o sistema irá funcionar corretamente. Teste de Aceitação ou Funcionais Tem por objetivo verificar se a interação entre as classes que implementam uma estória atendem a necessidade de forma correta, sendo descritos pelo cliente ou orientados por ele e implementados pelo desenvolvedor. Neste caso, o cliente escreve teste para uma estória de cada vez para realizar este tipo de teste, tendo o desenvolvedor o trabalho de traduzir as idéias dos testes. Portanto, escrever um teste antes de cada estória representa uma maneira de aprimorar a análise sobre as características da mesma. 9-) Refactoring Traduzindo para o português Refactoring significa Refatoração, esta técnica implica que todo desenvolvedor ao encontrar um código mal escrito, ilegível, sem padronização, lento tem por obrigação alterar este código deixando-o o mais simples e legível possível. É importante salientar que estas modificações não poderão alterar o comportamento do código em questão. A necessidade de Refatoração aparece à medida que a arquitetura evolui e novas funcionalidades são solicitadas pelos clientes. Ao longo do processo de Refatoração o sistema irá ter as seguintes características, tais como: Simplicidade: Seria um design simples, Clareza: Código de fácil entendimento, Adequação ao Uso: O propósito deverá ser alcançado, Ausência de Repetição: O código não pode ser repetido, Ausência de Funcionalidades Extras: Funcionalidades que não são úteis ao sistema. No processo de Refatoração os desenvolvedores procuram utilizar nomes que façam sentido, evitando abreviações e adotando um código padronizado. Este tipo de técnica anda de mãos dadas com a de Código Coletivo e Código Padronizado. Estas técnicas no XP se tornam muito importantes e relevantes quando são utilizadas corretamente. 10-) Integração Contínua O XP defende uma integração contínua, deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém desenvolvido. Com esta prática o feedback sobre a alteração efetuada será retornado em um menor espaço de tempo. Diferentemente do desenvolvimento tradicional, onde temos a divisão por módulos. Estas estratégias reduz a complexidade e as preocupações do desenvolvedor. 11-) Releases Curtos Em XP, temos os denominados Releases curtos, que seriam um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente. O XP recomenda que pequenos investimentos sejam efetuados de forma gradual, dando um retorno para o cliente em um espaço de tempo muito curto. Diferentemente do modelo tradicional que é dividido em fases, de um modo que o cliente tenha benefícios quase no término do sistema. Uma das finalidades desta prática seria maximizar o retorno dos projetos assegurando que o maior valor do negócio seja entregue ao final de cada release. Esta técnica consiste em colocar o sistema para funcionar em prazos muito curtos, geralmente alguns meses. Conclusão Sobre o autor Thiago Cavalheiro Montebugnoli Vimos neste artigo um pouco da Metodologia Extreme Programming junto com seus valores e algumas práticas. Podemos perceber que este tipo de metodologia pode ser bem útil no âmbito de desenvolvimento de sistemas. Muitas empresas vêm aprimorando as concepções desta Metodologia para atender todas as necessidades, principalmente a das pessoas. Estarei abordando em artigos futuros um pouco mais desta Metodologia que tem como foco melhorar a condução de sua equipe de desenvolvimento e atender e entender todas as necessidades dos clientes. Fico por aqui, um forte abraço e até o mês que vem. Thiago Cavalheiro Montebugnoli é tecnólogo, formado pela Faculdade de Tecnologia de Botucatu SP (FATEC) foi consultor técnico do The Club, já desenvolveu softwares utilizando a plataforma.net, Delphi junto com Banco de Dados SQL Server e Firebird. Atualmente trabalha no Centro de Processamento de Dados da Prefeitura Municipal de Itaí-SP. Possui as seguintes certificações: MCP - Microsoft Certified Professional, MCTS - Microsoft Certified Technology Specialist, MCAD - Microsoft Certified Application Developer e MCSD - Microsoft Certified Solution Developer. thiago@theclub.com.br setembro

10 Criando componentes no Windows Forms Veremos nesse artigo, como criar componentes para aplicações Windows Forms com C# no Visual Studio A idéia do artigo é criar um componente extended, ou seja, componente estendido para apenas agregar propriedades em controles já existentes. Um exemplo, seria o controle Error- Provider que ao colocar o mesmo em um formulário, adiciona a propriedade Error on errorprovider1 em alguns controles de tela. O componente que criaremos indicará se o campo é de preenchimento obrigatório. Outro componente que criaremos será o de pesquisa, componente visual para termos uma pesquisa auxiliar. Indicando algumas propriedades poderemos ter uma tela de pesquisa a ser reaproveitada em toda a aplicação. Imagine uma aplicação comercial, onde telas de pesquisas auxiliares sejam muito usadas. O trabalho de manutenção de várias telas é cansativo, portanto, o componente ajuda a diminuir esse trabalho, além de dar agilidade no desenvolvimento. Figura 1. Exemplo de extending component Criando um Extending Component Um Extending Component, agrega, propriedades em determinados tipos de controles. Na implementação do mesmo, são definidos que controles e quais propriedades serão incorporadas ao mesmo. Veja na Figura 1 um exemplo de Extending Component utilizando um TextBox. Faça um teste, adicione um TextBox em um formulário e note que nenhuma propriedade mostrada na Figura 1, existe no componente. Elas aparecerão quando você adicionar os respectivos extending component no formulário. Vamos passar então para a criação do extending component. Abra o Visual Studio 2010, caso ainda não o tenha feito, e crie um projeto do tipo Class Library (Figura 2). Veja a figura 2. Após, remova a classe adicionada. Adicione um item do tipo Component Class (Figura 3). 10 setembro 2011

11 Veja a figura 3. Note que temos um container do tipo do objeto. Aperte F7 para visualizarmos o código do componente. Aqui, iniciamos nossa implementação. Não teremos nenhum componente no container criado, então, podemos remover as chamadas ao método InitializeComponent. Para que você possa saber o valor que estará presente na propriedade a ser adicionada, não podemos simplesmente fazer, por exemplo: if (textbox1.obrigatorio) Como a propriedade é extendida, ela não esta presente no código. Para saber o valor da propriedade ou alterar o mesmo, precisamos criar dois métodos (get e set). Veja no código a seguir a simples implementação dos mesmos: Figura 2. Criando o projeto no Visual Studio 2010 public void SetObrigatorio(Control lcontrol, bool bvalue) EnsurePropertiesExists( lcontrol).obrigatorio = bvalue; public bool GetObrigatorio(Control lcontrol) return EnsurePropertiesExi sts(lcontrol).obrigatorio; Nos métodos, usamos a classe EnsurePropertiesExists (a ser criado a seguir) para conseguir pegar a propriedade. Assim, quando quisermos saber o valor da propriedade, basta chamar o get passando o controle como parâmetro. Precisamos indicar que o componente, implementa a interface IExtenderProvider. Na definição da classe, altere: public partial class Obrigatorio : Component, IExtenderProvider Adicione também no using o namespace System.Windows.Forms e System.Collections. Caso Figura 3. Adicionando a classe do componente não sejam reconhecidos, é necessário adicionar nas referências do projeto o respectivo assembly. Precisamos implementar o método que retorna e configura a propriedade criado no componente. private Properties EnsureProperties Exists(object key) Properties p = (Properties) properties[key]; if (p == null) p = new Properties(); properties[key] = p; return p; O tipo Properties será uma classe privada que criaremos, responsável por armazenar o valor da propriedade. Assim, poderíamos ter tantas setembro

12 propriedades extendidas, quanto quiséssemos. A definição da classe: private class Properties public bool Obrigatorio; public Properties() Obrigatorio = false; private Hashtable properties; No construtor da classe Obrigatorio, vamos instanciar a classe privada: properties = new Hashtable(); Precisamos indicar ao componente, em quem ele pode adicionar a propriedade. bool IExtenderProvider. CanExtend(object lcontrol) return (lcontrol is Control); Indicamos que ele pode criar a propriedade Obrigatorio em qualquer componente que herde de Control. Poderíamos especificar, por exemplo, indicar que somente TextBox receberia a propriedade. Por fim, precisamos dar o nome da propriedade para que apareça na barra de propriedades. Antes da declaração da classe, adicione o seguinte código: [ProvideProperty ( Obrigatorio, typeof(control))] Adicione no using: System.Collections e System.Windows.Forms (para esse é necessário adicionar o referência de mesmo nome). Instalando o componente Dê um build no projeto. Crie um novo projeto Windows Forms e crie uma aba na Toolbox. Clique com o botão direito na aba criada e escolha Choose itens. Na tela que abrir, escolha o arquivo TheClubExtendedComponent.dll que esta no diretório bin/debug do diretório do seu projeto. Veja na Figura 4, como ficou o componente na Toolbox. Figura 4. Componente na Toolbox Adicione alguns controles como TextBox, ComboBox, ListBox etc, no formulário, assim como um ErrorProvider e um botão. Adicione o componente Obrigatorio e no Click do botão adicione o código da Listagem 1. Listagem 1. Exemplo de utilização do componente foreach (Control ctl in this.controls) //verifica os controles adicionados em tela if (ctl is TextBox) //se TextBox vazio if ((ctl as TextBox).Text == ) //verifica se é obrigatório if (obrigatorio1. GetObrigatorio((ctl as TextBox))) errorprovider1. SetError((ctl as TextBox), Campo obrigatório! ); else errorprovider1. SetError((ctl as TextBox), ); //verifica se é ComboBox if (ctl is ComboBox) //se não foi escolhido item if ((ctl as ComboBox).SelectedIndex == -1) //verifica se é obrigatório if (obrigatorio1. GetObrigatorio((ctl as ComboBox))) errorprovider1. SetError((ctl as ComboBox), Selecione pelo menos um item ); else errorprovider1. SetError((ctl as ComboBox), ); //verifica outros controles da tela Como podemos ver, fizemos um laço para percorrer os controles do formulário. Precisamos verificar cada tipo, para saber se o mesmo foi preenchido ou selecionado para executar a verificação do componente. Lembrando apenas que você deve alterar para True a propriedade Obrigatorio on obrigatorio1 de cada controle para indicar se o mesmo precisa ser preenchido. Veja na Figura 5 a validação da tela. Figura 5. Validando campos obrigatórios 12 setembro 2011

13 Criando um componente visual de pesquisa A criação de um componente visual é semelhante. A diferença maior fica por conta que nesse exemplo temos um formulário de pesquisa. Teremos um Component Class para ter as propriedades e eventos a serem modificados/codificados. Esse Component Class que terá o método para chamar o formulário de pesquisa. Crie ou Component Class, semelhante ao da Figura 3, mas usando o nome Pesquisa.cs. Precisamos agora, criar as propriedades que serão alteradas. Veremos a propriedade referente ao título do formulário. Assim, para cada tipo de pesquisa, você poderá indicar o título correto. Adicione o seguinte código: private string _stitulo; public string Titulo get return _stitulo; set _stitulo = value; Vamos também criar duas propriedades, para que nosso componente de pesquisa realize a pesquisa através de código e de descrição. private string _ ssqlcodigo; private string _ ssqldescricao; public string ssqldescricao get return _ ssqldescricao; set _ssqldescricao = value; public string ssqlcodigo get return _ ssqlcodigo; set _ssqlcodigo = value; Nota: essa padronização é feita apenas para fins didáticos. Você pode adaptar para sua necessidade normalmente. O interessante, seria uma propriedade no controle, onde adicionariamos os filtros e seria incluído no formulário automaticamente. Fica a dica. Para finalizar as propriedades, vamos adicionar mais duas, que serão responsáveis por retornar para o formulário que chamou a tela de pesquisa, os valores do código e a descrição pesquisada. private string stovalor; private string stotexto; Veja que indicamos que as propriedades são private. Fiz isso por que o valor das mesmas será retornado por métodos, como podemos ver: public override string ToString() return stotexto; public string ToValue() return stovalor; O ToString() retornará a descrição selecionada na tela de pesquisa, enquanto o ToValue() retornará o código. Vamos agora, criar o evento do componente. Quando o usuário selecionar um registro na tela de pesquisa, precisamos saber o valor que ele escolheu, tanto para código quanto para descrição. Sabemos os métodos que devemos chamar, mas precisamos saber em que evento chamar esse método. Por isso, criaremos o seguinte evento: public delegate void OnCloseSearch(object sender, System.Windows. Forms.DialogResult drretorno); [Category( Notification )] public event OnCloseSearch CloseSearch; Utilizamos o DialogResult para saber se o usuário fechou sem escolher a tela ou escolheu um item existente (iremos configurar isso mais adiante na tela de pesquisa). Agora nosso método principal, o responsável por mostrar a tela de pesquisa. Mas antes, apenas adicione uma formulário com o nome de frmpesquisa.cs (Figura 6). Veja a figura 06. Voltando ao método principal da classe, veja como ele é implementado: public void Pesquisar() frmpesquisa frm = new frmpesquisa(); frm.text = _stitulo; frm.ssqlcodigo = _ ssqlcodigo; frm.ssqldescricao = _ssqldescricao; DialogResult retorno = frm.showdialog(); if (CloseSearch!= null) if (retorno == DialogResult.OK) stotexto = frm. stotexto; stovalor = frm. stovalor; CloseSearch(this, retorno); O código é simples. Chamamos o formulário de pesquisa, configuramos as propriedades (titulo, SQLs, etc) e preenchemos uma variável com o retorno do mesmo. Se o evento (CloseSearch) não for nulo, verificamos se o retorno foi OK (existe um item escolhido) e preenchemos os valores que serão retornados pelo formulário. Por fim, executamos o evento. Veja que não existem muitas dificuldades, apenas temos que atentar para o preenchimento correto das variáveis. Assim, no formulário de pesquisa, adicionado anteriormente, devemos primeiramente criar as variáveis de retorno dos dados e configurações: setembro

14 public string stovalor; public string stotexto; public string ssqlcodigo; public string ssqldescricao; As características da tela de pesquisa (layout e componentes) podemos ver na Figura 7. Costumo usar essa padronização, mas fique a vontade para alterá-la, Veja a figura 7. Lembre-se que na tela de pesquisa, devemos programar o mais abstrato possível, pois o componente tem a finalidade de ser genérico. Usei um ListView, mas fique a vontade de usar um datagridview ou qualquer outro controle que mostre os dados. Figura 6. Criando o formulário de pesquisa Para o botão OK, devemos codificar para fechar o formulário e passar o valor OK para o DialogResult do formulário. O Cancelar é semelhante, apenas que vamos passar o valor Cancel. Caso, você tenha algum método que feche o formulário (exemplo, duplo clique no componente que mostra os dados), lembre-se apenas de configurar corretamente o valor do DialogResult. Vamos criar um método que fará a pesquisa e será chamado quando clicarmos no botão Pesquisar ou quando apertar ENTER no TextBox do filtro. Vale lembrar que aqui, evite referenciar string de conexão diretamente no código, pois seu componente vai ser utilizado em outros projetos (essa é a idéia). O que fazer então? Bom, eu possuo um framework de acesso a dados, que pega a string de conexão configurada no projeto. Deixo a seu critério, escolher a melhor forma de pegar a string de conexão para adaptar ao componente de pesquisa. Voltando ao formulário de pesquisa, adicione o seguinte código para o método de pesquisa. string ssql = ; if (rbcodigo.checked) ssql = this. ssqlcodigo.replace( [#], txtpesquisa.text); else ssql = this. ssqldescricao. Replace( [#], Figura 7. Layout da tela de pesquisa txtpesquisa.text); SqlConnection con = new SqlConnection(Settings. Default.strPesquisa. ToString()); SqlDataAdapter da = new SqlDataAdapter(sSQL, con); DataTable dt = new DataTable(); con.open(); try da.fill(dt); catch (Exception ex) throw new Exception(ex. Message); finally con.close(); int nqtderegistros = dt.rows.count; if (nqtderegistros > 0) lvpesquisa.items. Clear(); foreach (DataRow row in dt.rows) ListViewItem item = new ListViewItem(row[0]. ToString()); item.subitems. 14 setembro 2011

15 Add(row[1].ToString()); lvpesquisa.items. Add(item); foreach (ListViewItem item in lvpesquisa.items) if (item.index % 2 == 0) item.backcolor = Color.Gainsboro; else item.backcolor = Color.Transparent; lblmensagem.text = nqtderegistros + registro(s) encontrado(s) com o texto + txtpesquisa.text + ; btnok.enabled = (nqtderegistros > 0); if (nqtderegistros > 0) lvpesquisa.focus(); Vamos entender o método. Primeiramente, configuramos a conexão com o banco (usaremos o Northwind) e fazemos a consulta, de acordo com o tipo (Código ou Descrição). Veja que fiz um Replace no valor da propriedade, pois precisamos modificar um coringa pelo valor digitado pelo usuário. Use o coringa que desejar. Outra maneira seria usar parâmetros da consulta SQL. Fica a seu critério a melhor maneira. A conexão com o banco deve ficar dentro de um bloco try...catch...finally para que no caso de erro, a conexão seja sempre fechada (no finally). Figura 8. Exemplo do componente de pesquisa Testando o componente Para testar o componente, dê um build no projeto do componente. Crie uma aplicação Windows Forms e atualize a ToolBox para mostrar o novo componente (basta fazer o mesmo mostrado anteriormente). Configure as propriedades do(s) controle(s) que deseja testar. No botão, faça a chamada do método Pesquisar() do controle. No evento do componente, use o seguinte código: if (drretorno == System.Windows.Forms. DialogResult.OK) textbox1.text = Código: + pesquisa1. ToValue() + - Descrição: + pesquisa1.tostring(); Veja a figura 8. Conclusões Vimos neste artigo como criar componentes estendidos e visuais em aplicações Windows Forms com C#. A criação dos componentes visa melhorar a produtividade de suas aplicações e manutenção das mesmas. Experimente outros exemplos como propriedade para saber o controle tem permissão para ser editado ou exibido (segurança e controle de permissões). Fica a dica. Um grande abraço a todos e até a próxima! Após, verificamos se existem registros na consulta, para preenchermos o controle de tela (ListView), o que é bem simples. Percorremos os itens do ListView para dar um layout diferente ao mesmo, no estilo zebrado. Nota: Existem outras maneiras de fazer o estilo zebrado no ListView. Por fim, mostramos uma mensagem (na StatusBar) com a quantidade de itens retornados e habilitamos o foco no ListView. Execute a aplicação e veja como funciona (Figura 8). Luciano Pimenta Sobre o autor É Técnico em Processamento de Dados, desenvolvedor Delphi/C# para aplicações Web com ASP.NET e Windows com Win32 e Windows Forms. Palestrante da 4ª edição da Borland Conference (BorCon). Autor de mais de 60 artigos e de mais de 300 vídeos aulas publicadas em revistas e sites especializados. É consultor da FP2 Tecnologia ( onde ministra cursos de programação e banco de dados. É desenvolvedor da Paradigma Web Bussiness em Florianópolis-SC. setembro

16 Injetor de DLL Um dos temas mais discutidos sobre programação são as injections ou injeções, que fazem com que um componente externo interaja com o sistema e suas funções internas fazendo com que elas executem as rotinas ou os processos de maneira diferente do que foi programado, porém muitos se utilizam desse método para acessar pontos restritos de websites e sistemas, mas, neste artigo veremos esta questão com o intuito de promover a facilidade de que os programadores têm de dar flexibilidade à suas aplicações com as Dynamic Link Libraries, já que elas fazem parte também da estrutura do Sistema Operacional Windows, sendo uma importante fermenta de comunicação de muitos bancos de dados como o Firebird e o Mysql, por exemplo. Neste artigo trataremos à pratica da utilização, da necessidade e da necessidade da dll e não da injection em si, e para isso utilizaremos alguns componentes simples porém funcionais do delphi. Componentes Utilizados e Codificação Utilizaremos fundamentalmente 2 Edits, 3 Botões e 1 OpenDialog para que o componente funcione como esperado. Vamos primeiro criar uma função para verificar o processo que está em execução verificando se o executável selecionado está em execução, para isso verificaremos no gerenciador de tarefas, que é o responsável por suprir as informações das condições dos softwares ativos. Primeiro vamos criar uma procedure para verificar o processo function VerificaProcesso (NomeExecutavel: string): Boolean; Nessa função vamos passar na função uma String que tem, no caso, o nome de NomeExecutavel, pois será informado o nome que será verificado pelo gerenciador de tarefas, além do retorno, que será do tipo boolean. Vamos agora declarar 3 variáveis, uma que será utilizada para verificar a necessidade de repetir a verificação dos processos, uma que irá fazer o mapeamento de processo por processo e execução e uma ultima variável que irá armazenar o nome do processo procurado, que será o nome 16 setembro 2011

17 do executável do projeto var ContinueLoop: BOOL; Mapear: THandle; Processo: TProcessEntry32; Primeiro faremos a utilizaremos a variável Mapear, que é do tipo THandle para armazenar todos os processos em execução e armazenar para consulta dos registros contidos através da função nativa do Windows CreateToolhelp32Snapshot e através do parâmetro dwflag TH32CS_SNAPPROCESS começando a listagem do zero. Mapear:= CreateToolhelp 32Snapshot(TH32CS_ SNAPPROCESS, 0); Logo após utilizaremos a variável Processo, que é do tipo TProcessEntry32 para que seja encontrado o executável pelo nome comparando o que foi passado pelo sistema com o qual está executando nos processos Processo.dwSize:= SizeOf(Processo); E, para que, caso não seja encontrado o processo verificado não seja idêntico ao nome do processo com o nome informado, deve ser dado continuidade nas buscas, para isso utilizaremos a variável ContinueLoop, que receberá o comparativo entre o que é executado e o que precisa ser encontrado ContinueLoop:= Process32 First(Mapear, Processo); E, caso, como já foi visto ainda não tenha sido encontrado o processo, a verificação deve se dar continuidade ao próximo registro, até que seja identificado, e caso não tenha, que pelo menos tenha sido verificado em todos os processos, garantindo que tenha sido feita uma varredura completa dos processos executados. while Integer(ContinueLoop) <> 0 do begin if ((ExtractFileName(Processo. szexefile) = NomeExecutavel) or (Processo.szExeFile = NomeExecutavel)) then begin Result:= True; end; ContinueLoop:= Process32Next(Mapear, Processo); E por fim feche a verificação dos processos com a função CloseHandle CloseHandle(Mapear); Após ter sido feita toda a cobertura dos registros verificando se há algum processo que faça referencia explicita de que o executável está ativo, vamos chamar a função que irá inserir a DLL ao executável do processo, para essa função utilizaremos 6 variáveis, sendo 3 do tipo Cardinal, e uma do tipo Pointer, String e DWORD cada. var IDProcess: DWORD; DLL: String; KernelPonteiro: Pointer; KernelProcesso, ContagemBytes, EncadeamentoRemoto: Cardinal; A Variavel IDProcess armazenará a ID do processo que será executado, a variável DLL receberá o caminho da dll, a variável KernelPonteiro que irá registrar em qual ponto da memória esta alocado o processo executado, a variável KernellProcesso que servirá para armazenar o processo desejado que está no kernel da memória, a variável ContagemBytes que irá armazenar a contage de bytes e a variavel EncadeamentoRemoto, que será responsável por integrar a dll externa ao processo interno do executável. Utilizaremos primeiro a variável DLL para que retorne o caminho da DLL que será chamada pelo Edit1 DLL:= Edit1.Text; Em seguida faremos uma verificação se o processo do executável existe e foi encontrado, caso tenha sido encontrado ele verificará se a dll existe, caso também exista ele ira verificar se o processo da dll também existe e foi encontrada, fazendo assim, o resgate da Kernel do processo e do ponteiro, escrevendo o processo na memória criando o handle que fará com que a dll seja incorporada no executável e, por fim, fechar o handle if VerificaProcesso (PChar(Edit2.Text), IDProcess) then begin if FileExists(DLL) then begin VerificaProcesso (PChar(Edit1.Text), IDProcess); KernelProcesso:= OpenProcess (PROCESS_ALL_ ACCESS, False, IDProcess); KernelPonteiro:= VirtualAllocEx (KernelProcesso, nil, length(dll), MEM_COMMIT, PAGE_EXECUTE_READWRITE); WriteProcess setembro

18 Memory(KernelProces so, KernelPonteiro, PChar(DLL), Length(DLL), ContagemBytes); CreateRemoteThread( KernelProcesso, nil, 0, GetProcAddress (GetModuleHandle ( kernel32. dll ), LoadLibraryA ), KernelPonteiro, 0, EncadeamentoRemoto); CloseHandle (KernelProcesso); ShowMessage ( DLL Inserido com sucesso! ); End Caso não tenha sido obtido sucesso na execução será retornada a exceção com a mensagem avisando que não foj possível inserir a dll no executável Caso seja no evento OnClick do botão para procurar o executável utilizamos: OpenDialog1.Filter:= Executável *.exe ; if OpenDialog1.Execute then Begin Edit2.Text:= OpenDialog1.FileName; end; O resultado estético deve ser parecido com esse: Conclusão E concluímos nosso exemplo demonstrando a utilidade de se termos boas praticas de utilização das dll s, já que podem ser aproveitadas em muitas outras linguagens e como ela trabalha com o arquivo executável, sendo de importante função na programação em muitos casos, até de comunicação com o banco de dados, que sem ele instalado é por meio das dll s que exercem esta função de comunicação, porém lembrando que nossa intenção jamais é divulgar ou incentivar a pirataria e/ou seus meios, a intenção deste artigo é mostrar neste artigo que podemos utilizar um meio para inserir a dll em um executável para que possa ter múltiplos comportamentos para sem que seja feita alguma alteração no código-fonte do sistema, dando assim, versatilidade e simplicidade aos executáveis. else begin ShowMessage( DLL não pode ser inserida! ); end; end; E por fim, mais para a parte estética e aproveitamento do componente utilizaremos para o mesmo OpenDialog dois filtros distintos, para melhor aproveitamento do componente. Sobre o autor Eduardo Massud Consultor Técnico The Club. No evento OnClick para procurar a DLL utilizaremos: eduardo@theclub.com.br OpenDialog1.Filter:= Arquivo DLL *.dll ; if OpenDialog1.Execute then Begin Edit1.Text:= OpenDialog1.FileName; end; 18 setembro 2011

19 setembro

20 Delphi XE2 Novidades Neste mês de setembro, tivemos o lançamento da nova versão do Delphi intitulada XE2. Essa nova versão está inclusa no pacote RAD Studio XE2, que também traz as ferramentas Delphi Prism, RAD PHP e C++ Builder. Essa nova versão do Delphi traz, além de melhorias e incrementos em tecnologias e ferramentas já existentes, algumas novidades importantes. Nesse artigo estarei mostrando uma visão geral das principais novidades que acompanham o Delphi XE2. FireMonkey A novidade mais aguardada pela comunidade Delphi para essa nova versão sem dúvida é o FireMonkey. O FireMonkey é um novo framework visual, assim como a VCL, que permite a criação de aplicações com maior riqueza visual, além de ser compatível com o desenvolvimento de aplicativos para Windows 64 bits além de 32 bits, já existente e Mac OS e ios (base operacional dos tablets Apple). Uma comparação válida a respeito do FireMonkey é com a WPF do.net, que trouxe para a plataforma.net uma maior gama de recursos visuais aos desenvolvedores. Com o FireMonkey, uma grande gama de novos componentes visuais foi agregada ao Delphi, já que muitos dos componentes visuais do Delphi são baseados na API Windows. Como agora a compilação para Mac e ios se faz necessária, esses componentes baseados em API não podem ser utilizados nessas novas plataformas. Com o FireMonkey, também é possível a integração de elementos 3D em nossos aplicativos, não nos deixando limitados a visual 2D. É possível também a colocação de recursos animados nas janelas, além do que as próprias janelas do Fire- Monkey podem ser animadas. 20 setembro 2011