A solução foi levar todos os nomes de itens para um TListBox respeitando a ordenação atual e deixar o usuário livremente posicionar os nomes sem se preocupar com o dataset. Quando o usuário estiver satisfeito com a ordem dos itens, clica em OK e o programa atribui de uma só vez todos os valores de “posicao” ao dataset conforme os índices dos nomes no ListBox.

A idéia foi rapidamente implementada pelo Fábio Costa, que trabalha comigo. A solução inicial usava apenas teclas de atalho e botões para mover o item selecionado para cima e para baixo, para a primeira ou última posição. O problema é que ele começou a tomar gosto pela coisa e danou a ter idéias. Por que não arrastar e soltar um item com o mouse para mudar sua posição? Por que não fazer o mouse dar scroll sozinho no ListBox quando o usuário estiver arrastando para além da primeira ou da última posição do controle?

Assim, a coisa foi evoluindo para uma solução mais e mais sofisticada. Não é que ficou bom?

Várias técnicas foram utilizadas para chegar ao resultado final: TActionList com teclas de atalhos (Ctrl+Home, Ctrl+Up, Ctrl+Down, Ctrl+End) e habilitação condicional, manipulação dos eventos OnStartDrag, OnDragOver, OnDragDrop e OnDragEnd, execução de mensagens do Windows pelo método Perform, scroll de TListBox por código, identificação do item do ListBox dada uma posição (X, Y) de tela, timers com intervalos dinâmicos (1s para começar, 0.2s para continuar a rolagem).

Veja o código de exemplo comentado abaixo, sem a parte de banco de dados. Você também pode fazer o download do código fonte do projeto de demonstração.

unit ListBoxReorder_Form;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ActnList, StdCtrls, ExtCtrls;
 
type
  TScrollZone = (szNone, szTop, szBottom);
 
  TMainForm = class(TForm)
    ActionList: TActionList;
    ListBox: TListBox;
    ScrollTimer: TTimer;
    DownAction: TAction;
    DownButton: TButton;
    FirstAction: TAction;
    FirstButton: TButton;
    LastAction: TAction;
    LastButton: TButton;
    UpAction: TAction;
    UpButton: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FirstActionExecute(Sender: TObject);
    procedure FirstActionUpdate(Sender: TObject);
    procedure UpActionExecute(Sender: TObject);
    procedure UpActionUpdate(Sender: TObject);
    procedure DownActionExecute(Sender: TObject);
    procedure DownActionUpdate(Sender: TObject);
    procedure LastActionExecute(Sender: TObject);
    procedure LastActionUpdate(Sender: TObject);
    procedure ListBoxStartDrag(Sender: TObject; var DragObject: TDragObject);
    procedure ListBoxDragOver(Sender, Source: TObject; X, Y: Integer;
      State: TDragState; var Accept: Boolean);
    procedure ListBoxDragDrop(Sender, Source: TObject; X, Y: Integer);
    procedure ListBoxEndDrag(Sender, Target: TObject; X, Y: Integer);
    procedure ScrollTimerExecute(Sender: TObject);
  private
    FScrollZone: TScrollZone;
    procedure InitListBox;
    function IsSelected: Boolean;
    procedure MoveItem(NewIndex: Integer);
    function GetScrollZone(X, Y: Integer): TScrollZone;
  end;
 
var
  MainForm: TMainForm;
 
implementation
 
{$R *.dfm}
 
{ Inicializa ListBox.Items para demonstração }
procedure TMainForm.FormCreate(Sender: TObject);
begin
  InitListBox;
  ListBox.DragMode := dmAutomatic;
end;
 
{ Inicializa ListBox.Items com nomes de arquivos da pasta System32 }
procedure TMainForm.InitListBox;
var
  F: TSearchRec;
begin
  ListBox.Items.BeginUpdate;
  if FindFirst('C:\Windows\System32\*.*', faArchive, F) = 0 then
    repeat
      ListBox.Items.Add(F.Name);
    until FindNext(F) <> 0;
  FindClose(F);
  ListBox.Items.EndUpdate;
  ListBox.ItemIndex := 0;
end;
 
{ Indica se algum item do ListBox está selecionado }
function TMainForm.IsSelected: Boolean;
begin
  Result := ListBox.ItemIndex <> -1;
end;
 
{ Move um item do ListBox para outra posição,
  seleciona a nova posição no ListBox e
  atribui o foco ao ListBox. }
procedure TMainForm.MoveItem(NewIndex: Integer);
begin
  ListBox.Items.Move(ListBox.ItemIndex, NewIndex);
  ListBox.ItemIndex := NewIndex;
  ListBox.SetFocus;
end;
 
procedure TMainForm.DownActionExecute(Sender: TObject);
begin
  MoveItem(ListBox.ItemIndex + 1);
end;
 
procedure TMainForm.DownActionUpdate(Sender: TObject);
begin
  DownAction.Enabled := IsSelected and
    (ListBox.ItemIndex < ListBox.Items.Count - 1);
end;
 
procedure TMainForm.FirstActionExecute(Sender: TObject);
begin
  MoveItem(0);
end;
 
