Desenvolver uma aplicação comercial utilizando WPF é realmente muito legal! A plataforma nos oferece recursos de DataBinding que facilitam nossa vida como desenvolvedores e que permitem a criação de visualizações magníficas para os usuários finais. Mesmo com tantas facilidades ainda nos esbarramos em conceitos que não existem em WPF, como herança visual de XAML e até mesmo o conceito de MDI.

Nota: Neste post, não entrarei nos detalhes, contudo, o código estará disponível.

Aqui em nossa aplicação um dos requisitos era montar uma interface MDI, que pemitisse que um usuário pudesse abrir várias janelas de forma simultânea e até mesmo a mesma janela mais de uma vez. A solução desevolvida foi a de abstrair o conceito de “janela gerenciada” de tal forma que é possível indicar ao sistema qual janela será gerenciada ou não. Posteriormente foi necessário se criar um mecanismo que mantivesse o estado dessas janelas gerenciadas. Essas janelas são mantidas em uma lista que pode ser exibida ao usuário e ele, ao clicar em um item dessa lista, traz a janela selecionada para o foco ativo. Bem vamos ver algum código. 

Nota: Esta solução que apresento foi inspirada por este post, apresentando um código parecido, contudo foi ajustado para minha realidade… Logo irei postar tudo detalhado no Code Project.

Tenho uma classe que irá gerenciar as janelas, a classe WindowViewStateManager. Ela herda de ViewModel, que é um tipo declarado pelo framework Julmar que facilita o uso padrão M-V-VM. Se você desenvolve em WPF sem utilizar esse padrão (ou algo similar), corra!!! Por que seu código deve estar virando uma bela macarronada!

Nessa classe tenho a lista de janela que foram abertas:

public ObservableCollection<WindowViewStateInstance> WindowViewStates
        {
            get{ return_windowViewStates ?? (_windowViewStates = newObservableCollection<WindowViewStateInstance>()); }
        }

Agora como que uma janela pode ser adicionada à essa lista? Para isso criamos uma Attached Property que inclue esse comportamento em nossas janelas. Ela está definida na classe a seguir:

public class WindowViewState
{
    public static bool GetIsManaged(DependencyObject obj)
    {
        return (bool) obj.GetValue(IsManagedProperty);
    }

    public static void SetIsManaged(DependencyObject obj, bool value)
    {
        obj.SetValue(IsManagedProperty, value);
    }

    // Using a DependencyProperty as the backing store for MyProperty.  This enables animation, styling, binding, etc...
    public static readonly DependencyProperty IsManagedProperty =
        DependencyProperty.RegisterAttached("IsManaged", typeof (bool), typeof (WindowViewState),
                                            new FrameworkPropertyMetadata((bool) false,
                                                                          new PropertyChangedCallback(
                                                                              OnIsManagedChanged)));

    private static void OnIsManagedChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        Window target = (Window) d;
        if (target != null)
        {
            target.Loaded += new RoutedEventHandler(target_Loaded);
            target.Closed += new EventHandler(target_Closed);

        }
    }
    

    private static void target_Closed(object sender, EventArgs e)
    {
        Window target = (Window) sender;
        if (target != null)
        {
            WindowViewStateManager.Instance.RemoveWindowViewState(target);
            WindowViewStateManager.Instance.ShowLastWindow();
        }
    }

    private static void target_Loaded(object sender, RoutedEventArgs e)
    {
        Window target = (Window) sender;
        if (target != null)
        {
            WindowViewStateInstance instance = new WindowViewStateInstance();
            instance.Title = target.Title;
            instance.Icon = new VisualBrush(target);
            instance.Window = target;
            instance.Number = (WindowViewStateManager.Instance.CountInstancesForWindowTitle(target.Title) + 1);
            instance.Window.Tag = instance.Number;
            WindowViewStateManager.Instance.HideAllVisible(instance.WindowId);
            WindowViewStateManager.Instance.WindowViewStates.Add(instance);
        }
    }
}

