PowerBuilder Brasil: Cartilha WPF para o Desenvolvedor PowerBuilder: Parte 2

Postado em 22 de junho de 2009 por John Strano, no blog do PowerBuilder no site oficial da Sybase: http://blogs.sybase.com/powerbuilder/2009/06/a-wpf-primer-for-the-powerbuilder-developer-part-two/

Traduzido e adaptado por: Blog PowerBuilder Brasil

Migrando para WPF

O WPF introduziu vários novos conceitos, entre eles: propriedades de dependência, propriedades de anexos, comandos e eventos roteados. Um dos objetivos do projeto da IDE PowerBuilder .NET é abstrair todos os detalhes destes novos conceitos e manter a sua utilização semelhante a IDE PowerBuilder já existente.

O ambiente de desenvolvimento PowerBuilder .NET reduz drasticamente sua curva de aprendizado para o WPF. O objetivo é proporcionar aos desenvolvedores a experiência de criar aplicações WPF através do PowerBuilder.

O WPF tem um modelo de objeto diferente das aplicações Win32 e WinForm. Estamos trabalhando para preservar o modelo PowerBuilder ao incorporar a funcionalidade WPF desejada. Por exemplo, os controles WPF tem uma propriedade “content”. Para as classes/controles apropriados, o PowerBuilder abstrai para a propriedade já conhecida “Text”. Este objetivo é atingido no PowerBuilder através de controles estendidos para WPF. Abaixo temos um pequeno fragmento de XAML, ilustrando esta abstração:

pbwpf:CommandButton PBHeight=”112″ PBWidth=”462″ Name=“cb_save” VerticalAlignment=”Bottom” Text=”Save” />

A arquitetura do WPF também é consideravelmente diferente das arquiteturas Win32 e WinForm. A abordagem de migração é diferente do que tivemos no PowerBuilder 11.x, quando migramos de Win32 para WinForm .NET. Na migração para o WPF, serão necessárias mais alterações de código do que numa migração de Win32 para Windows Forms.

Eventos Personalizados Definidos pelo Usuário

Para o WPF, o modelo de eventos do Win32/WinForm foi alterado. Muitos eventos personalizados do Win32 do WinForms .NET não possuem eventos correspondentes no WPF e por isso não serão suportados pelas aplicações PowerBuilder WPF. Por exemplo, se você mapeou o evento pbm_erasebkgnd para uma janela no PowerBuilder Clássico (Win32), este evento não existe em uma janela WPF. Você precisará decidir qual a melhor alternativa para contornar este problema e re-escrever o código.

Utilização de Window Handle

Em aplicações Win32/WinForm, cada controle é na verdade uma janela e tem o seu próprio handle. No WPF, existe apenas um único handle de janela pai. Um controle em uma janela WPF não terá um handle próprio. Chamadas de API`s que utilizam Window handles não serão suportadas. Para aplicações migradas, não existe outra solução a não ser re-escrever o código.

Seqüência de Eventos

Novamente, o modelo de eventos de aplicações WPF foi alterado em relação a seus predecessores. A seqüência de eventos das aplicações WPF é diferente da seqüência de aplicações WinForm / Win32. Não podemos garantir que a seqüência de eventos das classes WPF será exatamente a mesma. Se algumas partes de suas aplicações migradas são invocadas em uma ordem específica de eventos, que difere no WPF, não existe outra solução a não ser re-escrever o código.

Aparência

A aparência das aplicações WPF é bem diferente das aplicações Win32 e WinForm. Alguns comportamentos básicos serão alterados. Algumas propriedades não possuem um padrão equivalente no WPF. O WPF incentiva os desenvolvedores a usar Styles e Templates para criar bordas em vez de simplesmente usar a propriedade BorderStyle. Curiosamente, na década de 90 a Microsoft defendeu o uso do MDI, mas este agora é visto pela Microsoft com uma série de desvantagens. Nas aplicações PowerBuilder migradas para WPF, as aplicações MDI serão renderizadas em uma interface com abas (tabpages). A área cliente MDI será um tab control e cada uma das sheets MDI será uma página do tab control. O que era um frame MDI será um tab control e o que era uma sheet MDI agora será uma tabpage.

Restrições de Controles

Em aplicações Win32 e WinForm, uma janela pode ser pai de vários controles. Já no WPF, uma janela pode ter apenas um controle filho.

A convenção no WPF é colocar um painel de layout na janela, então este painel atua como o objeto pai de múltiplos controles. O painel de layout “Canvas” será utilizado como default para janelas de aplicações migradas. No WPF, os painéis “Canvas” se aproximam bastante do posicionamento oferecido pelas aplicações Win32 e WinForm. Se utilizássemos painéis Grid para aplicações migradas, a posição dos objetos não seriam satisfatórias. Se nos depararmos com estas situações, vamos entender que o desenvolvedor quer utilizar de forma proveitosa os recursos do WPF.

Todos os conflitos de migração serão marcados em um avançado assistente de migração, e esta ferramenta irá reportar que existem itens dependendo de decisões do desenvolvedor. O log de saída na IDE PowerBuilder .NET é segregado por categorias, em tabs, o que facilita o exame de conflitos após a migração.