Depois que uma exception é lançada o CLR começa uma busca no call stack por um bloco que faça o tratamento dessa exception.
O AppDomain.FirstChanceException é um evento que ocorre antes do CLR começar a procurar no call stack por um ponto da aplicação que faz o tratamento dessa exception, isto é, antes da exception ser tratada este evento é acionado.
Este evento funciona como um notificador, não afetando a exception ou cancelando o seu disparo.
A criação de botões customizados para o Kinect for Windows é bastante simples de ser feita. Para tanto faremos uso de recursos nativos do WPF, orientação a objetos e o Kinect for Windows Developer Toolkit.
Por padrão, o Windows Developer Toolkit contém dois modelos de botões: o KinectTileButton e o KinectCircleButton. O KinectTileButton geralmente é utilizado para navegação entre páginas, enquanto que o KinectCircleButton é utilizado para execução de ações e barras de ferramentas.
Redimensão de imagens é uma tarefa comum do dia-a-dia para quem trabalha com computadores. Redimensionamos imagens em tarefas do trabalho, lazer, e do cotidiano. Esta é uma tarefa que pode ser executada facilmente com um editor de imagens, mas é bastante custosa quando queremos redimensionar um conjunto de imagens.
Por conta do trabalho (e tempo) gasto com a redimensão de múltiplas imagens, e pela vontade de não depender da instalação de nenhum editor de imagens, acabei por criar um programa que faz essa redimensão em massa. Fiz isso quatro anos atrás e, como o programa se tornou “popular” entre amigos e familiares, percebi que era preciso fazer uma nova versão com tecnologias mais novas.
O CLR considera que existem dois tipos de threads: foreground e background threads.
Foreground threads executam com uma prioridade elevada. Esse tipo de thread evita que a aplicação se encerre antes que tenham executado todo o seu trabalho.
Em contraponto, as background threads não são executadas com prioridade elevada. Background threads são finalizada imediatamente pelo CLR assim que todas as foreground threads de uma aplicação (leia managed assembly) encerram sua execução, sem lançar nenhuma exceção.
Sem o garbage collector seu código não seria como ele é hoje. Provavelmente você se preocuparia muito mais com o consumo de recursos e descarte de instâncias de objetos não mais utilizadas. Também é fato que pouco se pensa sobre o funcionamento do garbage collector. Este post visa destacar brevemente o funcionamento do garbage collector.
Callback functions são blocos de código executável que são passados como parâmetro para outro código, que fica responsável por invocá-los quando apropriado.
O modo como callback functions são suportados em cada linguagem de programação é diferente, mas são frequentemente implementados como subrotinas, expressões lambdas ou ponteiros de função.
O tratamento das linguagens não-gerenciadas sobre os callback functions é limitada a apenas um endereço de memória. Este endereço de memória não contém nenhuma informação adicional sobre o tipo de retorno, o número de parâmetros ou os tipos de dados dos parâmetros.
Com o aumento da quantidade de funcionalidades construídas com Javascript novos requisitos surgem a cada dia. Requisitos que antes não eram tão comuns (como a manipulação/movimentação de objetos gráficos em um browser) tornam-se triviais, pois aumentam a usabilidade da aplicação tornando o seu uso fácil, agradável, rápido e de fácil assimilação.
O exemplo abaixo demonstra como é possível identificar a sobreposição de objetos HTML utilizando código Javascript.
Uma tarefa bastante recorrente durante o desenvolvimento de sistemas é a criação de rotinas de log. E o Entity Framework facilita a nossa vida quando temos de fazer isso.
Com o Entity Framework podemos criar uma customização que encapsule os comandos que serão enviados para o banco de dados e então adicionar uma lógica que gere os registros de log necessários para cada operação.
O padrão Unit of Work mantém um rastreamento sobre todas as alterações que possam alterar sua fonte de dados durante uma transação. Assim, quando todas as alterações já tiverem sido executadas o padrão fica responsável por persistir todas na fonte de dados.
Geralmente, não somos responsáveis por implementar este padrão, acabamos por consumi-lo em ferramentas de persistência, como: Entity Framework, NHibernate e LINQ to SQL.
Trabalhando em alguns sistemas, nos foi recomendado, pelo próprio cliente, que fizéssemos uso do operador NOLOCK em todos os comandos de consulta que fizéssemos no banco de dados. Isso parece uma atitude exagerada, mas por experiência do cliente, com receio de deadlocks, tínhamos de seguir à risca essa indicação.
O SQL Server utiliza recursos de bloqueio (tanto para escrita quanto leitura) para garantir a integridade dos dados. Enquanto executamos uma transação seguimos o conceito ACID (se você não conhece este conceito, veja este post Entity Framework 6 – Database.BeginTransaction() e Database.UseTransaction(DbTransaction)). Por conta disso, dentro de uma transação qualquer comando paralelo que tente acessar os dados com os quais estamos trabalhando entram nesse bloqueio, e assim são forçados a aguardar o término de nossa transação.
Fernando Henrique Ferreira 