quinta-feira, 24 de fevereiro de 2011

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.



Bibliografia

Introduction to Windows Presentation Foundation:
Window Presentation Foundation Unleashed By Adam Nathan - ISBN-13: 9780672328916
CodeProject Guided Tours:
http://www.codeproject.com/KB/WPF/GuidedTourWPF_1.aspx
http://www.codeproject.com/KB/WPF/GuidedTourWPF_2.aspx
http://www.codeproject.com/KB/WPF/GuidedTourWPF_3.aspx
http://www.codeproject.com/KB/WPF/GuidedTourWPF_4.aspx
http://www.codeproject.com/KB/WPF/GuidedTourWPF_5.aspx

segunda-feira, 21 de fevereiro de 2011

Analista Programador - Belo Horizonte-MG

Duas Vagas - BELO HORIZONTE-MG, 21/02/2011
Código: 141943
Cargo: Analista Programador
Descrição: Atividades a serem desempenhadas:
• Atendimento ao cliente
• Análise e correção de incidências
• Análise e desenvolvimento de software (.NET e PowerBuilder)
• Acompanhamento de processos de teste automatizado
• Apoio à implantação e homologação de sistemas
Conhecimentos/experiências imprescindíveis:
• Programação em linguagem Windows
• Banco de dados relacional/SQL
 

Fonte: www.ceviu.com.br

Analista de TI PL - Vitória-ES

Uma Vaga - VITORIA-ES, 16/02/2011
Código: 141294
Cargo: Analista de Sistemas
Descrição: Analista de TI Pleno

Descrição: Pré Requisitos:
Formação Acadêmica:
- Graduação Concluída
- Pós-Graduação [Desejável]

Conhecimentos:
- Inglês - nível técnico
- PowerBuilder - nível básico [ Mínimo ]
- Visual C - nível básico [ Mínimo ]

Experiência:
- Desejável experiência em indústria.

Incluir pretensão salarial
Empresa: Vixteam Consultoria & Sistemas
O profissional deverá ter disponibilidade para viagem.


Link para a vaga: http://www.ceviu.com.br/vaga/emprego-analista-de-ti-pl-vitoria-es-141294-m-pesquisa

Fonte: www.ceviu.com.br

PROGRAMADOR POWERBUILDER - Campo Bom-RS

Uma Vaga - CAMPO BOM-RS, 21/02/2011
Código: 141955
Cargo: Programador PowerBuilder
Descrição: Profissional pleno para desenvolvimento e manutenção de sistemas financeiro e comercial.
Imprescindível: SQL e PowerBuilder
Desejável: Inglês intermediário
Contratação: CLT Benefícios.
Local de trabalho: Campo Bom - RS


Link para a vaga: http://www.ceviu.com.br/vaga/emprego-programador-power-builder-campo-bom-rs-141955-m-pesquisa

Fonte: www.ceviu.com.br

Desenvolvedor - São Paulo-SP

Uma Vaga - SAO PAULO-SP, 18/02/2011
Código: 141919
Cargo: Desenvolvedor/Programador Web
Descrição: Desenvolvedor (programação) - PowerBuilder versão 10 e PL / SQL Oracle.
* Experiência com PowerBuilder versão 10 PL / SQL Oracle. Desenvolvimento de melhorias - fase de especificação técnica e programação.
* Ensino Superior completo na área.

* Regime de contratação: Prestador de serviços (PJ)
* Horário: Comercial.
* Informações adicionais: Alocação no cliente Piracicaba, despesas por conta do projeto. Na alocação em Alphaville, São Paulo, despesas de alimentação / estacionamento por conta do profissional.
* Idiomas: Inglês - Básico

Link para a vaga: http://www.ceviu.com.br/url/2/NDYyNDQx

Fonte: www.ceviu.com.br

sexta-feira, 18 de fevereiro de 2011

Analista de desenvolvimento de sistemas .Net - Belo horizonte-MG

Vaga: Analista de desenvolvimento de sistemas .Net
Código da vaga: 1432033
Cidade: BELO HORIZONTE/MG (1 vaga)
Data de atualização: 16/02/2011
Quantidade: 1 vaga
Descrição: Curso superior completo na área de TI.
Desejável experiência mínima de um ano em desenvolvimento de sistemas.
Conhecimento de desenvolvimento de aplicações no ambiente WEB em .Net. Conhecimento de banco de dados (Oracle, SQL, Sybase).
Desejável conhecimento de linguagens de programação visuais (Visual Basic, Power Builder, Delphi).
Exigências: Superior completo
Faixa salarial: A combinar
Benefícios: A combinar
Níveis hierárquicos: Especialista com Curso Superior
Área(s) de atuação: Informática (T.I.)
Dados da Empresa: ATTPS INFORMATICA
Descrição: Desenvolvimento e licenciamento de programas de computador customizáveis.
Porte: Média
Ramo: Informática
Tipo: Nacional

