Segundo Carlos Mattos, diretor de tecnologia da WD5, empresa sorocabana parceira da multinacional na construção do portal, outros animais do zôo terão sua vez como apresentador das atividades e conteúdos na web. O projeto também prevê a instalação de câmaras no local para registrar as imagens dos animais e disponibilizá-las on-line. No parque existirá, ainda, um ponto de acesso livre à internet com conexão sem fio.

Veja a matéria completa publicada no Jornal Cruzeiro do Sul (http://www.cruzeironet.com.br/materia.phl?editoria=39&id=70333).

O novo site do Parque Zoológico Municipal Quinzinho de Barros é vitrine para a nova tecnologia Silverligth desenvolvida pela Microsoft. É o que revelou o diretor da multinacional, Carlos Ferreira, ontem à tarde, durante cerimônia de lançamento do portal. A ferramenta eletrônica permite uma maior manipulação de fotos e imagens no campo virtual. Para Ferreira, implementar a tecnologia em um Zoológico cujo trabalho é reconhecido quase que mundialmente, expõe de maneira positiva a qualidade do produto.

Veja a matéria completa publicada no Jornal Cruzeiro do Sul (http://www.cruzeironet.com.br/materia.phl?editoria=39&id=76076). 

select tipoeis.*, ROW_NUMBER() OVER (order by idtipoeis) - 1 as Posicao from tipoeis

Introdução

O LINQ-to-SQL oferece uma coleção de APIs (Application Program Interface) para auxiliar o desenvolvedor a identificar, avaliar e solucionar conflitos de concorrência nas suas aplicações.

Concorrência Otimista

O modelo otimista para gerenciamento de conflitos de concorrência utiliza o método Resolve(RefreshMode) apresentado pelo Namespace System.Data.Linq. Este método avalia o conflito e atualiza os dados de acordo com o que foi definido pelo desenvolvedor através da Enumeração RefreshMode.

Enumeração RefreshMode

Esta enumeração determina como o método Resolve() irá tratar os conflitos de concorrência expostos pela Exception ChangeConflictException. Abaixo estão os membros desta enumeração com uma breve descrição:

Entendendo o RefreshMode

Analisando a Enumeração acima, o desenvolvedor pode ter uma interpretação equivocada sobre o comportamento do método Resolve(). Para esclarecer isso abaixo estão três cenários diferentes que ilustram o comportamento do método Resolve para cada Membro da Enumeração RefreshMode.

Cenário de Exemplo

Considere o cenário abaixo. Uma Exception do tipo ChangeConflictException é gerada quando o Usuário1 tenta submeter suas alterações ao banco de dados, porque o Usuário2 efetivou modificações nos dados enquanto o Usuário1 estava manipulando o mesmo registro.

Resolvendo conflitos mesclando dados (KeepChanges)

O membro KeepChanges pode ser utilizado para reconciliar diferenças entre os valores esperados e os valores reais contidos no banco de dados antes de você tentar submeter a atualização novamente. Este membro mescla dados do cliente com dados contidos na base.

Resolvendo conflitos mantendo os dados do banco (OverwriteCurrentValues)

O membro OverwriteCurrentValues pode ser utilizado para reconciliar diferenças entre os valores esperados e os valores reais contidos no banco de dados antes de você tentar submeter a atualização novamente. Este membro sobrescreve os valores atuais (no cliente) com os valores encontrados no banco de dados.

Resolvendo conflitos sobrescrevendo os valores do banco de dados (KeepCurrentValues)

O membro KeepCurrentValues pode ser utilizado para reconciliar diferenças entre os valores esperados e os valores reais contidos no banco de dados antes de você tentar submeter a atualização novamente. Este membro sobrescreve os valores do banco de dados com os valores atuais no cliente.

Exemplo de implementação do modelo de concorrência otimista

O procedimento abaixo apresenta o código necessário para implementação do modelo otimista. A linha em destaque mostra a chamada do método Resolve() onde o desenvolvedor pode escolher a ação desejada de acordo com a enumeração RefreshMode.

try

{

    db.SubmitChanges(ConflictMode.ContinueOnConflict);

}

catch (ChangeConflictException e)

{

    Console.WriteLine(e.Message);

    foreach (ObjectChangeConflict occ in db.ChangeConflicts)

    {

        occ.Resolve(RefreshMode.KeepCurrentValues);

    }

}

Muitas aplicações .NET utilizam o Namespace System.Drawing.Printing para criar documentos de impressão (PrintDocument) e enviá-los para impressora ou para janela de PrintPreview.

Um cenário comum é encontrado em aplicações WindowsForms. Imagine um ponto de venda que utiliza uma aplicação WindowsForms para impressão de cupons, comandas entre outros jobs. Considere que o operador desta aplicação utiliza o teclado para executar todos os comandos e entradas de dados (o uso do mouse é minimizado). Em cenários como este, é comum que a tecla [ENTER] seja pressionada repetidas vezes para completar um processo de entrada de um novo pedido por exemplo.

Tive um cenário semelhante implementado no módulo de caixa de um restaurante, o volume de comandas entregues pelos garçons ao caixa é grande e o procedimento do caixa para inserir os pedidos no sistema é rápido e agilizado pelo uso do teclado. Ao final do processe de inserir uma nova comanda, o sistema verifica os itens inseridos e envia um job para diferentes impressoras dependendo dos itens, por exemplo, os itens "pratos quentes" são impressos na cozinha, enquanto as bebidas são enviadas para a impressora do bar para que o pedido seja atendido.

O problema é que com o tempo, o usuário do caixa, tende a digitar as entradas cada vez mais rápido. Isso faz com que a tecla [ENTER] seja pressionada repetidas vezes, algumas para avançar para o próximo campo e outras para acionar os botões de comando. Contudo, é comum que o usuário pressione esta tecla pelo menos 1 vez mais além do necessário. Se isso ocorre quando a janela de diálogo "Generating Previews" está sendo exibida, o job de impressão é cancelado.

Imagine a situação, você está na mesa, solicitou um prato, o garçon emitiu a comanda, entregou ao caixa, o caixa registrou o pedido, mas, sem perceber, pressionou a tecla [ENTER] mais uma vez cancelando o envio da impressão para a cozinha. Seu prato demora, você reclama para o garçon, ele reclama para o caixa, o caixa culpa a cozinha e no final de tudo a cupla recai sobre o sistema que devia ter previsto este cenário e utilizado uma implementação diferente.

A solução: A solução é simples, porém os exemplos de impressão na documentação do MSDN não aborda nenhum cenário semelhante. Basicamente o que você precisa é mudar o PrintController do seu objeto PrintDocument. Por padrão, o PrintController é um objeto do tipo PrintControllerWithStatusDialog, assim toda vez que o método Print() é invocado, o PrintControllerWithStatusDialog exibe a janela Generating Previews. Basta substituí-lo pelo objeto StandardPrintController que a janela não será mais exibida. A sintaxe correta para esta construção é:

pd.PrintController = new StandardPrintController();
pd.Print();

Simples assim!

O website Hansel Minutes (http://www.hanselminutes.com/default.aspx?showID=101) publicou o áudio da entrevista com Shawn Burke da Microsoft. Nesta entrevista, Scott Hanselman e Carl Franklin conversam com Shawn Burke sobre a nova versão do Visual Studio que possibilita que o desenvolvedor estenda a depuração de suas aplicações até as classes do .NET Framework. A entrevista está no idioma original (Inglês), mas vale a pena conferir.