Usando o Visual Studio 2005 para criar interfaces do usuário e dados para aplicativos de dispositivos

Por Maarten Struys - PTS Software bv OpenNETCF.org

Novembro de 2005

Aplica-se a:

• Microsoft Visual Studio 2005

• Microsoft .NET Compact Framework versão 2.0

• Windows Mobile versão 5.0

• Pocket PCs baseados no Windows Mobile

• Microsoft Windows CE

Resumo: Aprenda sobre o que há de novo no Visual Studio 2005 com relação à interface do usuário e banco de dados para uso de aplicativos .NET Compact Framework versão 2.0. Este artigo apresenta você ao novo ambiente de desenvolvimento—especificamente ao novo Windows Forms Designer que integra o Visual Studio 2005. Você terá também um passeio guiado pelos novos controles simplificados disponíveis no Visual Studio 2005, e aprenderá como é fácil criar aplicativos que oferecem suporte aos modos de retrato e paisagem usando esses controles. O Visual Studio 2005 ajuda você a focar vários dispositivos. Você aprenderá também a usar um formulário de herança e a reutilizar e estender formulários existentes. Como a maior parte dos aplicativos móveis de linha de negócios também precisam armazenar e acessar dados, você aprenderá, igualmente, a usar o novo designer de dados no Visual Studio 2005 para criar e preencher um banco de dados do SQL Server 2005 Mobile Edition. Da mesma forma, neste artigo, você descobrirá como criar um banco de dados local e como usá-lo em um aplicativo simples. (36 páginas impressas).

Baixe o artigo Using_VS2005_to_Design_User_Interfaces_and_Databases_for_Device_Applications.msi (em inglês) do Microsoft Download Center.

Nesta página

Introdução
Criando uma interface simples de usuário para Pocket PC baseado em Windows Mobile 5.0
Encaixando e ancorando controles
Controle do Splitter (separador de saída)
Configurando a ordem de tabulação
Alterando fatores de formulários de dispositivos
Alterando a plataforma de destino
Herança do Visual Form
Trabalhando com ferramentas do banco de dados do Visual Studio
Conclusão

Introdução

A cada nova versão do Visual Studio aumenta a produtividade do desenvolvedor, porque as ferramentas de criação visual tornam-se mais sofisticadas e mais código é gerado para os desenvolvedores. Esse código tem uma grande vantagem porque não é necessário se concentrar em escrever todos os tipos de códigos de direcionamento. Em vez disso, é possível concentrar-se quase inteiramente na funcionalidade que é necessária para o aplicativo. Como há diversos dispositivos no mercado, todos com fatores de formulários diferentes, é essencial possuir ferramentas de design de interface do usuário que demonstrem o que prometem e que correspondam ao máximo possível à interface do usuário final. À medida que mais e mais aplicativos são requeridos para armazenar localmente significativas quantidades de dados em dispositivos, a habilidade de criar virtualmente tabelas e bancos de dados para bancos de dados do SQL Server Mobile em ambientes de desenvolvimento irá ajudá-lo. O Visual Studio 2005 oferece excelentes ferramentas de criação que facilitam muito o trabalho envolvido na criação de interfaces de usuário e de dados.

Ao ler este artigo, você descobrirá que é possível criar interfaces de usuário que podem alternar entre modos de retrato e paisagem sem que seja necessário escrever instruções de linha de código. Quando um aplicativo que usa vários formulários é criado, cada um com uma série de características comuns, é possível usar a herança de formulário com suporte completo para designer a fim de limitar a quantidade de código que deve ser fornecido a cada formulário individual. Finalmente, quando um banco de dados local é usado no aplicativo, é possível criar o banco de dados e até preenchê-lo usando as ferramentas de designer do Visual Studio 2005.

Criando uma interface simples de usuário para Pocket PC baseado em Windows Mobile 5.0

Para iniciar o desenvolvimento de um novo aplicativo de dispositivo, é preciso criar primeiramente um projeto novo no Visual Studio 2005. O projeto deve ser um Smart Device em C# ou Visual Basic .NET que se destina a um Pocket PC executado no Windows Mobile versão 5.0. Embora não relevante para o próprio Windows Forms Designer, todos os exemplos de códigos são apresentados em C# por todo este artigo. No entanto, todos os exemplos de códigos estão disponíveis no Visual Basic .NET para download.

Quando você cria um novo aplicativo de dispositivo, o Visual Studio 2005 apresenta um formulário vazio com as dimensões corretas do dispositivo de destino—inclusive uma capa de dispositivo para corresponder tão perto quanto possível ao dispositivo real. Ao usar a caixa de ferramentas Device Controls exibida na Figura 1, é possível arrastar controles para o formulário do aplicativo.

Figura 1. Visual Studio 2005 Modo de exibição do designer

Se você comparar o número de controles de dispositivos da caixa de ferramentas com o número de controles de dispositivo do Microsoft Visual Studio .NET 2003, verá que há muito mais controles disponíveis no Visual Studio 2005. Se não estiver familiarizado com os novos controles, a melhor coisa a fazer é criar um aplicativo simples utilizando os controles novos, observar cada uma das propriedades de controle e estudar seus comportamentos. Naturalmente, você deve também procurar o controle específico na ajuda online. Quando a interface do usuário começa a ser criada, algo que imediatamente chama a atenção é como o Windows Forms Designer auxilia no alinhamento de controles e sugere uma distância mínima entre controles. A exibição automática de instruções, como mostrado na Figura 2, ajuda enormemente na criação de uma interface do usuário bem-organizada em pouco tempo.

Figura 2. As instruções ajudam você a esquematizar a sua interface do usuário

Encaixando e ancorando controles