Link para a vaga: http://empregocerto.uol.com.br/vagas/analista-de-desenvolvimento-de-sistemas-net-belo-horizonte-mg-1432033.html

Fonte: www.empregocerto.uol.com.br

sexta-feira, 11 de fevereiro de 2011

Analista Desenvolvedor PowerBuilder/Oracle – PIRACICABA-SP

Data: 11/02/2011
A Resource, uma das maiores empresas de soluções em Tecnologia da Informação, com 19 anos de atuação no mercado, busca profissionais com o seguinte perfil:
Seleciona candidatos para a vaga de Analista Desenvolvedor PowerBuilder/Oracle para PIRACICABA / SP.
Requisitos:
Solida
experiência em PowerBuilder e Oracle.
O
Profissional trabalhará no desenvolvimento de uma integração de sistemas.
LOCAL DE TRABALHO: Piracicaba.
Horário: Comercial de seg a sex.
Tempo de Projeto: Indeterminado
Benefícios:
A COMBINAR
Salário:
A COMBINAR
Observações:
-
Enviar currículos até 28-02-11 aos cuidados de: CRISTIENE COSTA com a sigla: PB no campo assunto para o e-mail: SELECAORMC@RESOURCE.COM.BR


Fonte: www.empregosemsp.com.br

Estágio PowerBuilder - Florianópolis-SC

Estágio para trabalhar na área de suporte.
Empresa desenvolvedora de software ERP (gestão empresarial). 
Buscamos jovens com conhecimentos básicos em SQL e Noções de Programação, que tenham vontade de aprender e apresentem características que primam pelo bom relacionamento interpessoal.
Características e Conhecimentos Necessários:
- SQL
- Noções de Programação
- Bom relacionamento Interpessoal
Conhecimentos Desejáveis:
- PowerBuilder
- Visual Studio (Asp.Net / Vb.Net)


O cargo irá exigir um atendimento ao cliente de maneira cordial, onde a pessoa irá identificar o problema inicial e fazer a abertura do chamado de assitência.Após esta etapa o chamado será enviado para análise, onde deverá ser previsto e informado ao cliente o prazo de resolução.
Alguns chamados, dependendo do nível, serão resolvidos pelo próprio analista e outros encaminhados ao nível superior.
Precisamos de alguém com o perfil desejado (bom relacionamento) e que tenha vontade de aprender e crescer conosco.


Vagas, enviar currículo para: 
financeiro@unisnet.com.br


www.unisnet.com.br

quarta-feira, 9 de fevereiro de 2011

Desenvolvedor PowerBuilder - São Paulo-SP

Dados da Empresa Contratante 

Nome: Tivit
Descrição Sumária: A Tivit é a primeira empresa a oferecer serviços integrados de Infraestrutura de TI, Sistemas Aplicativos e BPO. Com mais de 24 mil colaboradores, a empresa está presente em todo Brasil com 18 unidades. A companhia une experiência e maturidade em redesenho de processos, operações de missão crítica em larga escala e conhecimento do negócio em diversos segmentos da economia.
Ramo de Atividade: Informática
Porte: Grande
Nacionalidade: Brasileira

Dados da Vaga 
Título da vaga: Desenvolvedor PowerBuilder
Data de entrada: 08.02.2011
Quantidade: 2 vagas
Descrição da vaga: Análise e desenvolvimento utilizando PowerBuilder, JAVA, C e C++.
Ter experiência.
Ensino Superior completo.
Desejável conhecimento em mercado financeiro.

Observações: Benefícios: Assistência Médica / Medicina em grupo, Assistência Odontológica, Auxílio Creche, Seguro saúde, Tíquete-refeição, Vale-transporte
Regime de contratação: CLT (Efetivo)
Horário: Comercial.

Faixa Salarial: A Combinar
Idiomas: Inglês (Intermediário)

Cidades: SAO PAULO - SP (2 vagas)

Link para a vaga: http://emprego.catho.com.br/vagas/desenvolvedor-power-builder/sao-paulo/sao-paulo/5837915/