procedure TMainForm.FirstActionUpdate(Sender: TObject);
begin
  FirstAction.Enabled := IsSelected and (ListBox.ItemIndex > 0);
end;
 
procedure TMainForm.LastActionExecute(Sender: TObject);
begin
  MoveItem(ListBox.Items.Count - 1);
end;
 
procedure TMainForm.LastActionUpdate(Sender: TObject);
begin
  LastAction.Enabled := IsSelected and
    (ListBox.ItemIndex < ListBox.Items.Count - 1);
end;
 
procedure TMainForm.UpActionExecute(Sender: TObject);
begin
  MoveItem(ListBox.ItemIndex - 1);
end;
 
procedure TMainForm.UpActionUpdate(Sender: TObject);
begin
  UpAction.Enabled := IsSelected and (ListBox.ItemIndex > 0);
end;
 
{ Inicializa FScrollZone com szNone }
procedure TMainForm.ListBoxStartDrag(Sender: TObject;
  var DragObject: TDragObject);
begin
  FScrollZone := szNone;
end;
 
{ Define se a posição do mouse aponta para um item válido
  do ListBox que permita soltar o item arrastado (Accept).
  Inicia ou cancela o timer de scroll automático. }
procedure TMainForm.ListBoxDragOver(Sender, Source: TObject; X, Y: Integer;
  State: TDragState; var Accept: Boolean);
var
  NewZone: TScrollZone;
begin
  Accept := (Source = ListBox) and
    (ListBox.ItemAtPos(Point(X, Y), True) <> -1);
  NewZone := GetScrollZone(X, Y);
  if NewZone <> FScrollZone then
  begin
    FScrollZone := NewZone;
    if (FScrollZone <> szNone) then
    begin
      ScrollTimer.Interval := 1000;
      ScrollTimer.Enabled := True;
    end
    else
      ScrollTimer.Enabled := False;
  end;
end;
 
{ Move item selecionado para nova posição }
procedure TMainForm.ListBoxDragDrop(Sender, Source: TObject; X, Y: Integer);
var
  NewIndex: Integer;
begin
  NewIndex := ListBox.ItemAtPos(Point(X, Y), True);
  if NewIndex <> -1 then
    MoveItem(NewIndex);
end;
 
{ Desliga timer de scroll no fim do drag and drop }
procedure TMainForm.ListBoxEndDrag(Sender, Target: TObject; X, Y: Integer);
begin
  ScrollTimer.Enabled := False;
end;
 
{ Retorna a szTop se mouse está na área da primeira linha visível do
  ListBox, szBottom se mouse está na área da última linha visível do
  ListBox ou szNone caso contrátrio. }
function TMainForm.GetScrollZone(X, Y: Integer): TScrollZone;
begin
  if (Y < ListBox.ItemHeight) then
    Result := szTop
  else
    if (Y >= ListBox.ClientHeight - ListBox.ItemHeight) then
      Result := szBottom
    else
      Result := szNone;
end;
 
{ Faz scroll de uma linha para cima ou para baixo conforme a zona
  de scroll definida pela posição do mouse. Redefine intervalo
  do timer para 0.2s após o primeiro scroll. }
procedure TMainForm.ScrollTimerExecute(Sender: TObject);
begin
  ScrollTimer.Interval := 200;
  if (FScrollZone = szTop) then
  begin
    ListBox.Perform(WM_VSCROLL, SB_LINEUP, 0);
    ListBox.Perform(WM_VSCROLL, SB_ENDSCROLL, 0);
  end
  else
    if (FScrollZone = szBottom) then
    begin
      ListBox.Perform(WM_VSCROLL, SB_LINEDOWN, 0);
      ListBox.Perform(WM_VSCROLL, SB_ENDSCROLL, 0);
    end;
end;
 
end.

As convenções existem por um motivo: estabelecer um entendimento comum entre as partes sobre alguma coisa. Se uma das partes (no caso, a aplicação ou o usuário) ignorar a convenção a coisa não funciona.

A regra é clara: a tecla para pular de um campo é TAB, não ENTER.

Quem estabeleceu a regra não fui eu, foi a indústria ao longo dos anos. A publicação em 1987 pela IBM do manual Common User Access (CUA) foi um marco importante. A Microsoft seguiu essa cartilha no desenvolvimento da interface de usuário do Windows, até porque ajudou a criá-la durante a fase de cooperação do OS/2 com a IBM. Hoje em dia a Microsoft tem padrões mais atualizados que cobrem novos aspectos do Windows XP e do Windows Vista, como acessibilidade, bitmaps de alta definição, cores, transparências, interação com dispositivos USB, etc.

Quando os fabricantes de teclados colocam o mesmo conjunto de teclas de suporte, como Home, End, Insert, Delete, Tab, F1 a F12 e Print Screen, também estão respeitando as convenções da indústria.

A tecla ENTER tem um papel bem definido em caixas de diálogo, que é confirmar a aceitação do conteúdo e fechar a janela. Ou seja, equivale a um clique no botão OK. Similarmente a tecla ESC fecha a janela cancelando os dados, equivalendo a um clique no botão Cancelar.