Diferentemente da solução original, o meu requisito exige que mesmo podendo abrir mais de uma janela, apenas uma será visível. Isso eu trato no método target_Loaded, que é disparado sempre que uma janela é carregada. Isso é feito pelo método HideAllVisible. Na verdade esse método não “esconde” as janelas, pois ao escondê-las, o VisualBrush da mesma também desaparece. Veja que uso o VisualBrush da janela para que posteriormente tenhamos uma lista das janelas abertas sendo exibidas de forma visual mesmo! Como pode ser visto aqui:

Veja lá ao fundo a miniatura das janelas, é exatamente isso que estamos fazendo. Voltando ao esconder janelas, então, para que sua miniatura também não desapareça, apenas movo a posição da janela para uma área não visível e, posteriormente quando for necessário exibí-la novamente, a trago para o centro do monitor:

public void HideAllVisible(int WindowHashCode)
{
    foreach (var view in _windowViewStates)
    {
        if (view.WindowId != WindowHashCode)
        {
            view.Window.Left = -3000;
        }
    }
}

private void CenterWindow(Window w)
 {
     var width = (SystemParameters.PrimaryScreenWidth / 2);
     var tamanhojanela = w.Width / 2;

     var height = SystemParameters.PrimaryScreenHeight / 2;
     var alturajanela = w.Height / 2;
     w.Left = width - tamanhojanela;
     w.Top = height - alturajanela;
 }

Ao fechar uma janela, a removemos da lista e pedimos para que a última que foi aberta, fique ativa novamente:

private static void target_Closed(object sender, EventArgs e)
{
    Window target = (Window) sender;
    if (target != null)
    {
        WindowViewStateManager.Instance.RemoveWindowViewState(target);
        WindowViewStateManager.Instance.ShowLastWindow();
    }
}

public bool RemoveWindowViewState(Window window)
{
    var view = (from v in _windowViewStates where (v.Title == window.Title) && (v.Number.ToString() == window.Tag.ToString()) select v).First();
    if (view != null)
    {
        if (_windowViewStates.Count == 1)
        {
            view.Window.IsEnabled = true;
            view.Window.Owner.Activate();
            view.Window.Owner.Focus();
        }
        _windowViewStates.Remove(view);
        view = null;
        GC.Collect();
        return true;
    }
    return false;
}

public void ShowLastWindow()
{
    if (_windowViewStates.Count > 0)
    {
        var w = _windowViewStates[_windowViewStates.Count - 1];
        CenterWindow(w.Window);
    }

}

Para testar tudo isso foi criado um estilo para um ListBox, onde ele fique na horizontal. Ele irá exibir o conteúdo da lista de janelas gerenciadas. Antes, para definir que uma janela é gerenciada, fazemos uso da AttachedProperty:

<Window x:Class="Test.Window2"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:WindowViewState;assembly=WindowViewState"
    Title="Window2" Height="300" Width="300" Background="Aqua" local:WindowViewState.IsManaged="true">
    <Grid>
        <Button Margin="90,109,114,130" Name="button1">Button</Button>
    </Grid>
</Window>

Depois, no construtor da janela principal do projeto de teste, ligamos o datacontext do ListBox à lista de janelas abertas:

public Window1()
       {
           InitializeComponent();
           WindowsList.DataContext = WindowViewStateManager.Instance;
       }

E lá no ListBox utilizo um recurso do Framework Julmar para ligar o evento de SelectionChanged ao comando definido em WindowViewStateManager.

<ListBox x:Name="WindowsList"
                DockPanel.Dock="Top" 
                Style="{DynamicResource WindowsListTemplate}"
                ItemsSource="{Binding Path=WindowViewStates}" 
                ItemContainerStyle="{DynamicResource WindowsListItem}"  
                IsSynchronizedWithCurrentItem="True" 
                SelectedItem="{Binding Path=SelectedWindow}"
                ItemTemplate="{StaticResource WindowsListDataTemplate}" 
                Height="140">
                <julmar:EventCommander.Mappings>
                    <julmar:CommandEvent Command="{Binding CmdSetFocusWindow}" Event="SelectionChanged" />
                </julmar:EventCommander.Mappings>
            </ListBox>

public ICommand CmdSetFocusWindow { get; private set; }
public ICommand CmdCloseWindow { get; private set; }

private WindowViewStateManager()
{
    CmdCloseWindow = new DelegatingCommand(CloseWindow, CanCloseWindow);
    CmdSetFocusWindow = new DelegatingCommand(FocusWindow, CanFocusWindow);
}