Fonte: Emprego de Desenvolvedor Power Builder em São Paulo, SP | Catho

Chamando Componentes .NET no PowerBuilder - Via COM Wrappers

Artigo publicado em 11 de janeiro de 2011, no “Developers`s Powerbuilder journal”
Traduzido e adaptado por: Blog powerbuilder Brasil

Já escrevi inúmeros artigos sobre como usar componentes .NET, visuais e não visuais, em aplicações Win32 do PowerBuilder Clássico. Até então, todos eles envolviam componentes .NET originados do .NET Framework ou criados no Visual Studio. O que muda com o PowerBuilder 12 é que agora é possível escrever um componente não visual utilizando o PowerBuilder.NET, e a solução fica inteiramente baseada na plataforma PowerBuilder.
Tecnicamente, isso se tornou possível desde a introdução do target .NET assembly, no PowerBuilder 11. No entanto, há duas questões a serem observadas naquela abordagem:
  1. O PowerBuilder 11 (assim como o 11.5) não possuía um ambiente CLR, e referenciar classes .NET de objetos não visuais usados para criar o assembly requeria o uso de blocos de códigos condicionais, com suas próprias limitações (principalmente a falta de autoscripting, validação de script e uma pobre documentação da sintaxe).
  2. O PowerBuilder 11 (assim como o 11.5) gerava assemblies que não eram marcados como “COM visible”, um pré-requisito para que estes pudessem ser acessados via “COM Callable Wrappers” (CCW) pelas aplicações PowerBuilder Win32. Existe a possibilidade de forçar esta marcação, por exemplo, usando o ILDASM (IL disassembler) para decompilar o assembly, modificar o código decompilado e depois re-compilar com o ILASM. Este método, no entanto, está longe de ser ideal.
Com o PowerBuilder.NET, no PowerBuilder 12, temos um completo ambiente CLR PowerScript, totalmente suportado pelo autoscripting, validação de script e uma documentação de sintaxe melhor. Além disso, os assemblies gerados pelo PowerBuilder.NET são marcados como “COM visible”, por isso torna-se muito mais fácil utilizá-los em aplicações Win32 via CCW.

Criando o Assembly
Vamos implementar uma chamada à classe SMTPClient do .NET Framework como fizemos em exemplos anteriores, porém agora vamos fazer isso diretamente utilizando PowerScript, no PowerBuilder.NET:

System.Net.Mail.MailMessage myMailMessage
SmtpClient mySTMPClient
Attachment myAttachment
Exception ex

myMailMessage = create System.Net.Mail.MailMessage
mySTMPClient = create SmtpClient(iHost)

myMailMessage.From = create System.Net.Mail.MailAddress(iFrom)
myMailMessage.To.Add(iTo)
myMailMessage.Subject = iSubject
myMailMessage.IsBodyHtml = iIsHTML
myMailMessage.Body = iBody

if not IsNull(iCC) and iCC <> “” then
     myMailMessage.CC.Add(iCC)
end  if

choose case iSendUsing
case 0
     mySTMPClient.DeliveryMethod = SmtpDeliveryMethod.Network!

case  1
     mySTMPClient.DeliveryMethod = SmtpDeliveryMethod.PickupDirectoryFromIis!

case  2
     mySTMPClient.DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory!

end choose

if iAuthenticationMode > 0 then
     mySTMPClient.Credentials = create NetworkCredential(iUser,iPassword)
end  if

mySTMPClient.Port = iPort

mySTMPClient.EnableSsl = iUseSSL

//Anexos
if not isNull(iAttachmentPath) and iAttachmentPath <> “” then
     myAttachment = create Attachment(iAttachmentPath)
     myMailMessage.Attachments.Add(myAttachment)
end if

//Envia a mensagem
mySTMPClient.Send(myMailMessage)


Este código é uma adaptação do código que Dave Fish utilizou para uma de suas sessões na TechWave 2010. Existem algumas variáveis de instância, indicadas pelo prefixo "i", como iSubject, iIsHTML e iBody. Como o PowerBuilder.NET não suporta propriedades na geração de assemblies .NET, tivemos que implementar métodos set no assembly para atribuir valores às variáveis de instância. Por serem triviais não vamos listar os códigos destes métodos neste artigo.
Agora que temos um objeto não visual com os métodos set, criamos um projeto do tipo .NET assembly para que o PowerBuilder possa gerar o objeto não visual como um assembly (veja as figuras abaixo). Executando o projeto, teremos cumprido parte do nosso objetivo.



Criando as Entradas de Registro CCW para o Assembly
Agora que temos nosso próprio assembly .NET, temos que criar as entradas de registro que a aplicação desenvolvida no PowerBuilder Clássico vai utilizar para consumir o assembly. Também poderíamos utilizar um arquivo manifest ao invés de entradas de registro, como já expliquei em outro artigo numa edição anterior do PBDJ (Developer`s PowerBuilder Journal). No entanto, nesta demonstração iremos utilizar entradas de registro.
O caminho que você deve seguir é executar a ferramenta REGASM, do .NET SDK, no assembly. No nosso exemplo, o nome dado ao assembly foi PBSmtpClient.dll, então devemos executar o REGASM no assembly conforme a linha de comando abaixo:
REGASM  PBSmtpClient.dll /regfile:PBSmtpClient.reg
Caso você execute o REGASM diretamente no assembly sem definir nenhum parâmetro, as entradas serão automaticamente adicionadas ao registro da máquina onde você tiver executado. Mas por duas razões você deve gerar as entradas em um arquivo registry (.REG) e incorporá-las depois. A primeira razão é que você poderá precisar deste arquivo .REG (e das informações nele contidas) para executar o assembly em outras máquinas.
A segunda razão é específica para sistemas operacionais de 64 bits, tal como a versão 64 bits do Windows 7. Quando você executa o REGASM em um assembly num sistema operacional de 64 bits, ele cria apenas as entradas de registro necessárias para aplicações de 64 bits. Você precisa então fazer um trabalho de “copiar e colar” para adicionar as informações necessárias às aplicações de 32 bits, como as aplicações desenvolvidas no PowerBuilder Clássico. O que você vai fazer é abrir o arquivo, copiar e colar as entradas de registro, duplicando-as. Então, para o segundo bloco (o que foi duplicado), procure por HKEY_CLASSES_ROOT e substitua este termo por HKEY_CLASSES_ROOT\Wow6432Node. O termo “Wow6432Node” é a sub-chave de todas as principais chaves de registro que contém entradas utilizadas por aplicações de 32 bits.
Por exemplo, a primeira entrada no arquivo seria algo do tipo:
[HKEY_CLASSES_ROOT\PBSmtpClient.SmtpClient]
@="PBSmtpClient.SmtpClient"
Feita a cópia e a substituição, deverá existir uma entrada adicional no arquivo, conforme abaixo:
[HKEY_CLASSES_ROOT\Wow6432Node\PBSmtpClient.SmtpClient]
@="PBSmtpClient.SmtpClient"