TButton.Default, OK?

Por ser uma convenção, a API do Windows suporta nativamente desde a sua primeira versão essas de teclas de atalho em caixas de diálogo. Você não precisa fazer nada para que as combinações TAB e Shift+TAB mudem o foco dos controles. O que muita gente não sabe é que a API também trata nativamente ENTER e ESC.

A biblioteca VCL do Delphi torna tudo muito mais simples. Basta usar as propriedades tipo Boolean Default e Cancel de TButton para aceitar as teclas ENTER e ESC, respectivamente.

Definir TButton.Default = True faz mais que aceitar a tecla ENTER. Desenha um botão diferenciado, com a borda mais destacada, o que indica visualmente ao usuário qual é o botão padrão que será acionado ao se teclar ENTER.

Para o usuário acostumado a usar teclado, é extremamente conveniente (necessário até, eu diria) que a tecla ESC (TButton.Cancel = True) também seja tratada para sair da janela sem salvar nenhum dado.

Exceções

Exceções existem, é claro. Uma tela de entrada de dados de grande volume, ainda mais se os usuários nem sempre têm os olhos voltados para o teclado ou se a entrada é basicamente numérica, é uma possível candidata. Sem dúvida é mais fácil digitar com a mesma mão direita o ENTER (o TAB fica à esquerda) e porque as teclas ENTER (as duas!) são sempre maiores e verticais, facilitando o operador “acertar” a digitação sem olhar.

Outra justificativa comum é que os usuários estão acostumados a usar um programa antigo para DOS e são habituados a usar ENTER. Na minha opinião não é uma boa desculpa. É a hora de ensinar a convenção que todo mundo usa. Quando esses mesmos usuários navegarem na Internet vão ter que usar TAB para mudar de campo e ENTER para confirmar um formulário de qualquer forma.

Não podemos perder de vista que é a exceção não é a regra. A convenção é nossa amiga. A convenção facilita a vida do usuário e do desenvolvedor.

Na década de 90 os programadores descobriram a interface MDI (”Multiple Document Interface”) no Windows. Achavam o máximo aquele monte de janelas superpostas. Como o Delphi tornava muito fácil criar esse tipo de interface, qualquer programinha tinha múltiplas janelas flutuando na área cliente e não faltavam aquelas famigeradas opções de janelas em cascata, lado-a-lado, minimizadas, etc. A gente se sentia até orgulhoso de fazer um sistema com interface semelhante à do Office. Melhor ainda se os ícones fossem os mesmos da Microsoft.

O que nós desenvolvedores ignorávamos então é que os usuários finais não dão a mínima pra nada disso. Os usuários gostam de fazer uma coisa de cada vez, com início, meio e fim. Lidar com várias janelas abertas na mesma aplicação só torna mais confuso o trabalho.

Muitos se assutaram quando o próprio Office, que havia popularizado o modelo MDI, abandonou a estratégia. A Microsoft fez muitas pesquisas de opinião e laboratórios de usabilidade para chegar a conclusão que não valia a pena insistir naquilo. Ficamos perdidos em busca de um novo modelo de interface de usuário.

A alguns anos veio com o FireFox e outros navegadores modernos a inspiração para uma idéia salvadora: apresentar janelas em páginas selecionáveis por abas. Definiu-se um novo modelo, que alguns chamam de TDI (”Tabbed Document Interface”), em oposição ao antigo MDI. As janelas abertas (documentos) são fáceis de visualizar e selecionar. Cada aba utiliza grande parte da área cliente, dando ao usuário a confortável sensação que está sempre trabalhando com uma janela “maximizada”.

É fácil, no entanto, observar que os usuários finais preferem. O mais simples e direto modelo de interface é o mais eficaz. Muitas vezes os mais complexos modelos de interação acabam reduzidos pela forma com que o usuários utilizam a um modelo simples de uma única janela que ocupa toda área do monitor, conhecido como SDI (”Single Document Interface”).

A propósito, qual seria o modelo de interface de um sistema web? Pense no Americanas.com, no Orkut e no site do seu supermercado favorito. Não é TDI, nem MDI, evidentemente. Cada página funciona na mesma área cliente, alternando-se conforme o opção escolhida pelo usuário. O que mais se aproxima é o bom e velho SDI.

Todos esses modelos de interface têm uma coisa em comum: o conceito de documento. Seja um documento de texto, uma planilha eletrônica ou uma página web, todos os documentos são da mesma natureza em uma interface MDI, TDI ou SDI.

Ainda hoje, por falta de opção ou por retrógrada herança da cultura de modo texto dos anos 80 muitos desenvolvedores ainda utilizam uma grande tela vazia (ou pior, um imenso bitmap espalhafatoso com o logo da empresa no fundo), um menu e uma barra de botões no topo da janela e mais nada. Esse modelo é o que se pode chamar NDI: “No Document Interface”. A cada opção de menu, abre-se uma caixa de diálogo diferente. Pode não ser bonito ou elegante, mas é funcional. Os clientes entendem.