Para assegurar que um formulário seja exibido da maneira correta em ambos os modos de retrato e paisagem, é possível encaixar e ancorar controles em um local especificado no recipiente. Há uma diferença sutil, embora importante, entre encaixar e ancorar. Quando se ancora um controle em uma ou mais margens de um recipiente, é preciso certificar-se de que a posição relativa da margem ancorada seja mantida quando a orientação do vídeo do dispositivo for alterada. No momento em que encaixa um controle, você especifica a margem do recipiente contra a qual o controle será posicionado. É possível também especificar que um controle deva ser encaixado em todas as margens, significando que o controle preencherá todo o estado real do recipiente. Um recipiente é um conjunto de controles, ou, em outras palavras, o genitor de um controle. Por exemplo, se um recipiente pode ser o formulário inteiro, podem também ser um GroupBox ou Painel.

Para mostrar a diferença entre ancoragem e encaixe e mostrar o comportamento dos controles ancorados e encaixados em diferentes orientações de exibição, é possível criar uma interface simples de usuário que contenha uma série de controles de rótulos—cada um com uma cor de plano de fundo diferente—bastando, em seguida, observar o comportamento das alterações de ancoragem, encaixe e orientação. O design da interface do usuário não tem significação particular, porém ajuda a entender a diferença entre encaixe e ancoragem. Mostra também o impacto da alteração de modo retrato para modo paisagem. Suponha que você tenha criado uma interface do usuário que se pareça com a Figura 3.

Figura 3. Pocket PC em modo retrato com uma interface do usuário que possui rótulos e um painel que não são nem encaixados nem ancorados

Os três rótulos superiores são hospedados em um painel, e dois rótulos inferiores que são hospedados no próprio formulário. Com relação a todos os controles adicionados ao formulário é necessário assegurar a remoção explícita da ancoragem. O comportamento padrão do Visual Studio 2005 é ancorar todos os controles no alto e à esquerda das margens ou de seus recipientes de hospedagem. A interface do usuário parece bem no modo retrato, porém quando você troca a orientação para modo paisagem, ocorrem problemas, como mostrado na Figura 4.

Figura 4. Pocket PC em modo paisagem com uma interface do usuário que possui controles não encaixados nem ancorados

É possível notar de imediato que nem todos os rótulos que aparecem no modo retrato são visíveis no modo paisagem. Parte do painel, inclusive o label1, permanece fora da tela. Igualmente, o label5 desaparece da tela, e os lados direito e esquerdo do vídeo não são preenchidos no modo paisagem. Parece que o modo paisagem exibe meramente parte da interface do usuário em modo retrato.

Para revolver o problema sem ter que escrever o código real, é possível usar o encaixe e a ancoragem, que são novos nos aplicativos do .NET Compact Framework 2.0. Basta simplesmente ancorar um controle a ou mais margens da tela, configurando a propriedade Anchor. A ancoragem de um controle significa que a posição relativa da margem ancorada sempre permanece a mesma—independentemente da orientação da exibição. Por meio da propriedade Dock é possível especificar como um controle particular se alinha à margem de seu controle-pai, ou como preenche uma área da tela. O encaixe de vários controles com a mesma margem de controle-pai faz com que os controles se empilhem. Se você observar a Figura 5, verá que há algumas diferenças da Figura 3. No entanto, dessa vez os controles estão ancorados e encaixados.

Figura 5. Pocket PC em modo retrato com uma interface do usuário que possui controles encaixados e ancorados

Na Figura 5, os rótulos descrevem como são encaixados. Os três rótulos superiores são todos de propriedade de um painel de controle. O rótulo mais alto não é encaixado, mas é ancorado nas margens esquerda, superior e direita do painel de controle, que, por sua vez, é encaixado no alto do formulário. Independentemente da orientação de exibição, a distância entre as margens esquerda, superior e direita e o rótulo será a mesma. O rótulo é redimensionado quando a interface do usuário é exibida em modo paisagem. Os outros dois rótulos dentro do painel de controle são exibidos um sobre o outro, ambos sendo encaixados na parte inferior do controle do painel. A ordem de tabulação determina a forma em que esses rótulos são exibidos. Se você alterar a orientação da exibição para modo paisagem, todos os controles do formulário permanecerão visíveis, e toda a extensão do formulário é usada para preencher os controles, como mostrado na Figura 6.

Figura 6. Pocket PC em modo paisagem com uma interface do usuário que possui controles encaixados e ancorados

A interface do usuário mostrada na Figura 6 parece muito melhor do que a que é mostrada na Figura 4 porque os controles individuais foram redimensionados para exibição adequada em paisagem. Para perceber verdadeiramente como o encaixe e a ancoragem influenciam a posição dos controles em ambos os modos retrato e paisagem, despenda algum tempo experimentando-os.

No Visual Studio 2005, é muito fácil exibir a interface do usuário em ambos os modos de orientação—mesmo na exibição do Designer. Para alterar a orientação do dispositivo na exibição do Designer, selecione simplesmente todo o formulário (clicando com o botão direito do mouse em qualquer lugar no formulário onde não haja controles, clicando com o botão direito do mouse na barra de títulos do formulário ou clicando na capa do dispositivo e selecionando Select <nome de classe do formulário>) no menu de atalho. Se você possuir apenas um único formulário em um aplicativo e se usar o nome padrão que o Visual Studio 2005 atribui àquele formulário, o <nome de classe do formulário> será Form1. Quando todo o formulário tiver sido selecionado, o menu de atalho que é exibido quando se clica com o botão direito do mouse no dispositivo conterá diferentes entradas, inclusive Rotate Left e Rotate Right. É possível usá-las para alterar a orientação da exibição, como mostrado na Figura 7. Por outro lado, após selecionar todo o formulário, use os botões da barra de ferramenta para alterar a orientação.

Figura 7. Alterando a orientação da exibição no vídeo do modo de exibição do Designer

Controle do Splitter (separador de saída)

Um dos novos controles disponibilizados com o .NET Compact Framework 2.0 não é totalmente auto-explicativo e não é óbvio quanto ao uso. É possível usar o novo controle de Splitter em combinação com os controles encaixados para alterar a dimensão desses controles durante o tempo de execução, de forma semelhante ao controle de separador de saída do .NET Framework total.