Uma vez feito isso (considerando que você está em um sistema de 64 bits), dê um duplo-clique no arquivo .REG para que o Windows adicione a informação ao registro. Caso você esteja em um sistema de 32 bits, execute diretamente o arquivo gerado pelo REGASM, sem nenhuma modificação.

Chamando o Assembly no PowerBuilder Clássico

Depois que as entradas de registro já foram adicionadas ao registro do Windows, a aplicação PowerBuilder já pode acessar o assembly como se fosse um componente COM padrão, utilizando automação OLE. O código é praticamente o mesmo que nós utilizamos em exemplos anteriores, quando tratamos de assemblies gerados no Visual Studio:

integer             li_rc
oleobject          smtp
smtp = CREATE oleobject
li_rc = smtp.ConnectToNewObject ( "PBSmtpClient.SmtpClient" )
smtp.SetFrom ( "first.last@domain.com" )
smtp.SetTo ( "bruce.armstrong@teamsybase.com" )
smtp.SetSubject ( "Test" )
smtp.SetBody ( "This is only a test" )
smtp.SetHost ( "mail.domain.com" )
smtp.SendMessage()
smtp.DisconnectObject()
Destroy smtp

Considerações Finais

Existem algumas limitações para esta abordagem, como já relatei em minha sessão na TechWave 2008, principalmente relacionadas à captura de informações de erros de exceções lançadas pelo assembly (eu também direcionei naquela sessão o caminho para solucionar estes problemas). Desta forma, esta técnica deve ser bastante útil para aquelas aplicações onde a quantidade de chamadas que você precisa fazer para classes .NET é limitada o suficiente para que a migração completa para WinForm ou WPF não se justifique. O uso desta técnica permite que você mantenha sua aplicação no PowerBuilder Clássico, adicionando funcionalidades.NET conforme necessário.

terça-feira, 8 de fevereiro de 2011

Programador PowerBuilder - Brasília-DF