O fato é que os usuários imediatamente absorvem a metáfora do menu que abre e fecha opções e volta ao estado inicial. Dá até para imaginar um usuário ensinando a outro como usar a aplicação: “Escolhe essa opção para cadastrar e essa outra para tirar um relatório…”.

Janelas e Documentos

Trazer o conceito de documentos para um cliente nativo Windows não é fácil. Pelo menos, não é óbvio. Aplicações de negócio têm relatórios, telas de cadastro, consulta e configuração e lidam com grupos de informação diferentes (clientes, produtos e vendas, por exemplo), cada um com uma forma de apresentação própria.

Na busca de um modelo orientado a documentos, seja TDI ou mesmo SDI, torna-se necessário definir um tipo abstrato de objeto que possa representar todos os tipos de telas que se deseje apresentar na aplicação, similar ao conceito de documento dos browsers e editores de texto.

O Delphi não traz nada disso pronto, mas oferece inúmeros recursos que possibilitam a sua implementação. A chave é a programação orientada a objetos. Veja bem, eu disse programação, não interface orientada a objetos.

Uma hierarquia de classes de forms é chamada “herança visual” na VCL. Podemos usar herança visual para definir um form base que implemente o conceito de documento numa interface TDI ou SDI.

É razoável que todos os forms documento tenham alguma funcionalidade em comum. Todos os “documentos” podem ser abertos (abrir datasets, iniciar controles), fechados (fechar datasets, liberar objetos de memória), copiar para clipboard (seja um TEdit ou um TChart) e muitos até impressos. Esses são exemplos de ações comuns. Outras, no entanto, não podem ser abstraídas sem prejuízo de entendimento. Por exemplo, “Calcular” não é um bom candidato para uma ação comum, porque não é natural calcular um cadastro, por exemplo.

Há várias formas de implementar funções específicas de um tipo de documento: botões direto na janela, objetos TAction integrados em um TActionList global, menu merge, etc.

Balancear o que deve ser abstraído e o que deve ser especializado é sutil. Isso vale, é bem verdade, para todos os modelos de representação hierárquica e orientada a objetos, de modelos de dados a interfaces de usuário. Felizmente, no caso das interfaces de usuário você sempre tem o recurso de sair da sua mesa e ir perguntar os maiores interessadods, os usuários: “Para você, o que é melhor?”.

Descobri que se pode usar componentes dbExpress para acessar qualquer banco de dados MySQL que deseje no Delphi 2007, desde que seja um banco de dados da versão 5.0 do MySQL.

Por mais natural que pareça que funcione a versão estável mais recente, no caso a 5.1 (eu não digo nem a 6.0, em alpha-release), não adianta que não funciona. Tentei ainda usar o driver dbExpress que vem no recém-lançado Delphi 2009 e o resultado foi o mesmo. Só quando eu desinstalei o MySQL 5.1 e instalei o MySQL 5.0 na máquina deu certo. Rápido e fácil como era de se esperar da dupla dinâmica MySQL e dbExpress.

Aparentemente, manter compatibilidade entre versões da libmySQL.dll não é uma grande preocupação para a Sun. Se serve de algum consolo, percebi incompatibilidade similar na versão mais recente do driver de MySQL para Ruby on Rails. O driver 2.7.3 funciona bem com MySQL 5.0, mas falha com o MySQL 5.1 ao gerar comandos simples como “SHOW TABLES”.

Nada justifica, no entanto, os erros catastróficos que o Delphi exibe quando falha em abrir uma query usando a DLL cliente do MySQL 5.1. Primeiro aparece uma mensagem de erro “Commands out of sync; you can’t run this command now”. Até aí tudo bem, é uma mensagem do próprio MySQL - quer dizer, não está tudo bem, mas é compreensível. Só que a partir da segunda tentativa de abrir o dataset já é mostrada uma apavorante mensagem de “Access Violation” na IDE do Delphi.

A qualidade do design do DBX 4 é excelente. Ainda assim, como não é possível controlar a qualidade dos drivers e DLLs cliente de terceiros, seria importante dedicar mais atenção ao tratamento de erros nas interfaces para não da margem a esse tipo de instabilidade.

No caso específico do MySQL acho importante a CodeGear correr para tornar os seus drivers compatíveis com as versões mais recentes, porque existem por aí em produção bancos de dados MySQL de todas as versões e simplesmente dizer que a culpa é da Sun não vale.

Resumindo as informações que já se tem do Delphi Prism:

• Adeus VCL.NET - já vai tarde.
• A linguagem traz recursos avançados como nullable types e “future” types, generics, sequences e query expressions (LINQ)
• Funcionará com as tecnologias WPF, Silverlight, ASP.NET and LINQ
• ADO.NET e ASP.NET providers baseados em dbExpress
• DataSnap cliente, para conectar servidores DataSnap feitos em Win32
• BlackFish SQL database
• Precisará do .NET Framework 3.5 para rodar o VisualStudio
• Produz executáveis compatíveis com qualquer versão do .NET Framework a partir da 1.1
• Produz executáveis compatíveis com o framework .NET Mono, para Linux e Mac
• Onde já tem Visual Studio instalado será apenas adicionado o plug-in de linguagem ao sistema
• Onde não tem Visual Studio este será instalado apenas com a linguagem Delphi Prism (sem C# e VB)
• Não será preciso adquirir uma nova licença do Visual Studio
• Ainda não é possível desenvolver aplicativos .NET Compact Framework. A culpa não é da CodeGear, mas da Microsoft, que fez o CF fechado para as linguagens dela e não ao CLR
• A CodeGear/Embarcadero e a RemObjects são parceiros comerciais. Uma não comprou, nem vai comprar a outra
• O linguagem em si continuará a cargo da equipe de compiladores da RemObjects

O que é chato é criar campos persistentes para um dataset na IDE do Delphi e ver o nome dos componentes TField ficar com o nome formatado como na base de dados.

Dependendo da sua convenção, um dataset chamado cdsCliente, por exemplo, pode criar objetos TField com nomes estranhos como cdsClienteNOME, cdsClientenome_cliente ou cdsClienteENDERECO_BAIRRO. Todo esses casos fogem ao estilo padrão de nomenclatura de identificadores no Delphi (Object Pascal Style Guide, de Charles Calvert).

Decidido a encontrar de uma vez por todas uma solução para esse problema, fui em busca da fonte da VCL. A princípio, a unit DB era o lugar que me pareceu mais óbvio para buscar o momento em que um TField é criado. De fato, é mesmo criado ali por um método de TFieldDef, mas… coisa estranha, em nenhum momento a propriedade Name é atribuída.

Descobri afinal que a definição do nome de um TField é feita somente pela IDE, através de “component editors”. Graças a São Borland! Assim não teria que criar um descendente de TDataSet, o que seria um preço alto demais a pagar. Tudo que tive que fazer é criar um desdencente de TDSDesigner, sobrescrever o método virtual DoCreateField reformatando a propriedade Name como eu queria e registrar o novo “component editor”.

O código final tem apenas 74 linhas e uma vez instalado como um package na IDE é totalmente transparente a sua utilização. Apenas adicione os campos pelo “Fields Editor” e a formatação dos nomes será automática.

Nos exemplos anteriores, com o pacote instalado os componentes TField seriam criados como cdsClienteNome, cdsClienteNomeCliente ou cdsClienteEnderecoBairro, livres de sublinhados e maiúsculas.

O código fonte está disponível para download.

Só testei em Delphi 2007. Quem quiser testar em outras versões e me dar um feedback será bem vindo. De antemão eu sei que não vai compilar direto em versões anteriores ao Delphi 6, por causa das mudanças na unit DesignIntf, mas isso pode ser ajustado sem muita dificuldade.

Por exemplo:

procedure AV;
var
  List: TStringList;
begin
  // AV porque List é um objeto não alocado
  List.Add('teste');
 
  // ok, porque List foi previamente alocado
  List := TStringList.Create;
  List.Add('novamente');
 
  // AV, porque o objeto foi desalocado e o valor
  // da variável List é um ponteiro inválido
  List.Free;
  List.Add('outra vez');
 
  // AV da mesma forma que antes, apenas a
  // variável aponta para nil ($0000:0000)
  List := nil;
  List.Add('e finalmente');
end;

Essas são receitas certas pra cometer violações de acesso de leitura de memória. Normalmente, em blocos de código pequenos esse tipo de coisa não ocorre, porque temos mais visibilidade e controle sobre o tempo de vida das variáveis. O problema fica maior quando o objeto é um parâmetro recebido de outra parte qualquer do código. Quem garante que o valor passado como parâmetro é válido?

Só pra ficar claro:

procedure ShowText(List: TStringList);
begin
  ShowMessage(List.Text); // AV? List é válido?
end;
 
procedure TestAV;
var
  Strings: TStringList;
begin
  ShowText(Strings);
end;

Aqui TestAV chama ShowText passando como parâmetro um valor de objeto inválido, porque nunca foi alocado. Seja o valor igual a nil ou uma valor aleatório qualquer (dependendo do contexto, a variável pode conter “lixo” de memória), quando ShowText usar a propriedade Text do objeto vai produzir um AV.

O que eu uso para prevenir esses casos é um Assert básico.

O código acima com Assert ficaria assim:

procedure ShowText(List: TStringList);
begin
  // Exceção (EAssert) caso List seja inválido
  Assert(List <> nil);
 
  // A partir daqui é seguro usar List
  ShowMessage(List.Text);
end;

Assert tem como parâmetro um valor condicional (Boolean). Se falhar (False), dispara uma exceção EAssert. A vantagem é que, ao contrário de uma exceção de violação de acesso, a IDE vai te mostrar certinho onde ocorreu a violação, isto é, vai parar o debugger naquela linha do Assert. Sem uma verificação desse tipo, seria muito mais difícil identificar em todo o seu projeto o ponto que deu problema.

Se você quiser, pode ainda usar usar o segundo parâmetro opcional de Assert para dar uma mensagem ao usuário. Por exemplo: “Assert(List <> nil, ‘A função ShowText não recebeu um objeto TStringList válido’)”.

Outra vantagem do Assert é que depois que você estiver confiante da correção do código (quando esse dia chegar :) ), você poderá desativar um checkbox nas opções de compilação do Delphi para
simplesmente omitir todo o código de verificação de “Assert” globalmente no projeto (lembre-se de dar um Build depois que mudar essa opção).