private void FocusWindow()
{
    if (SelectedWindow !=null)
    SetFocusWindow(SelectedWindow.WindowId);
}

public bool SetFocusWindow(int WindowHashCode)
{
    var view = (from v in _windowViewStates where v.WindowId == WindowHashCode select v).First();
    HideAllVisible(view.WindowId);
    CenterWindow(view.Window);
    return view.Window.Activate();
}

Com isso temos um gerenciador de janelas funcional :)  Baixem o código, estudem e comentem !! Sei que aqui não entrei em detalhes profundos, mas qualquer dúvida, é só entrar em contato. Abraço!!

Acabou de ser publicado meu segubndo artigo no www.codeproject.com, onde mostro como criar um controle que realiza uma pesquisa nos itens de um menu.

Veja o post: Improving user experience using WPF and LINQ

No WPF é possivel criar estilos para todo controle visual. Hoje quero mostrar como fazer um estilo que fará com que o controle onde ele está aplicado faça um fade ao ser carregado. Ou seja, qdo a Window abrir, seus controles irão surgir aos poucos. O style pode ser definido como a seguir:

<Page.Resources>
       <Style x:Key="FadeIn" TargetType="FrameworkElement">
           <Style.Triggers>
               <EventTrigger RoutedEvent="FrameworkElement.Loaded">
                   <BeginStoryboard>
                       <Storyboard>
                           <DoubleAnimation
               Storyboard.TargetProperty="(FrameworkElement.Opacity)"
               From="0.0" To="1.0" Duration="0:0:3"/>
                       </Storyboard>
                   </BeginStoryboard>
               </EventTrigger>
           </Style.Triggers>
       </Style> 
</Page.Resources>

Nota: aqui coloquei o estilo em um resource da página que estou usando, mas é totalmente indicado que se crie arquivos de resource para essas situações.

Para utilizar esse estilo:

<TextBlock Name="Message" Text="This is a test." Margin="5,5,5,5"  Style="{StaticResource FadeIn}"/>

<TextBlock Name="Message2" Text="This is a test2." Margin="5,5,5,5"  Style="{StaticResource FadeIn}"/>
<TextBox Width="100" Height="30" Margin="5,5,5,5"  Style="{StaticResource FadeIn}"/>
<Button Content="Fade" Margin="5,5,5,5"  Style="{StaticResource FadeIn}"/>

Como nosso style tem como target o tipo FrameworkElement, podemos aplicá-lo até mesmo em um stackpanel e automaticamente todo seu conteúdo sofrerá o fade:

<StackPanel Orientation="Horizontal" Grid.Row="0" VerticalAlignment="Center" Style="{StaticResource FadeIn}">
            <TextBlock Name="Message" Text="This is a test." Margin="5,5,5,5"  />
            <TextBlock Name="Message2" Text="This is a test2." Margin="5,5,5,5"  />
            <TextBox Width="100" Height="30" Margin="5,5,5,5"  />
            <Button Content="Fade" Margin="5,5,5,5" />
</StackPanel>

Fica aí a dica!

Atualmente estou trabalhando com WPF… e uma das coisas que mais gosto é o mecanismo de DataBinding… simplesmente fantástico!

Mas

para que seus objetos de negócio possam ser utilizados adequadamente pelo databinding, é necessário que sejam implementadas algumas interfaces…

São elas:

• INotifyPropertyChanged – Notifica as mudanças de valores em propriedades
• IEditableObject – Permite que um objeto se torne “editável”, podendo desfazer alterações
• IDataErrorInfo – Adiciona recursos de validação aos objetos, permitindo que a UI seja notificada disso e possa apresentar adequadamente essa situação

Deixo aqui pra vcs a minha implementação disso tudo. Essas classes são utilizadas por mim como base de meus objetos… espero que ajudem a todos que estejam começando com esse incrível framework que é o WPF.

Infelizmente não consigo entrar no SkyDrive… acho que é Telefônica… mas fiz o upload para o Rapidshare:

Baixem aqui!!!

Abraço!

Antes que eu comece, talvez você esteja se perguntando o que é a sigla LOB. LOB são as iniciais de Line of Business. Quando é dito que uma aplicação é LOB, dizemos que ela segue a linha de uma aplicação comercial. Refazendo então a pergunta, o wpf está pronto para aplicações comerciais?.