No momento da criação, é possível adicionar os controles do Splitter e ser capaz de definir suas dimensões. A ordem em que os controles encaixados e os controles Splitter são adicionados ao formulário determina em quais controles encaixados um controle do Splitter operará, e também determina a forma em que o controle de Splitter é mostrado ao usuário. Segundo a ajuda online do Visual Studio, o controle do Splitter permite redimensionar o controle encaixado localizado imediatamente antes na ordem de encaixe. Em função de haver como definir de forma manual a ordem de encaixe, é preciso adicionar um controle de Splitter imediatamente após a adição do controle de encaixe que você deseja redimensionar. É também necessário certificar-se de encaixar o controle de Splitter às margens do controle encaixado a ser redimensionado, como mostrado na Figura 8.

Figura 8. Controles de Splitter na exibição do Designer

A interface do usuário da Figura 8 é criada da forma que se segue. Todas três caixas de imagens são adicionadas ao formulário, seqüencialmente, e encaixadas na parte superior e à direita do formulário. A última caixa de imagem, mostrada na parte inferior esquerda do formulário, na Figura 8, é encaixada para preencher. Após criar as caixas de imagens, dois separadores são soltos na caixa de imagem inferior esquerda e encaixados respectivamente na parte superior e à direita dessa caixa de imagem.

Olhando a interface do usuário na exibição do Designer, é possível imaginar que a caixa de imagem do lado direito do formulário só pode ser redimensionada na direção horizontal, e que a caixa de imagem do lado esquerdo pode ser redimensionada tanto na direção horizontal como vertical. No entanto, como se pode ver na Figura 9, quando o separador de saída horizontal é movimentado, todos os controles são modificados de acordo com a localização do separador. Esse comportamento é causado pelo fato de a caixa de imagem inferior direita ser encaixada na margem direita do formulário—tentando ocupar sempre tanto espaço quanto houver disponível na margem direita do formulário. Esse exemplo demonstra que os controles que não são imediatamente associados ao separador podem ainda assim afetar seus tamanhos. Embora esse exemplo seja útil para demonstrar a relação entre as barras do separador e os controles encaixados, não é recomendável criar uma interface do usuário com tal complexidade de comportamento.

Figura 9. Controles encaixados de redimensionamento por meio de controles de Splitter

Para fornecer aos usuários uma melhor indicação visual sobre a maneira pela qual os controles de Splitter afetam os controles encaixados, considere a ordem em que você encaixa controles. Adicione um controle de Splitter que tenha suporte para funcionar em um controle encaixado antes de adicionar outros controles com áreas de encaixe comum, como mostrado na Figura 10.

Figura 10. Controles de Splitter na exibição do Designer criados imediatamente após os controles encaixados que necessitavam de redimensionamento

Ao se criar a mesma interface do usuário em uma ordem diferente, é possível constatar a diferença. O controle de Splitter horizontal é criado imediatamente após a criação da caixa de imagem superior. Em seguida, a caixa de imagem direita foi criada, sendo seguida pelo controle de Splitter vertical e, finalmente, a última caixa de imagem foi criada. Embora o comportamento de redimensionamento durante o tempo de execução não tenha se alterado, a ordem em que as caixas de imagens e separadores foram criados se alterou, o que dá aos usuários uma idéia muito melhor de como os separadores efetuam o redimensionamento de diferentes controles, como mostrado na Figura 11.

Figura 11. Redimensionamento de controles encaixados usando controles de Splitter criados na ordem correta

Configurando a ordem de tabulação

Para determinar o controle que obtém foco, em outras palavras, o controle que aceita entrada de teclado, a ordem de tabulação é utilizada. É denominada ordem de tabulação porque é possível alterar o foco de controle para controle, usando-se a tecla TAB do teclado (mesmo em um painel virtual disponibilizado com o Pocket PCs).

No Visual Studio .NET 2003, a ordem de tabulação desses controles que podia aceitar entradas de teclado era mais ou menos fixa. A ordem de tabulação refletia a ordem em que os controles eram criados durante o tempo de criação e não podia ser alterada sem exclusão ou nova adição de controles em uma ordem diversa. No Visual Studio 2005 é possível alterar a ordem de tabulação após criar todos os controles da interface do usuário, o que oferece mais flexibilidade, uma vez que passa a ser desnecessário considerar a ordem de tabulação durante a criação da interface do usuário. Por exemplo, observe a Figura 12, que é um projeto da Exibição do Designer com a ordem de tabulação original.

Figura 12. Ordem de tabulação original

O projeto possui uma interface do usuário simples, só usada para fins de demonstração. Os controles do formulário foram criados em uma ordem particular. O botão foi criado primeiramente, seguido pelo controle de DateTime, e, ao final, foram criadas as duas caixas de texto. A ordem em que os controles foram criados determina a ordem de tabulação inicial. Ao clicar no botão Tab Order na barra de ferramentas de layout, circulado na Figura 12, é possível exibir e modificar a ordem de tabulação.

Se você deixar a ordem de tabulação desse aplicativo particular como está, verá que navegar pelos controles durante a execução do aplicativo não é a melhor experiência. Inicialmente, o foco de entrada é definido para o botão da interface do usuário. Pressionar a tecla TAB altera o foco de entrada para o controle de DateTime. Pressionar a tecla TAB novamente altera-a para tBox1 e, finalmente, para tBox2. Seria mais natural se o usuário navegasse por todos os controles de baixo para cima. No Visual Studio .NET 2003, permitir que um usuário navegue de cima da interface do usuário para baixo só pode ser conseguido pela criação de controles na ordem em que se deseja que o usuário navegue.

No Visual Studio 2005, quando o botão Tab Order da barra de ferramentas de Layout é selecionado, é possível clicar simplesmente em cada controle que possua o recurso de receber foco de entrada para alterar sua ordem de tabulação. Isso implica simplesmente adicionar controles a um formulário sem ter que pensar sobre a ordem de tabulação porque é possível modificar a ordem de tabulação mais tarde, como se pode ver na Figura 13.

Figura 13. Ordem de tabulação modificada na Exibição do Designer