Dá muito trabalho? “Better safe, than sorry.”

Que atire a primeira pedra quem nunca fez um “Access Violation”. ;-)

É claro que eu não fui o primeiro a ter essa necessidade, então antes de começar a quebrar a cabeça fui buscar no Google as soluções que já tinham sido criadas. Primeiro encontrei um comentário de Deborah Pate (TeamB) no newsgroup Borland “oleautomation”. Foi um bom começo, mas ainda faltava muito.

Mais tarde encontrei os posts de Nikolay Pavlov - nem acredito que encontrei um parente de Pavlov e ainda um que programa em Delphi! Nikolay estava bem mais próximo do que eu precisava, inclusive com o tratamento recursivo de arrays.

Como o código é livre, copiei, fiz diversas alterações e melhoramentos e estou publicando aqui a minha versão para quem se interessar.

***

A compra da CodeGear pela Embarcadero foi comercial e juridicamente finalizada a poucas semanas. Aqui no Brasil que eu saiba continua a mesma empresa e houve poucas mudanças na direção, embora agora se reportem a outra companhia lá fora.

***

Andreano Lanusse apresentou um preview do Tiburon em português no dia 1 de agosto. A apresentação foi interessante e deixou uma boa impressão. O mais importante foi perceber que a CodeGear está mesmo investindo em melhorias no Delphi e em particular no Delphi Win32, ao contrário do que os pessimistas de plantão vinham dizendo. No blog do Andreano tem alguns artigos em português sobre as novidades do Delphi 2008 2009 (codinome Tiburón).

***

“Anonymous methods” é um dos features mais polêmicos. No mínimo, é idéia interessante com um nome infeliz. Como apontou um comentário de Caleb, “anonymous methods” são de fato “closures“. O recurso de “closure” é comum em algumas linguagens modernas, mas ainda assim tem aplicabilidade questionável.

***

É engraçado para nós brasileiros a grande ênfase que se está dando a conversão completa de toda as libraries nativas Delphi (RTL, VCL, DBX, etc.) para Unicode. Eu lembro de ter assistido uma palestra em uma Borcon em que um representante da Borland americana foi pego de surpresa em público ao descobrir durante a apresentação que ninguém no Brasil tinha problemas com acentuação e ninguém estava ansioso por Unicode.

***

Unicode é bom para a globalização do Delphi. Por isso acaba sendo bom para todos nós, mesmo não tendo necessidade direta de usar Unicode (eu pelo menos não tenho pretensão de escrever programas em mandarin).

***

Não entendi ainda bem como funciona, mas fiquei admirado com a nova diretiva {$MethodInfo ON}, que permite inclusive o novo DataSnap evocar métodos remotos sem necessidade da parafernália Microsoft COM, interfaces, etc.

Atualização: Leonel comentou que a diretiva já existia em versões anteriores.

***

Aliás, por que diabos a CodeGear foi a essa altura do campeonato investir em melhorias na tecnologia COM? Há quem diga que estão “maqueando” correções de bugs como melhorias…

****

Delphi TStringBuilder é legal. Já existe a muitos anos em bibliotecas gratuitas como JCL, mas é legal.

***

Eu quero meu Delphi Win32 com generics!!!

Vantagens de usar Stored Procedures:

• SP podem incluir lógica condicional, cursores, chamar outros SP, funções, etc.
• SP são parametrizáveis (TParams)
• SP são transações atômicas
• SP são escritos em SQL
• SP podem ser facilmente atualizados com o sistema no ar
• SP têm plano de execução previamente “compilado”

Desvantagens de usar Stored Procedures:

• SP não são portáveis entre bancos de dados diferentes
• SP são somente-leitura
• SP de SELECT dificultam a geração automática de SQL de atualização

Usar SP não fere nenhum princípio de desenvolvimento multicamadas. De fato, o SQL fica no servidor, não no cliente. Tem gente que prefere não ter nenhuma lógica no banco de dados e tratá-lo como um simples repositório de dados. Outros, pelo contrário, entendem que toda lógica de acesso a dados precisa estar no servidor de banco de dados. Finalmente, há aqueles, entre os quais eu me incluo, que preferem um equilíbrio, pesando custos e benefícios caso a caso.

Nos próximos artigos vou mostrar como usar SP para obter dados do servidor de aplicação e como usar SP para atualizar os dados em um ApplyUpdates.

No exemplo da imagem anterior, se você deixar o mouse sobre o grid e girar o botão de rolagem para baixo enquanto mantém a tecla Control pressionada a fonte será aumentada até ficar como a imagem abaixo.

Semelhante ao que fizemos anteriormente para implementar a rolagem pelo mouse em um TScrollBox, tudo que é preciso é sobrescrever os eventos OnMouseWheelDown e OnMouseWheelUp com o tratamento adequado para aumentar ou diminuir o tamanho da fonte do grid, respectivamente.

O código principal é este:

procedure TMainForm.DBGrid1MouseWheelDown(Sender: TObject;
  Shift: TShiftState; MousePos: TPoint; var Handled: Boolean);
begin
  if ControlKeyPressed then
  begin
    ChangeGridFontSize(DBGrid1, +1);
    Handled := True;
  end;
end;
 
procedure TMainForm.DBGrid1MouseWheelUp(Sender: TObject;
  Shift: TShiftState; MousePos: TPoint; var Handled: Boolean);
begin
  if ControlKeyPressed then
  begin
    ChangeGridFontSize(DBGrid1, -1);
    Handled := True;
  end;
end;

Se a tecla Control não estiver pressionada, o valor de Handled continua False e o funcionamento normal da classe prossegue, rolando as linhas do grid. Se o resultado da função ControlKeyPressed (veja abaixo) é True, o botão Control está pressionado e devemos modificar o tamanho da fonte.

function ControlKeyPressed: Boolean;
begin
  Result := Boolean(GetKeyState(VK_LCONTROL) shr 31) or
    Boolean(GetKeyState(VK_RCONTROL) shr 31);
end;

GetKeyState é uma função da API do Windows e a forma (bizarra) de interpretar seu resultado é verificar se o bit mais significante do resultado é 1. Na função eu verifico se o botão esquerdo ou o direito está pressionado naquele momento.

A mudança de tamanho da fonte em si é realizada pela rotina ChangeGridFontSize:

type
  TDBGridHack = class(TDBGrid);
 
procedure ChangeGridFontSize(Grid: TDBGrid; Delta: Integer);
var
  Size: Integer;
begin
  Size := Grid.Font.Size + Delta;
  if (6 <= Size) and (Size <= 32) then
  begin
    Grid.Font.Size := Size;
    TDBGridHack(Grid).LayoutChanged;
  end;
end;

Primeiro note que a procedure recebe um parâmetro Delta que pode ser positivo ou negativo. Se positivo, aumenta a fonte. Se negativo, diminui. A rotina limita o novo tamanho de fonte à faixa 6..32 por segurança.

E o que é esse TDBGridHack? Err… bem… digamos que é um “código de flexibilização”. :-)

LayoutChanged é um método protegido de TDBGrid. Para poder usá-lo, precisamos declarar no escopo da unit uma classe descendente de TDBGrid. Dessa forma a nova classe será nossa “amiga” e poderemos usar seus métodos protegidos (mas não conte isso pra ninguém!). LayoutChanged é chamado para corrigir o número de linhas exibidas no grid quando a fonte é diminuida.

Você pode fazer o download desse projeto de exemplo e experimentar a mesma técnica com outros tipos de componente.

Os componentes da DevExpress são excelentes exemplos de boa programação orientada a objetos. O conceito de GridView, por exemplo, é abstraído de tal forma que podemos ter visualização como tabelas com linhas e colunas, gráficos ou cartões (”cards”), como os do gerenciador de contatos do Outlook. Por essa razão as “colunas” de um GridView são referidas como “Items”, já que não faria sentido chamar de coluna uma série de gráfico ou uma linha de um cartão.

A fonte de dados que alimenta um grid é também generalizada pela classe TcxCustomDataSource. A descendente TcxDBDataSource é especializada para trabalhar com datasets e implementa filtragem, agrupamento e cálculo de sumários. O componente TcxGrid não presume nada sobre a forma como os dados são obtidos, lidos e escritos. Lida apenas com os métodos e propriedades de TcxCustomDataSource e com isso permite o polimorfismo.

É fácil implementar um novo descendente de TcxCustomDataSource para lidar com TStrings ao invés de TDataSet. No exemplo abaixo são implementados apenas os métodos básicos que precisam ser sobrescritos em qualquer descendente de TcxCustomDataSource.

O resultado é um list box editável. Você pode usar as teclas de atalho “Ins” para inserir uma linha e “Ctrl+Del” para deletar. Também pode adicionar uma linha no final da lista no modo “append”.

{**********************************************}
{                                              }
{  cxStringsDataSource                         }
{  by Daniel Maltarolli                        }
{  http://singularsistemas.com.br/blog         }
{                                              }
{  01) 2008-05-22 Initial release              }
{                                              }
{**********************************************}
 
unit cxStringsDataSource;
 
interface
 
uses Classes, cxCustomData;
 
type
  TcxStringsDataSource = class(TcxCustomDataSource)
  private
    FStrings: TStrings;
  protected
    function AppendRecord: TcxDataRecordHandle; override;
    procedure DeleteRecord(ARecordHandle: TcxDataRecordHandle); override;
    function GetRecordCount: Integer; override;
    function GetValue(ARecordHandle: TcxDataRecordHandle; AItemHandle: TcxDataItemHandle): Variant; override;
    function InsertRecord(ARecordHandle: TcxDataRecordHandle): TcxDataRecordHandle; override;
    procedure SetValue(ARecordHandle: TcxDataRecordHandle; AItemHandle: TcxDataItemHandle; const AValue: Variant); override;
  public
    constructor Create(Strings: TStrings);
  end;
 
implementation
 