Vamos rever um pouco a história. Tínhamos cartões perfurados, depois teclados, monitores de fósforo branco, depois verdes e até laranjados. O mouse então ganhou seu espaço…. lembram de um programa chamado DOSSHELL? Era uma espécie de windows explorer do DOS, muito legal para a época.

Hoje ainda temos o mouse, mas a interação do usuário com um sistema informatizado está mudando. Temos webcams, videos, sons, telas sensíveis ao toque, até ao multi-toque. Os monitores estão cada vez maiores, em alta definição, internet, GPS, wireless. A imersão do usuário em relação ao computador evoluiu em muito nos últimos 15 ou 20 anos.

Acredito que a Microsoft percebeu isso e viu algo no futuro, alguns anos a frente e decidiu apostar em algo novo, substituindo sua plataforma gráfica. Trocando o GDI pelo WPF. O GDI possui suas limitações, a principal que vejo é estar preso a pixels. O WPF por sua vez é independente de resolução e ainda pode utilizar o poder de processamento da placa gráfica instalada no micro para renderizar a interface de um aplicativo.

O WPF também oferece recursos necessários para se criar aplicações que satisfaçam as necessidades visuais dos usuários. Ainda temos aí o windowsforms e vamos continuar a tê-lo por um bom tempo. Mas até quando? Creio que aos poucos ele vai deixar de ser utilizado, mas não por determinação da Microsoft e sim pelas escolhas dos usuários finais.

Imagine que você vai comprar um carro. Você vê um Toyota e um Civic. Ambos são similares em qualidade, recursos e segurança e digamos, tem o mesmo preço. Qual você compraria? Com certeza o que você acha mais bonito. Com as aplicações vai acontecer a mesma coisa. Se você possui uma máquina razoável, e lhe é apresentado o mesmo sistema teoricamente só que um utilizando formulários comuns, e outro usando WPF, permitindo requintes de visualização que melhoram a interatividade com o usuário, com qual você ficaria?

Nos EUA já existe uma grande adoção pela tecnologia. Até mesmo a própria Microsoft a está adontando, como prova de sua estabilidade e segurança. Sabe a nova versão do Windows Live Messenger? É feita com WPF. Até mesmo o Dynamics, um CRM/ERP da Microsoft, já possui módulos em WPF. Essa adesão está tomando lugar.

Outro ponto que me chama a atenção está por parte da comunidade de usuários. Em suas listas de discussão muito se fala em como fazer  a coisa certa. Separar as camada de interface da camada de lógica. Um padrão de projeto, utilizado no desenvolvimento do Blend, é divulgado e espalhado pela comunidade, o MVVM (Model-View-ViewModel). Quando você viu algo assim no início do windowsforms?

Por isso digo, sim. O WPF está pronto para o desenvolvimento de aplicações comerciais. Temos o suporte de uma comunidade muito ativa, componentes, mesmo que de terceiros. Contudo isso não significa que vamos sair migrando tudo, mas, se você têm um projeto para os próximos 3 ou 5 anos, comece já em WPF. Isso porque a oferta desenvolvedores nessa área estará maior, creio eu.

Agora existe um ponto importante. Você desenvolvedor, que não é designer… não fique preso apenas aos recursos visuais que o WPF oferece. Ou, contrate algum designer para fazer a interface pra você. Com WPF isso é facilmente possível. Acredito que cada um deve estar no seu lugar. Um exemplo de uma aplicação WPF é o próprio Windows Live Messenger. Une uma boa interface com uma usabilidade legal. Agora, um exempo de um não tão bom programa WPF para o usuário final é o *Chirp, ou agora chamado Blu. Ele é um cliente twitter, segue o link pra vocês baixarem: http://www.thirteen23.com/experiences/desktop/blu/

Mas porque ele não é bom? Veja a Figura abaixo. O primeiro programa é o Blu. O segundo é o TwitterFox.

Bem, não dá nem pra comparar o visual não é? Mas e a experiência do usuário, a usabilidade da coisa? Em seu blog, Tamir Khason apresenta uma lista dos problemas do Blu:

• Utiliza 140MB  de memória;
• Não é possivel ocultá-lo 
• Não notifica novo twitters sem ter que exibir a janela principal do programa
• É necessário presscionar um botão update para ser notificado 
• If you not finished typing, you can either dismiss all text of post it.
• Não é possível digitar mais de 140 caracteres. Se você cola um texto maior, o texto é truncado.
• Para operar o programa, é exigido o mouse
• Não existe uma scrollbar para a lista de twitters exibidos, ou seja, você não pode correr para o último. É preciso passsar um a um.

Vamos ao TwitterFox:

• 10MB de RAM apenas
• Ao clicar no “X” ou pressionar ESC, ele é ocultado 
• Oferece recurso que notifica de novos twitters sem ter que abrir a tela principal
• Once focused text are become active, expanded automatically and ready to write
• Você pode digitar mais de 140 caracteres, contudo ele avisa qdo o limite é excedido permitindo que você ajuste o texto.
• Pode ser operado via teclado.

Para mais detalhes dos problemas funcionais do blu acesse este post: http://khason.net/blog/line-of-business-vs-beautifulness-or-two-dogmas-comparison-as-exemplified-by-two-twitter-applications/ .

Portanto, uma coisa é fato. A beleza de uma aplicação não é tudo… o WPF veio literalmente unir o útil ao agradável. Uma boa aparência com uma grande usabilidade.

Pensem nisso, e comentem, sintam-se à vontade.

Se você está desevolvendo em WPF, segue aqui um ótimo exemplo:

Essa aplição é fruto de um treinamento acontecido lá fora (USA) explicando o padrão M-V-VM e como utilizá-lo de forma eficiente. Mais detalhes a respeito deste demo, acesse o site do Jaime Rodriguez.

Os links pra download:

Apresentação

Código Fonte

Em breve darei minhas considerações sobre o uso do WPF em aplicações comerciais….

Baixem aqui : VS2008 SP1

Baixem aqui:.NET 3.5 SP1 RTM

O WPF oferece um mecanismo de databinding espetacular e com alguns recursos muito interessantes. Devido a isso vou dividir o assunto DataBinding em partes.

Parte I

Uma das características legais, é o conceito de DataContext. DataContext nada mais é do que uma propriedade que existe em qualquer FrameWorkElement e que permite que os controles herdem, de seu parent, a fonte de dados. Um DataContext pode ser ligado diretamente a um objeto CLR ou a um DataSource Provider. Para entender melhor isso imagine a situação onde você possui um Window e esse Windows possui alguns TextBox inseridos nele. Ao se definir que o o DataContext do Window é por exemplo a classe Produto, não é mais necessário indicar o DataContext daqueles TextBox. Eles, por estarem dentro da hierquia do Window, entendem que devem herdar o DataContext de Window, caso outro não seja especificado. Sim, você também pode especificar outros objetos como DataContext, como já citei, cada FrameWorkElement possui a propriedade DataContext.

Como definir um DataContext

Podemos fazê-lo diretamente via XAML:

<Window.Resources>
   <src:ListaProdutos x:Key="Lista"/>
</Window.Resources>
.
.
<DockPanel DataContext="{Binding Source {StaticResource Lista}}">
.
.

E também é possivel fazer isso no code-behind:

List<Produto> Lista := Repository<Produto>.GetAll();
DockPanel.DataContext = Lista;

No ComicReader é feito da seguinte forma:

A direção de um Databind

O que isso significa? isso quer dizer como os dados serão atualizados, se for alterado na UI será passado ou não para o datasource.

• O WPF oferece as seguintes possibilidades, que são definida como Binding.Mode:
• OneWay: Ideal para situação de "somente-leitura". O que é alterado na UI não é repassado para o source.
• TwoWay: Tando o source como a UI se atualizam. idieal para edições. Caso o source sofra alteração por alguma rotina interna do sistema, e não pela intervenção do usuário junto à UI, a UI será atualizada.
• OnTime: O valor contido no source é utilizado para inicializar a UI. Caso o source sofra alguma alteração em seu conteúdo, a UI não é atualizada. É como se fosse algo estático. Mas se por exemplo o Source em si é alterado, por exemplo um nova instância é passada, aí sim a UI reflete a alteração.
• OneWayToSource: É o inverso do OneWay. O que vc alterar na UI vai para o source.