Agora, quando o aplicativo é executado, é possível ver que navegar pelos controles é mais natural porque o foco de entrada se altera em cada um dos controles, a começar pela parte superior da interface do usuário, funcionando para baixo. É igualmente possível configurar a ordem da tabulação de controles individuais utilizando a propriedade TabIndex. É possível especificar também se o usuário pode navegar para um controle com a tabulação, no formulário, definindo a propriedade TabStop. Essas propriedades são implementadas apenas para aqueles controles que podem aceitar entrada de teclado.

Alterando fatores de formulários de dispositivos

O Pocket PC original possuía uma resolução de tela de 240 x 320 pixels. Uma série de Pocket PCs disponíveis hoje possuem resoluções de tela diferentes ou até telas quadradas. Para assegurar que o aplicativo funcione bem em todos esses dispositivos, configure a propriedade FormFactor. A propriedade FormFactor é somente um valor de tempo de design. Em outras palavras, não influencia a própria aplicação. É possível usar a propriedade FormFactor para definir uma série de dimensões de telas diferentes para um dispositivo, para poder verificar se a interface do usuário é mostrada adequadamente em dispositivos com diferentes fatores de formulários durante o tempo de design. Como você pode ver, a Figura 14 mostra um editor de texto simples que é executado em um Pocket PC. Se você examinar o baixar código de exemplo, poderá apreciar a sofisticada funcionalidade disponibilizada para você ao escrever código gerenciado por meio do .NET Compact Framework 2.0. A funcionalidade total desse editor de exemplo contém 30 linhas de código-fonte, incluindo a possibilidade de abrir arquivos existentes e de salvar arquivos. Naturalmente, esse exemplo é muito limitado em funcionalidade e não fornece verificação ortográfica ou gramatical, nem a funcionalidade editorial normal, como Localizar e Substituir, mas o exemplo é totalmente funcional.

Figura 14. Aplicativo de Pocket PC com interface do usuário de editor de texto simples

Suponha que você deseje executar esse aplicativo em um Pocket PC com dimensões de tela quadrada. Graças aos controles ancorados, é muito fácil manter a mesma interface do usuário sem ter que escrever código algum. A nova propriedade de tempo de design somente, FormFactor, permite que se verifique a aparência do aplicativo dentro do designer do Visual Studio 2005. Como se pode ver pela Figura 15, uma nova capa é exibida e a interface do usuário do aplicativo se ajusta de acordo com o novo fator de formulário de dispositivo.

Figura 15. Aplicativo de Pocket PC com interface do usuário de editor de texto simples exibida usando o fator de formulário de tela quadrada

É fácil alterar fatores de formulário no Visual Studio 2005. O aplicativo não precisa nem ser recompilado. Acima de tudo, o dispositivo ainda é um dispositivo de Pocket PC, de modo que ainda é possível usar todos os controles específicos de Pocket PC. A única coisa que se altera é o layout dos formulários no tempo de design.

Mas, e se você quiser mudar para um dispositivo completamente diferente? Imagine que você deseje usar o mesmo aplicativo em um dispositivo de Smartphone.

Alterando a plataforma de destino

Não havia suporte para a alteração da plataforma de destino de um aplicativo particular, na verdade, no Visual Studio .NET 2003. Por exemplo, quando você criava um aplicativo para um Pocket PC, não havia suporte no Visual Studio .NET 2003 para alterar o projeto para que se destinasse a um Smartphone. A melhor abordagem era separar toda a lógica comercial da lógica de interface do usuário, reutilizar a lógica comercial para a nova plataforma de destino e, em seguida, recriar a interface do usuário.

No Visual Studio 2005 é possível alterar a plataforma de destino. Naturalmente, do ponto de vista de um desenvolvedor de software, ainda é boa idéia separar a lógica comercial da lógica da interface do usuário, mas o redestinamento para uma plataforma diferente usando o Visual Studio 2005 torna você mais produtivo quanto à modificação da interface do usuário do aplicativo para que ela ofereça suporte a vários tipos de hardware. De fato, quando você altera uma plataforma de destino, somente a interface do usuário é alterada. Todos os outros aspectos do aplicativo produzidos pelo projeto são os mesmos. Como vários controles que estão disponíveis em Pocket PCs não estão disponíveis em Smartphones, o designer converte esses controles nas alternativas mais aproximadas disponíveis em Smartphones.

Com o Visual Studio 2005 é possível alterar a plataforma de destino de um projeto particular. O designer irá ajudar ao máximo na conversão da interface do usuário para atender aos requisitos da nova plataforma de destino. É possível alterar para uma nova plataforma de destino no Visual Studio 2005 selecionando Change Target Platform no menu Project. Quando você seleciona esse comando, uma caixa de diálogo mostra a plataforma de destino atual e uma lista da qual é possível selecionar uma plataforma de destino, como mostrado na Figura 16.

Figura 16. Alterando a plataforma de destino do Pocket PC para Smartphone

Após clicar em OK, o Visual Studio irá alterar o projeto de destino para você. No processo, fecha e abre novamente o projeto. A diferença é que o designer de formulário agora apresenta o aplicativo com fatores de formulário de Smartphone. O Visual Studio não alterou nenhum código e todos os controles originais ainda estão disponíveis no formulário, porém pode ser necessário redimensioná-los para adaptá-los à tela menor de um Smartphone.