Uma Vaga - BRASILIA-DF, 08/02/2011
Código: 139730
Cargo: Programador PowerBuilder
Descrição: Programação PowerBuilder e SQL Server 2000 ou Superior

3 anos na função

Link para a vaga: http://www.ceviu.com.br/vaga/emprego-programador-powerbuilder-brasilia-df-139730-m-pesquisa


Fonte: www.ceviu.com.br

Analista Desenvolvedor PowerBuilder - Curitiba-PR

Uma Vaga - CURITIBA-PR, 08/02/2011
Código: 139721
Cargo: Desenvolvedor
Descrição: Necessário conhecimento em :

- C /C
- PowerBuilder

Link para a vaga: http://www.ceviu.com.br/vaga/emprego-analista-desenvolvedor-power-builder-curitiba-pr-139721-m-pesquisa


Fonte: www.ceviu.com.br

Analista Programador Sênior - Rio de Janeiro/RJ

Uma Vaga - RIO DE JANEIRO-RJ, 08/02/2011
Código: 139681
Cargo: Analista Programador
Descrição: Formação superior em andamento ou completa na área de informática ou afins;

Experiência de 3 ano ou mais em desenvolvimento de Sistemas PowerBuilder, versões 6 e 8;
Desejável experiência INFORMIX e SQLSERVER;
Desejável experiência em e-Commerce;
Desejável experiência em metodologia AGILE (Scrum, XP).


Link para a vaga: http://www.ceviu.com.br/vaga/emprego-analista-programador-senior-rio-de-janeiro-rj-139681-m-pesquisa


Fonte: www.ceviu.com.br

Desenvolvedor Powerbuilder - Porto Alegre RS

Uma Vaga - PORTO ALEGRE-RS, 08/02/2011
Código: 139628
Cargo: Desenvolvedor
Descrição: Esperiência com desenvolvimento em Powerbuilder.

A empresa oferece remuneração compatível com o mercado.
Link para a vaga: http://www.ceviu.com.br/vaga/emprego-desenvolvedor-powerbuilder-porto-alegre-rs-139628-m-pesquisa

Fonte: www.ceviu.com.br

domingo, 6 de fevereiro de 2011

Cartilha WPF para o Desenvolvedor PowerBuilder: Parte 1

Postado em 22 de maio de 2009 por John Strano, no blog do PowerBuilder no site oficial da Sybase: http://blogs.sybase.com/powerbuilder

Traduzido e adaptado por: Blog PowerBuilder Brasil

Window Presentation Foundation (WPF) é uma nova tecnologia para construção de interfaces gráficas. Esta tecnologia de renderização foi inicialmente distribuída como parte do .NET 3.0 e está totalmente relacionada à camada de apresentação. O WPF está disponível a partir da versão 3.0 do .NET e pode ser instalada nas plataformas: XP/Vista/Windows 2003/etc. Utilizando a IDE PowerBuilder.NET, os desenvolvedores serão capazes de aproveitar suas habilidades em PowerBuilder para criar aplicativos WPF.
Tecnologia Estratégica de Renderização
A Microsoft afirma que embora aplicativos Win32, .NET Windows Forms e .NET Web Forms ainda serão suportados por muitos anos, estes não podem mais ser considerados estratégicos. O WPF e a tecnologia Silverlight para navegadores são as tecnologias de renderização escolhidas para o Windows de agora em diante.
A IDE PowerBuilder .NET, presente na versão 12 do PowerBuilder, é compatível com a tecnologia WPF, preservando o investimento e habilidades dos desenvolvedores PowerBuilder. Poucas ferramentas de desenvolvimento disponibilizaram este tipo de evolução para seus consumidores.
A propósito, o PowerBuilder 12 será distribuído com duas IDEs. O PowerBuilder Clássico para desenvolvimento de aplicações Win32, aplicações .NET, JEE e componentes não visuais. A IDE PowerBuilder .NET fornece um ambiente de desenvolvimento para aplicações WPF e para objetos não visuais como .NET Assemblies ou .NET Web Services.
Gráficos WPF
O WPF pode dar uma aparência impressionante às aplicações, dando ao usuário uma experiência visualmente deslumbrante. Não são apenas os gráficos que impressionam, mas também a capacidade que o WPF tem de integrar com gráficos 3D, animações, vídeos de alta definição, etc.
A primeira alteração está relacionada à tecnologia subjacente. Historicamente, aplicações Win32 e .NET Window Forms sempre utilizaram GDI+. Já o WPF utiliza DirectX para renderização. O DirectX pode ser renderizado utilizando recursos de hardware, e em alguns casos isso resulta inclusive em ganhos de performance sem o desenvolvedor ter que aprender a acessar cada API de placa gráfica. Uma paleta de cores, gradientes, preenchimentos, texturas e transparência estão todos disponíveis na forma de "escovas".