Por hoje é só. Quero deixar estes posts sempre pequenos assim, para faciliar a leitura. Na parte II veremos como implementar o TwoWay de  maneira eficaz e quando que a notificação de mudança de dados é disparada.

Até lá.

Literalmente... fiquei de queixo caído. Vejam este vídeo:

Sistema Médico

Isso me faz pensar no que teremos nos próximos anos... tudo bem que esse tipo de coisa demora pra ser usado aqui no Brasil, mas mesmo assim... imagine bibliotecas onde não existam livros e sim várias mesas "surface" e os livros estão lá, digitalizados..... e muitas outras coisas....

Temos que começar a nos preparar pra isso... e sair na frente no mercado. Vejo que um novo "boom" pode começar. Na época onde ninguém sabia nada de informática, os poucos que sabiam alguma coisa injetaram tempo e dinheiro nisso e hoje estão bem. Creio que haverá uma demanda de especialistas em design e interatividade e quem estiver pronto pra isso, poderá sair na frente e se destacar ao longo dos anos.

Abraço

Layout é uma das coisas mais importantes em qualquer projeto WPF, bem, não só WPF mas em qualquer projeto que necessite de uma interação com usuários. Para quem vem de uma origem de desenvolvimento desktop, seja windows forms ou Delphi, o WPF oferece mais que apenas "arrastar e clicar". Você realmente precisa pensar em como dispor os controles.

O que o WPF oferece?

Essencialmente temos os seguintes controles de layouts disponibilizados:

• Canvas
• Stackpanel
• Wrappanel
• Dockpanel
• Grid

Na figura abaixo vemos os controles de layout que utilizei para o desenvolvimento do ComicReader X

Canvas

Este é um dos controles de layout mais fáceis de se utilizar. Semelhantemente aos formulários windows forms ou VCL, nele podemos posicionar os controle utilizando as coordenadas X,Y.

StackPanel

Também é bem fácil de ser utilizado, nele os controles são empilhados verticalmente ou horizontalmente. Isso pode ser feito pela propriedade Orientation.

Wrappanel

O wrappanel distribui os controles que estão contidos nele. No ComicReader X ele é utilizado para criar a barra de movimentação da janela.

Dockpanel

É muito útil e pode servir como layout base para qualquer janela WPF. Através dele podemos construir os mais variados layouts, posicionando por exemplo uma menu ao topo, uma área livre à direita e até mesmo um outro controle de layout à esquerda. Sim, é possível aninhar controles de layout. Cada controle que é inserido em um dockpanel pode ser alinhado através da propriedade DockPanel.Dock, como visto abaixo.

O Dockpanel também oferece uma propriedade muito interessante, a LastChildFill, que faz com que o último controle inserido nele preencha todo o espaço restante. Utilizei essa propriedade para fazer o Scrollbox preencher todo o espaço disponível da janela

Grid

O Grid é semelhante a uma tabela, com ele definimos colunas e linhas, e dentro delas inserimos os controles.

Conclusão

Confesso que demorei um pouco até chegar nesse layout, que defino como apropriado para o ComicReader X. Achei meio complicado montar isso direto no Blend, de forma visual. Foi mais fácil eu rascunhar em um papel e depois no VS2008 mesmo, direto no XAML, definir os controles de layout.

Muitos pensam que só porque temos um "code-behind" em WPF já estamos separando a UI das regras de negócio. Mas o negócio é mais profundo... vejam nessa série de posts do Dan Crevier como aplicar um padrão chamado DataModel-View-ViewModel

Olá pessoal,

Comecei a fazer um aplicativo WPF que l

ê arquivos CBR (formato usado para histórias em quadrinhos, muitos profissionais liberais disponibilizam seus trabalhos nesse formato).

Abaixo tem um vídeo o ComicReader X em operação. Qdo finalizá-lo por completo vou publicar o que aprendi, dificuldades e facilidades que enfrentei. Também vou disponibilizar o programinha gratuitamente.

Abraço !

Muito legal o que nos reserva o futuro, não muito distante... vejam os vídeos...

Este abaixo usa uma aplicacao WPF

Então baixe o conteúdo deste incrível site !!!  Video aulas e Labs !!!