A Figura 17 mostra uma série de controles que não têm suporte em Smartphones. É possível diferenciar controles que não são têm suporte pela plataforma de destino, porque eles aparecem no formulário com um aviso de advertência (um triângulo com um sinal de exclamação) e suas propriedades são bloqueadas. O Visual Studio 2005 pode ajudar você a converter controles sem suporte em controles com suporte. Ao selecionar um controle sem suporte no formulário e clicar na seta mostrada na parte superior do controle, um menu pop-up é exibido com controles que têm suporte e que têm funcionalidade comparável ao de controles sem suporte. No caso desses botões, como mostrado na Figura 17, o Visual Studio ajuda a convertê-los tanto em caixas de texto como em itens de menu. Se você alterar um botão de um item de menu, o item de menu será bloqueado para o evento original button_Click, significando que o item de menu obtém a mesma funcionalidade do botão em um Pocket PC. Na Figura 17 é igualmente possível observar que os controles SaveFileDialog e OpenFileDialog não têm suporte em um Smartphone. No entanto, esses componentes são diferentes de botões—não há conversão simples desses componentes em controles de Smartphone alternativos, de modo que é preciso realizar algum trabalho para alterá-los. Em baixar código de exemplo, a coisa mais provável a fazer seria providenciar suas próprias caixas de diálogo para abrir e salvar arquivos. Em baixar código de exemplo, essas caixas de diálogo não estão implementadas, mas espera-se que se capte a idéia.

Figura 17. Aplicativo de Pocket PC que foi convertido em aplicativo de Smartphone

Após todos os botões serem convertidos em itens de menu, e quando os componentes OpenFileDialog e SaveFileDialog forem removidos, basta simplesmente criar e executar o projeto. Como se pode ver pela Figura 18, o mesmo aplicativo agora é executado em um Smartphone. Alterar a plataforma de destino é uma ação irreversível. Embora o Visual Studio não altere o código do aplicativo, fará alterações no layout da interface do usuário.

Figura 18. O editor de texto simples executado presentemente em um Smartphone

Ainda que seja preciso realizar algum trabalho para alterar um aplicativo em um dispositivo de destino diferente, a quantidade de trabalho é, na maioria dos casos, menor do que o trabalho que se teria ao criar uma interface do usuário inteira para um outro dispositivo de destino.

Herança do Visual Form

Nos últimos anos, vários desenvolvedores de dispositivo solicitaram suporte visual para herança de formulário. No Visual Studio .NET 2003, a herança de formulário não tem suporte em projetos de dispositivo inteligente, embora—sendo criativo—você possa usar o pré-processador C# de compilação condicional para oferecer-lhe uma quantidade particularmente limitada de suporte de designer ao herdar um formulário de outro formulário. O Visual Studio 2005, por outro lado, fornece um suporte total de designer para a herança de formulário visual. Trata-se de uma grande adição, que lhe permite reutilizar e estender formulários sem necessidade de iniciar continuamente a criação de novos formulários do começo.

Para exibir a herança de formulário visual, comece com um formulário básico, simples, que você pode usar mais tarde para produzir outros formulários. Embora não seja absolutamente necessário, faz muito sentido criar uma biblioteca de classe separada para manter o formulário básico. Um formulário básico criado como parte de um projeto é um candidato sem valor para uso em aplicativos diferentes. Além disso, o designer de formulário do Visual Studio precisa ser capaz de ler metadados do formulário básico antes de poder exibir um formulário derivado dele, significando que será necessário fazer uma compilação a mais antes de poder usar o formulário básico para herança se o formulário básico integrar o mesmo projeto do formulário derivado. Criar o formulário básico em uma biblioteca separada torna isso desnecessário.

É importante pensar de forma antecipada no formulário básico. Você deve saber em especial quais controles podem ser modificados em formulários herdados e quais controles não podem. Para ser capaz de modificar controles ou comportamentos de controle, é preciso certificar-se de definir o modificador de acesso de um controle particular como algo que não seja private. Não é possível alterar propriedades de um controle privado em um formulário derivado. A Figura 19 mostra um formulário básico simples que se pode usar mais tarde em um aplicativo.

Figura 19. Formulário básico armazenado em uma biblioteca de classe separada

O formulário básico contém um botão privado que executa a mesma ação em todo formulário derivado quando é clicado. Como esse botão é private, nem o botão nem seus membros são acessíveis no formulário derivado. O formulário básico também contém um botão protegido com um manipulador de eventos implementado como método virtual. Exatamente como qualquer outro método virtual, o manipulador de eventos pode ser substituído em formulários derivados individuais. Pelo fato de o segundo botão ser protegido, tanto o botão como seus membros são acessíveis no formulário derivado. É possível até mesmo optar por criar um manipulador de eventos de clique separado no formulário derivado, que resulte na execução de ambos os manipuladores de evento de formulário derivado e de formulários básicos. Finalmente, o formulário básico também contém um rótulo protegido, significando que o rótulo pode ser acessado de todos os formulários derivados. Observe que o formulário básico da Figura 19 não contém um menu. Por padrão, o designer cria um controle de menu denominado mainMenu1 em todo formulário recém-criado. É possível ter um menu no formulário básico e até mesmo estendê-lo no formulário derivado. No entanto, seja cuidadoso na remoção do menu do formulário derivado e defina as propriedades de acesso do menu na classe básica para Protected ou Public.

O formulário básico contém algumas funcionalidades comuns que serão compartilhadas entre formulários derivados, como mostrado no exemplo de código a seguir.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace BaseFormLibrary
{
    public partial class BaseForm : Form
    {
        public BaseForm()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            label1.Text = "Same action on all forms";
        }

        protected virtual void button2_Click(object sender, EventArgs e)
        {
            label1.Text = "Default action";
        }
    }
} 

O método BaseForm contém dois manipuladores de eventos de clique de botão. O manipulador button1_Click é um método private; não pode ser substituído. Implementar button1_click como private resulta sempre na execução da mesma ação em todo formulário derivado quando o button1 é clicado. No entanto, poderia ser possível criar o manipulador de eventos button1_Click como virtual protegido. Nesses caso, teria sido possível substituir o manipulador de eventos button1_Click em um formulário derivado—fornecendo-lhe a funcionalidade específica desse formulário particular.