Gráficos Vetoriais
Interfaces WPF estáticas e animadas são processadas através de gráficos vetoriais. Os gráficos vetoriais vieram à tona no final de década de 90 com o advento do Flash. Lembram-se de quanto custava uma banda de 56k em 1998? Com a utilização de gráficos vetoriais, os arquivos necessários para download de uma interface em Flash eram muito pequenos, minúsculos se comparados ao impacto visual que produziam uma vez processados pelo software cliente. Os “Flash Players” então se tornaram onipresentes e o sentimento dos usuários pode ser traduzido como algo do tipo “Eu não tenho que instalá-lo”. O WPF e o Silverlight são responsáveis pela incursão da Microsoft num espaço até então ocupado pela Macromedia, com o Adobe Flash e Flex.
O WPF é independente de resolução
Por ser um subproduto da tecnologia vetorial, aumentar ou diminuir o zoom em uma interface WPF praticamente não degrada em nada a interface renderizada, mesmo que ultrapasse os limites da usabilidade, conforme podemos ver no exemplo que segue.





Outra vantagem do WPF é o fato de possuir uma rica e unificada API para várias tecnologias. Sua integração ampla abrange gráficos 3D, vídeos em HD, reconhecimento de voz e uma rica visualização de documentos, com uma única tecnologia, um único framework. Não há necessidade de ir à busca de várias APIs para cada um desses recursos.
Texto e Tipografia no WPF
O WPF oferece suporte à fonte OpenType. O OpenType é uma extensão do formato TrueType®. O suporte à fonte PostScript foi adicionado através de um esforço conjunto entre Microsoft e Adobe. A especificação do formato OpenType pode ser encontrada no endereço abaixo:
O ClearType é uma tecnologia de otimização para displays LCD que foi aprimorada para o WPF. Estes aprimoramentos incluem “sub-pixel positioning”, “y-direction anti-aliasing”, e utilizando DirectX, o texto WPF pode aproveitar a velocidade do hardware. Textos internacionais também possuem grande suporte no WPF.
Veja o artigo “Globalization for the Windows Presentation Foundation”:
A integração do texto com mídias, gráficos e animações oferecem uma nova e suave apresentação textual.
A imagem a seguir ilustra a integração entre texto e gráficos para alcançar formas variadas de decoração de textos:



Um subproduto relacionado aos recursos de textos no WPF é o suporte à capacidade de exibição da direita para a esquerda, através da propriedade de layout “FlowDirection”. Qualquer controle capaz de exibir textos terá a funcionalidade “FlowDirection”.



Documentos
O WPF suporta três tipos nativos de documentos: Fixed, Flow e XPS (XML Paper Specification).
Documentos Fixed
…são para exibição WYSIWYG, e preservam o formato e estilo originais do documento. A qualidade varia de acordo com os dispositivos de saída.
Documentos Flow
…podem ser ajustados e redimensionados dinamicamente.

Documentos XPS
…ou XML Paper Specification são baseados nos documentos fixed do WPF.
Eles são abertos em forma de documentos eletrônicos, e podem ser autônomos ou dependentes de navegadores. O XPS compete com o Adobe PDF no campo de documentos eletrônicos.
No próximo post relacionado, continuaremos nossa introdução ao WPF e explorar a migração de aplicações existentes em PowerBuilder para WPF e PowerBuilder.NET.
Bibliografia
Introduction to Windows Presentation Foundation:
Window Presentation Foundation Unleashed By Adam Nathan - ISBN-13: 9780672328916
CodeProject Guided Tours:

sábado, 5 de fevereiro de 2011

Programador Power Builder JR - Curitiba PR

Empresa:  BRQ IT Services  
Data:  01/02/2011 
Local:  PR - Curitiba 
Nível: Junior
Tipo de Contratação:  CLT-Flex, PJ 
Tags:  Power Builder 
Anuncio: Programador Power Builder JR
Conhecimento em Power Builder currículos para jcarolinesantos@brq.com
Contato:
vagas-ctba@brq.com 
Nº. vagas disponíveis:  1 
Informar Pretensão salarial?  Sim
Previsão de inicio:  Urgente

Fonte: www.empregosti.com