uses SysUtils, Variants;
 
{ TcxStringsDataSource }
 
constructor TcxStringsDataSource.Create(Strings: TStrings);
begin
  inherited Create;
  FStrings := Strings;
end;
 
function TcxStringsDataSource.AppendRecord: TcxDataRecordHandle;
begin
  FStrings.Append(EmptyStr);
  DataChanged;
  Result := TcxDataRecordHandle(FStrings.Count - 1);
end;
 
procedure TcxStringsDataSource.DeleteRecord(
  ARecordHandle: TcxDataRecordHandle);
begin
  FStrings.Delete(Integer(ARecordHandle));
  DataChanged;
end;
 
function TcxStringsDataSource.GetRecordCount: Integer;
begin
  Result := FStrings.Count;
end;
 
function TcxStringsDataSource.GetValue(ARecordHandle: TcxDataRecordHandle;
  AItemHandle: TcxDataItemHandle): Variant;
var
  Index: Integer;
begin
  Index := Integer(ARecordHandle);
  Result := FStrings.Strings[Index];
end;
 
function TcxStringsDataSource.InsertRecord(
  ARecordHandle: TcxDataRecordHandle): TcxDataRecordHandle;
var
  Index: Integer;
begin
  Index := Integer(ARecordHandle);
  FStrings.Insert(Index, EmptyStr);
  DataChanged;
  Result := ARecordHandle;
end;
 
procedure TcxStringsDataSource.SetValue(ARecordHandle: TcxDataRecordHandle;
  AItemHandle: TcxDataItemHandle; const AValue: Variant);
var
  Index: Integer;
begin
  Index := Integer(ARecordHandle);
  FStrings.Strings[Index] := VarToStrDef(AValue, EmptyStr);
end;
 
end.

Você precisa atribuir por código um objeto TcxStringsDataSource a GridView.DataController.CustomDataSource. É importante que o GridView seja um TcxTableView, não um TcxDBTableView. Para isso você precisará primeiro deletar no Form Designer o TcxDBTableView que é criado por default, criar um novo TableView e atribuí-lo a GridLevel1.

As propriedades do GridView são semelhantes àquelas usadas na parte um, porém deixando o grid editável e “OptionsSelection.CellSelect = True”.

Veja um exemplo completo de utilização no arquivo anexo.

Pra começar, você pode usá-lo para selecionar registros em um dataset através de um campo qualquer. Basta configurar algumas propriedades do TcxGridDBTableView para obter o “look and feel’ de um autêntico TListBox data-aware.

Pra começar, adicione a coluna para o campo que você quer selecionar. Pode também ser mais de uma coluna, mas aí já sai um pouquinho do padrão comum de um ListBox. Em seguida, ajuste as propriedades do GridView como indicado abaixo.

Em OptionsView ocultamos o Header, o GroupByBox e as linhas de grid. ColumnAutoWidth garante que a coluna ocupe perfeitamente a largura interna do grid. CellEndEllipsis dá um toque sofisticado, mostrando reticências (”…”) no fim de um item que não caiba totalmente na área cliente.

OptionsView.CellEndEllipsis = True
OptionsView.ColumnAutoWidth = True
OptionsView.GridLines = glNone
OptionsView.GroupByBox = False
OptionsView.Header = False

Em OptionsSelection, precisamos desabilitar CellSelect, para ter a barra de seleção esperada.

OptionsSelection.CellSelect = False

Em OptionsBehavior, temos alguns extras interessantes. CellHints mostra automaticamente hints popup quando o mouse para sobre uma linha cujo texto que não cabe inteiramente na largura. IncSearch ativa a busca incremental pelo teclado. PullFocusing produz o efeito de rolar as linhas quando o mouse é clicado sobre uma linha e arrastado enquanto é mantido pressionado.

OptionsBehavior.CellHints = True
OptionsBehavior.IncSearch = True
OptionsBehavior.PullFocusing = True

Finalmente, em OptionsData desabilitamos a edição, para ter um grid read-only.

OptionsData.Deleting = False
OptionsData.Editing = False
OptionsData.Inserting = False

Pronto. Com essas configurações é possível selecionar um registro simplesmente mostrando o “list box” para o usuário escolher pelo nome, com direito a busca incremental, reticências e hints para textos longos, além da barra de rolagem horizontal, que por default um ListBox não tem.

Na próxima parte deste artigo, vou mostrar como usar um TcxGrid para editar o conteúdo de um objeto TStrings qualquer usando um “CustomProvider”.

A Scalabium tem também os componentes SMExport, que permitem exportar um dataset ou qualquer outra fonte de dados para uma série de formatos.

Eu comprei o pacote com os dois, SMImport e SMExport. Hoje em dia para exportar eu uso só o DevExpress, mas continuo confiando no SMImport para dar aos usuários das minhas aplicações a possibilidade de importar sozinhos dados de diversos formatos. É uma funcionalidade muito apreciada pelos usuários finais e por isso o investimento se paga rapidamente.

Hoje foi publicada uma nova versão do SMImport que implementa o formato de arquivo 12 do Excel, além de várias outras melhorias e atualizações.