Os modificadores do manipulador de eventos do button2_Click são mais interessantes. Embora o código gerado pelos Forms Designer tenham criado o manipulador de eventos button2_Click com um modificador de acesso private, é possível modificar a declaração do manipulador de eventos no arquivo de origem. Ao declarar o manipulador de eventos button2_Click como protegido e virtual, o mesmo pode ser substituído em formulários derivados, o que resulta na execução de seus manipuladores de evento quando button2 é clicado. Se o manipulador de eventos button2_Click não for substituído em um formulário derivado, o manipulador de eventos button2_Click do formulário básico será executado. Esse é exatamente o comportamento que se espera quando uma classe é produzida de uma classe básica. Como button2 é declarado protegido, há uma possibilidade a mais de não ser mostrado nos exemplos de códigos futuros. Com button2 declarado como protegido, um formulário derivado possui acesso para suas propriedades e eventos—inclusive para o evento de clique. Portanto, é também possível adicionar um outro manipulador de eventos ao evento de clique, o que resulta na execução de ambos o manipulador de evento de formulário básico e do manipulador de eventos de formulário derivado.

Para usar o formulário básico, é possível criar um novo projeto de dispositivo inteligente e adicionar uma referência ao conjunto de módulos (assembly) da BaseFormLibrary do mesmo. Quando se cria um novo projeto de dispositivo inteligente do tipo Aplicativo de dispositivo, o designer adiciona automaticamente um formulário ao projeto. Esse formulário é derivado de Sistema.Windows.Formulários.Formulários. Para produzir do formulário básico, adicione uma declaração using para o espaçodenome da "BaseFormLibary" ao arquivo de origem do formulário e, em seguida, basta modificar a declaração do formulário no código-fonte do formulário, por exemplo, quando se altera:

    public partial class Form1 : Form

para:

    public partial class Form1 : BaseForm

você produzirá o formulário no aplicativo do formulário básico anteriormente criado. Ao examinar o formulário na exibição de designer, observará todos os controles da classe básica e os controles adicionados especificamente a esse formulário particular, como mostrado na Figura 20.

Figura 20. Formulários derivados contendo controles do formulário básico com suporte total a designer

Os controles que foram colocados no formulário básico são herdados no formulário derivado. É possível observar que são herdados porque apresentam um símbolo no canto superior esquerdo, como mostrado na Figura 21.

Figura 21. O símbolo herdado

É igualmente possível ver que o botão mediano é um botão private para o formulário básico (significando que não pode ser substituído) porque possui um símbolo de bloqueio adicional no canto superior esquerdo. Da mesma forma, as propriedades do botão central são bloqueadas porque não podem ser modificadas no formulário derivado. É claro que é possível adicionar controles adicionais a um formulário herdado.

Na Figura 20, o primeiro botão é um botão novo que foi adicionado ao formulário herdado. O aplicativo inteiro, denominado VisualInheritance em baixar exemplo de código, consiste em dois formulários—ambos são herdados do formulário básico. O formulário principal substitui o manipulador de evento de clique de botão Overridable action para exibir o segundo formulário herdado. O segundo formulário não substitui o manipulador de evento de clique do botão Overridable action, de modo que clicar nele simplesmente executa o manipulador de evento padrão que é fornecido no formulário básico. No exemplo de código a seguir, é possível ver o código-fonte do formulário principal do aplicativo.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using BaseFormLibrary;

namespace VisualInheritance
{
    public partial class Form1 : BaseForm
    {
        public Form1()
        {
            InitializeComponent();
        }

        protected override void button2_Click(object sender, EventArgs e)
        {
            Form2 form = new Form2();
            form.ShowDialog();
        }
    }
}

Há várias coisas a serem observadas no exemplo de código anterior. Primeiramente, é possível ver que, observando a declaração de classe, o formulário é derivado de BaseForm. Em segundo lugar, o manipulador de eventos do button2 é substituído. Se desejar substituir a funcionalidade do manipulador de eventos por uma nova funcionalidade do formulário derivado, será preciso substituir o manipulador de eventos button2_Click em vez de anexar um novo manipulador de eventos ao mesmo. O código do Form2 é ainda mais simples, como se pode observar no exemplo de código a seguir. Só contém um manipulador de eventos para o button3 recentemente criado no formulário. Quando button1 ou button2 são clicados no Form2, os manipuladores de eventos encontrados no BaseForm são executados, como mostrado no exemplo de código a seguir.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using BaseFormLibrary;

namespace VisualInheritance
{
    public partial class Form2 : BaseForm
    {
        public Form2()
        {
            InitializeComponent();
        }

        private void button3_Click(object sender, EventArgs e)
        {
            label1.Text = "Local button clicked";
        }
    }
}

Agora, você talvez tenha uma boa noção de como usar a herança de formulário virtual em combinação com o designer de formulários do Windows. Naturalmente, é possível hospedar qualquer controle no formulário básico, desde que se deseje reutilizá-lo em formulários derivados. Certifique-se apenas de alterar a propriedade Modifiers do controle para protected ou public se desejar modificar o comportamento do controle particular em um formulário derivado. Com a propriedade Modifiers configurada com um valor diferente de private, é possível ocultar o controle, encaixá-lo ou redimensioná-lo em um formulário derivado.

Trabalhando com ferramentas do banco de dados do Visual Studio

SQL Server 2005 Mobile Edition (SQL Mobile) é o novo nome do SQL Server CE. Se pretende trabalhar com um banco de dados SQL Mobile, o Visual Studio 2005 lhe oferece alguns excelentes recursos. Pela primeira vez, é possível criar o seu próprio banco de dados no Visual Studio. Antes do Visual Studio 2005, só era possível criar um banco de dados SQL Server CE localmente em um dispositivo, tanto em código como usando a versão do QueryAnalyzer localizada no dispositivo. Com o Visual Studio 2005, o Visual Database Tools pode ser usado para criar o seu banco de dados. Você tem também o recurso de preencher o banco de dados com dados e criar datasets tipados.

Nesta seção você terá uma visão geral do trabalho com dados no Visual Studio 2005. Este artigo não fornece uma discussão completa sobre o trabalho com o SQL Mobile; limitando-se a mostrar as ferramentas de banco de dados do Visual Studio. No entanto, pondo tudo em perspectiva, você aprenderá a criar um banco de dados do SQL Mobile a partir do Visual Studio; como usar esse banco de dados em um aplicativo simples, e como criar datasets tipados para preencher controles usando ligação de dados.