WPF Bootcamp

Baixe os fontes aqui...

Utilizando o Blend construí a interface conforme figura 1 abaixo

No último post foi mencionado que iríamos “converter” o resultado do método getPessoas para o tipo ObservableCollection<>. Então em Window1.xaml.cs criei uma classe People conforme listagem abaixo.

   1:  public class People : ObservableCollection<Pessoa>

   2:      {

   3:          public People()

   4:              : base()

   5:          {

   6:              PessoaDAO dao = new PessoaDAO();

   7:              List<Pessoa> lista = new List<Pessoa>();

   8:              lista = dao.getPessoas();

   9:              if (lista.Count > 0)

  10:              {

  11:                  foreach (Pessoa obj in lista)

  12:                  {

  13:                      Add(obj);

  14:                  }

  15:              }

  16:   

  17:          }

  18:      }

Com isso pronto, vamos utilizar nossa classe People como um DataSource para o ListBox. No painel Data clicamos sobre o botão [+CLRObject] e na janela que surge, escolhemos a classe People, conforme figura abaixo

Ao adicionar a classe People como um DataSource o blend automaticamente ajusta para nós o código xaml tornando esse DataSource um recurso disponível. Veja isso no trecho abaixo do código xaml.

<Window.Resources>
    <ObjectDataProvider x:Key="PeopleDS" d:IsDataSource="True" ObjectType="{x:Type Agenda:People}"/>
</Window.Resources>

Com o DataSource disponível, agora é possível fazer o binding. Então clicamos com o botão direito no ListBox e no menu que aparece, escolhemos a opção “Bind ItemsSource to Data”. Veja figura abaixo.

Na janela que aparece, vamos escolher o datasource, dando um clique duplo sobre ele e então clicar no botão Finish. Veja figura abaixo.

A linha no XAML referente o ListBox foi alterada pra representar a situação de binding.

<ListBox Margin="54,184,40,53" IsSynchronizedWithCurrentItem="True" ItemsSource="{Binding Mode=OneWay, Source={StaticResource PeopleDS}}"/>

Salve o projeto. Se você tentar executar pelo Blend, vai gerar um erro (não sei porque), mas se você abrir o projeto no VS, tudo funciona perfeitamente.

No próximo post, vamos criar uma tela para inserção das Pessoas na nossa agenda. Pontanto, não percam.

Um dos objetivos do WPF, além de melhorar o apelo visual de um sistema, é separar a lógica de negócio envolvida da camada de interface, permanecendo na interface sua própria lógica de apresentação.

Para mim, lógica de apresentação são requisitos como: “se o saldo da conta for negativo, o valor deve ser apresentado em vermelho”, e lógica de negócio é a rotina que vai calcular o saldo da conta.

Pensando nisso comecei um pequeno exemplo. Nele temos uma classe Pessoa e seu DAO. Para o exemplo estou o utilizando o db4o, inspirado no artigo do Luciano Lima, na última edição da revista mundo NET . Na figura 1 vemos a representação gráfica das classes.

Nossa aplicação será uma agenda. Sua interface será construída em WPF, acessando os objetos da classe Pessoa acima.

O desafio

Vamos listar as pessoas cadastradas em um listbox, que é um controle muito versátil dentro do WPF. Para listar uma coleção de objetos descobri que manter a interface atualizada sempre que a fonte mudar, essa fonte deve implementar INotifyPropertyChanged. O que isso quer dizer ?

Através da classe DAO nós vamos obter a lista de pessoas, essa é nossa fonte, o listbox será nossa interface. Veja que o método getPessoas() retorna List<Pessoas>, como fazer o List implementar INotifyPropertyChanged ? E se vc não tem acesso aos fontes da classe de negócio, você é apenas o “cara” que desenvolve a interface.

A resposta

Como diz o jargão... “seus problemas acabaram”... o WPF oferece a classe ObservableCollection, que já implementa as peculiaridades de INotifyProprertyChanged. Na nossa aplicação WPF vamos “transformar” os dados de List<Pessoa> para ObservableCollection<Pessoa>, mas isso fica para o próximo post....

Até lá

PS.: Eu não sou nenhum guru de WPF e .NET não, apenas gosto de compartilhar o que aprendo...