Para criar um banco de dados do SQL Mobile no Visual Studio 2005, é possível usar o Server Explorer do Visual Studio 2005. É possível adicionar um novo banco de dados do SQL Mobile em um projeto existente, modificar o esquema de um banco de dados de SQL Mobile existente, preencher um banco de dados de SQL Mobile com dados, e examinar um banco de dados já implantado no dispositivo usando o ActiveSync versão 4.0.

Comece com um projeto novo e crie um banco de dados simples para usar no aplicativo. O banco de dados a ser criado será um banco de dados simples de uma coleção de DVDs. Para fins de exemplo, é muito simples; contém apenas títulos e categorias de DVDs. O banco de dados é feito de duas tabelas diferentes: DVD_Titles e DVD_Categories. Ao usar o Server Explorer, é possível criar localmente o banco de dados no seu computador de desenvolvimento. Mais tarde você descobrirá como adicionar o banco de dados ao projeto, de modo que seja implantado com o aplicativo para o dispositivo.

Há várias formas para se criar um banco de dados do SQL Mobile dentro do Visual Studio 2005. Para criar um banco de dados adicionando uma nova conexão de dados ao projeto, clique com o botão direito do mouse em Data Connections no Server Explorer e, em seguida, Add Connection, como mostrado na Figura 22.

Observação Se o Server Explorer ainda não estiver visível no Visual Studio 2005, abra-o clicando em View e, em seguida, clicando em Server Explorer no menu do Visual Studio 2005.

Figura 22. Adicionando uma conexão de banco de dados a um projeto de dispositivo inteligente

O Visual Studio exibe uma caixa de diálogo para adição da conexão, conforme mostrado no gráfico da Figura 23. Nessa caixa de diálogo, é possível anexá-la a um banco de dados de SQL Mobile existente ou criar um novo banco de dados. Assim que o dispositivo estiver conectado por meio do ActiveSync, é possível criar um banco de dados em um dispositivo conectado ou até anexá-lo a um banco de dados existente no dispositivo. Se estiver criando um banco de dados novo, crie-o localmente em primeiro lugar, no computador de desenvolvimento e, em seguida, implante-o no dispositivo como parte de seu aplicativo.

Figura 23. Criando um banco de dados novo e local no SQL Mobile por meio da caixa de diálogo Add Connection (esquerda) e da caixa de diálogo Create New SQL Server 2005 Mobile Edition Database (direita)

Na caixa de diálogo Add Connection, vá para um banco de dados existente ou crie um novo banco de dados. Ao clicar no botão Create, a caixa de diálogo Create New SQL Server 2005 Mobile Edition Database é exibida. Na Figura 23, o novo banco de dados é criado na pasta My Documents no computador desktop. Da mesma forma, nessa caixa de diálogo, há as opções de criptografar o banco de dados e de adicionar uma senha de segurança. Nesse artigo, a única coisa que você fará é especificar o nome do banco de dados MyDVDCollection. Ao clicar em OK, o Visual Studio 2005 cria o banco de dados. É possível verificar a conexão para o banco de dados clicando no botão Test Connection.

Assumindo que haja uma conexão em funcionamento, a seguir você criará tabelas no banco de dados. No Server Explorer, observe o banco de dados recentemente criado em Data Connections. Se expandir o banco de dados, encontrará uma entrada Tables. Para criar uma nova tabela, clique com o botão direito do mouse em Tables, e clique em Create Table, que exibe a caixa de diálogo New Table, como mostrado na Figura 24.

Figura 24. Criando uma tabela para adicionar a um banco de dados

É possível criar tabelas para adicionar ao banco de dados e definir os nomes, tipos de dados e outros atributos específicos de colunas da tabela particular. Após você clicar em OK, a nova tabela é adicionada ao banco de dados. É possível criar várias tabelas por meio dessa caixa de diálogo.

Até agora você não escreveu nenhuma linha de código para o aplicativo. Usou as ferramentas de designer de dados do Visual Studio para criar um banco de dados com uma série de tabelas. É possível inserir dados ao banco de dados recém criado de dentro do Visual Studio no Server Explorer. Para inserir dados na tabela, selecione e expanda o banco de dados em Server Explorer; expanda o nó Tables e clique com o botão direito do mouse na tabela para a Open, abrindo as tabelas individuais em Server Explorer e começando a adicionar-lhes dados, como mostrado na Figura 25.

Figura 25. Adicionando dados a uma tabela

Para usar um banco de dados recém-criado em um aplicativo, é necessário adicionar uma fonte de dados ao aplicativo. No Visual Studio 2005, selecione a entrada Add New Data Source no menu Data. Essa ação ativa o Assistente de configuração do Data Source, como mostrado na Figura 26.

Figura 26. Selecionar um tipo de fonte de dados usando o Assistente de configuração Data Source

A primeira página do assistente é usada para selecionar um tipo de fonte de dados. Esse tipo de fontes de dados indica se os dados serão recuperados de um banco de dados, serviço de Web ou objeto de aplicativo. Na Figura 26, o tipo de fonte de dados é um banco de dados. A seguir, é necessário optar pela conexão de dados. O assistente exibe as conexões existentes para sua escolha, como mostrado na Figura 27. É também possível criar uma nova conexão de dados no assistente. Se você precisar criar uma nova conexão de dados, clique no botão New Connection. Será necessário uma nova conexão quando não houver um banco de dados existente ou quando você estiver trabalhando com um banco de dados particular pela primeira vez. Esse botão abre a caixa de diálogo Add Connection, como mostrado na Figura 23. Como já há um banco de dados existente—MyDVDCollection—no computador de desenvolvimento, é possível selecionar esse banco de dados no Assistente de configuração do Data Source. O assistente pergunta se o banco de dados deve ser adicionado ao projeto atual, como mostrado na Figura 27. Se você clicar em Yes, o Visual Studio 2005 faz uma cópia do banco de dados, adiciona-a ao projeto e implanta-a no aplicativo quando o aplicativo for executado no Visual Studio 2005.

Figura 27. A mensagem solicita que você decida se o banco de dados escolhido deve ser adicionado à conexão

O Assistente de configuração do Data Source cria um dataset tipado que pode ser usado para ligar dados a controles no aplicativo. Há igualmente outras opções de ligação de dados disponíveis. No entanto, estão fora do alcance deste artigo. Assim, neste exemplo, você irá usar um dataset. Os datasets são objetos que contêm tabelas de dados em que são armazenados temporariamente os dados para uso no aplicativo. Quando um dataset é criado, o Visual Studio gera código para acessar dados no dataset, para editar dados no dataset e para transferir dados entre o banco de dados e o dataset, nos dois sentidos. Isso limita a quantidade de código que você deve escrever. Como esse aplicativo só mostra dados que já estão disponíveis no banco de dados, não é necessário escrever nenhum código. O aplicativo como um todo funciona com código gerado.

Finalmente, é necessário escolher quais objetos de banco de dados integrarão o dataset que o assistente criará em breve, como mostrado na Figura 28.

Figura 28. Escolha os objetos de banco de dados usando o Assistente de configuração do Data Source

Para disponibilizar todos os dados inseridos no dataset basta selecionar todas as tabelas. Após clicar em Finish, o assistente cria um dataset tipado que pode ser usado para exibir dados do banco de dados no aplicativo, que usa a ligação de dados para vincular itens de dados individuais aos controles da interface do usuário. O aplicativo que usar o banco de dados MyDVDCollection exibirá simplesmente uma lista de títulos de DVDs em um controle de grade de dados e uma relação pai-filho para exibir as categorias correspondentes.

É necessário definir a relação entre a tabela da lista que contém os títulos de DVDs e a tabela que contém as categorias do dataset. Outra vez, isso é algo que você pode fazer usando um designer do Visual Studio 2005, nesse caso o DataSet Designer, como mostrado na Figura 29.

Figura 29. DataSet Designer

É possível abrir o DataSet Designer clicando com o botão direito do mouse no arquivo MyDVDCollectionDataSet.xsd no Solution Explorer e, em seguida, escolhendo View Designer. Como alternativa, é possível abrir o DataSet Designer clicando com o botão direito do mouse em um dos itens que são visíveis no painel Data Sources e selecionando Edit DataSet with Designer, como mostrado na Figura 29. Se o painel Data Sources não estiver visível, abra-o selecionando Data Sources no menu Data.

No DataSet Designer, será exibida uma representação visual de tabelas que integram o dataset. Para criar uma relação entre diferentes tabelas, selecione um campo em uma das tabelas que combina as tabelas e, em seguida, arraste-o para outra tabela que necessita de participar da relação. Essa ação faz com que a caixa de diálogo Relation apareça. Nessa caixa de diálogo, especifique os campos que relativos às tabelas no dataset. Por este exemplo, DVDTitles é a tabela-pai, DVDCategories é a tabela-filho, e são relacionadas por meio do campo DVD_CategoryID, como se pode ver na Figura 30. É possível também mostrar a caixa de diálogo Relation clicando com o botão direito do mouse em uma das tabelas, apontando para Add e, em seguida, clicando em Relation.

Figura 30. Definindo a relação entre duas tabelas

Com o banco de dados no projeto, um dataset criado para o banco de dados, e um relacionamento definido no dataset, a única coisa que resta a fazer é tornar os dados visíveis no aplicativo. Como esse exemplo é extremamente simples e destinado a mostrar os designers do Visual Studio que ajudam você a criar aplicativos que usam um banco dados do SQL Mobile, a própria interface do usuário não é nada atraente. É simplesmente feita de um controle de DataGrid que contém os títulos dos DVDs e de um controle de Textbox que mostra as categorias correspondentes de cada título de DVD. No painel Data Sources, selecione um controle específico de interface do usuário de cada coluna ou de toda uma tabela. Para tanto, clique na coluna ou tabela que deseja exibir em uma empresa. Após fazer isso, expanda os controles da interface do usuário que podem ser usados para tornar os dados visíveis, clicando na seta para baixo. A seguir, selecione o controle da interface do usuário que deseja mostrar no formulário, e, em seguida, arraste-o para o formulário, conforme mostrado na Figura 31. Os controles adicionados ao formulário dessa forma são automaticamente ligados aos dados subjacentes, de modo que não há necessidade de escrever nenhum código para exibir o conteúdo dos dados que estão atualmente disponíveis no banco de dados.

Figura 31. Adicionando controles de dados ligados ao aplicativo

Para poder usar o relacionamento existente entre DVDTitles e DVDCategories, arraste o campo DVD Category da tabela-filho, que é exibido na tabela DVDTitles. Quando você compila e implanta esse aplicativo, o banco de dados é implantado no dispositivo do aplicativo, podendo ser usado imediatamente, como mostrado na Figura 32.

Figura 32. Aplicativo de coleção de DVD concluído

É claro que será necessário adicionar códigos se você desejar adicionar novos registros, excluir registros ou modificar registros do banco de dados—mas essas ações ultrapassam o escopo deste artigo.

Conclusão

Com o Visual Studio 2005 e o .NET Compact Framework versão 2.0, há um grande número de controles práticos disponíveis que aumentam instantaneamente a produtividade. O novo designer de interface do usuário pode ajudá-lo a criar excelentes interfaces do usuário. Graças à disponibilidade de capas no designer, é possível entender imediatamente qual será a aparência da interface do usuário em um dispositivo real. É possível também testar a aparência da interface do usuário em modos retrato e paisagem (quando aplicável) sem necessidade de escrever nenhuma linha de código. A disponibilidade de designers de dados permite criar e manter bancos de dados do SQL Mobile em um computador de desenvolvimento e implantá-los mais tarde no dispositivo. Este artigo exemplificou alguns recursos do Visual Studio 2005 com relação às ferramentas de design. Há muitos outros recursos a serem explorados, e esperamos que você seja curioso o bastante para explorar os vários outros recursos do Visual Studio 2005 por conta própria.

© .