Atenção: esse artigo tem uma palestra complementar. Clique e assista!

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

A API do Windows é um conjunto de arquivos .dll que fazem parte do sistema operacional, porém, expondo várias funções ao meio externo. Nós podemos usar a API do Windows da mesma forma que usamos qualquer outra dll, porém o Delphi contém uma unit que já tem várias das funções mais usadas mapeadas e declaradas.

Durante nossas considerações sobre a API vamos analisar, em cada caso, um cenário onde sua aplicação seria necessária e depois discutiremos como usá-la. Exceto quando o uso da API for muito simples, caso em que inverteremos a ordem: mostraremos primeiro como usar e depois onde seria aplicável. Vamos expor ao longo do artigo diversas dicas do uso de APIs do Windows para a resolução de diversos problemas. Muitas das coisas que conhecemos como dicas nada mais são do que o uso de funções do Windows, que poderiam ser usadas em qualquer linguagem.

O registro do Windows é um conjunto de vários arquivos, dentre eles system.dat e user.dat, mas não se limitando a esses. As informações de configuração do Windows e de diversos outros softwares são armazenadas no registro em forma de árvore, hierarquicamente, de forma muito semelhante a arquivos e diretórios. O formato como esses dados são armazenados e como o arquivo é “feito” não nos interessará porque a Microsoft providenciou na sua API diversas funções para ler e gravar informações do registro. E o Delphi possui uma classe chamada TRegistry que torna o uso dessas funções ainda mais fácil e mais transparente para o desenvolvedor.

Criando janelas dentro de outras janelas

Dentre os vários modelos de disposição de janelas que temos para nossos sistemas, podemos citar o MDI (Multiple Document Interface), onde todas as janelas de um sistema são filhas de uma janela principal, como era a interface dos documentos do Word antes da versão 2007. Uma outra forma é a conhecida SDI (Single Document Interface), onde cada janela abre em um espaço independente. Muito popular hoje é o padrão TDI (Tabbed Document Interface), onde as janelas são dispostas em abas, assim como o Internet Explorer 7 e 8 e o Mozilla Firefox. Imagine um cenário onde você precise, sem usar forms MDI, criar formulários um dentro do outro em vários níveis. Isso é perfeitamente possível com o uso da função SetParent e a propriedade Handle das janelas.

No Windows todo controle gráfico, até mesmo botões e caixas de texto, são considerados janelas, e toda janela tem um Handle, que é um número inteiro positivo que identifica unicamente uma janela. Todas as funções do Windows que usam janelas usam o Handle. Para nós, isso é transparente porque a VCL e outras bibliotecas do Delphi fazem isso automaticamente por nós sem percebermos.

Vamos simular uma aplicação MDI em vários níveis onde não usaremos os forms MDI do Delphi. Além disso, para podermos criar várias instâncias da mesma janela sem usar as variáveis públicas com o nome do formulário e, para evitar vazamentos de memória, vamos projetar um mecanismo no qual poderemos criar quantos formulários quisermos de cada tipo e estes serão destruídos no momento em que os fecharmos clicando no botão X do formulário.

Crie uma aplicação Delphi Win32 e vamos dar o nome de ExemploSetParent a essa aplicação. Vamos criar três formulários, chamados respectivamente de frmPrimeiro, frmSegundo e frmTerceiro e sendo os nomes das units como uFrmPrimeiro, uFrmSegundo e uFrmTerceiro respectivamente. Coloque em cada um dos formulários componentes diferentes, ao seu gosto, como Labels identificando o nome do formulário.

Assegure-se que o primeiro form seja maior que o segundo, e este maior que o terceiro, apenas para, quando colocarmos os formulários um dentro do outro eles não ocultarem controles do próprio formulário. Depois veremos como usar barras de ferramentas e painéis para limitar o espaço que uma janela filha pode tomar. O primeiro formulário será o formulário padrão de nossa aplicação. Os outros dois podemos dizer que seriam um documento e seu detalhe respectivamente.

Vamos colocar no primeiro formulário um botão para abrir o segundo, e no segundo um botão para abrir o terceiro. Seus nomes serão btAbrirSegunda e btAbrirTerceira, respectivamente. O Caption de ambos pode ser simplesmente Abrir. Antes de editarmos o código dos botões vamos editar o código do evento OnClose do segundo e terceiro formulários. No Object Inspector selecione o evento OnClose e digite o seguinte código:

  Action := caFree; 

Faça isso tanto no segundo como no terceiro formulário. Isso fará com que, ao se fechar o formulário, seu método Free seja executado automaticamente, sendo assim liberado da memória. Não usaremos a variável pública da unidade do formulário.

Vá em Project > Options e assegure-se de que apenas a frmPrimeira será criada com a execução do programa, sendo as outras duas criadas sob demanda, conforme a Figura 1.

Figura 1. Ordem de criação dos formulários

A unit Windows provavelmente já está declarada no uso de todas as units desse projeto, então não precisaremos nos preocupar. Usaremos o método SetParent dessa unit, mas para não confundir com o método SetParent do form, que tem o mesmo nome, usaremos Windows.SetParent.

Faça com que o primeiro formulário use o segundo, clicando em File > Use unit> uFrmSegundo. Analogamente faça com que o segundo formulário use o terceiro. Vamos dar um duplo clique no botão btAbrirSegunda, do primeiro form, e digitar o código da Listagem 1.

Listagem 1. Botão abrir do primeiro formulário

  procedure TfrmPrimeira.btAbrirSegundaClick(Sender: TObject);
  begin
    with TfrmSegunda.Create(Self) do
    begin
      Show;
      Windows.SetParent(handle, Self.Handle);
    end;
  end; 

A função SetParent da unit Windows aceita dois parâmetros, o primeiro é o handle da janela filha e o segundo é o handle da janela que será a mãe. Não devemos confundir esse Parent com os conceitos de Herança, da Programação orientada a objetos, e muito menos com o conceito de Owner dos componentes do Delphi. Esse sistema de Parent das janelas do Windows é apenas uma hierarquia visual.

Colocamos Self como Owner do form que acabamos de criar (segunda) por uma razão especial: podemos criar centenas de “segundos formulários” dentro do primeiro. Se fecharmos todos eles, cada um será destruído automaticamente, porém, se fecharmos o primeiro sem fechar os seus filhos, sendo o primeiro formulário Owner (dono) de todos eles, ele mesmo se encarregará de destruir, automaticamente, todos os seus filhos. Esse é o mecanismo de Owner do Delphi. Poderíamos passar Application como Owner, que também funcionaria, com um pequeno problema: só quando a aplicação inteira fosse fechada é que esses formulários seriam destruídos. Embora isso não faça diferença do primeiro para o segundo, fará diferença do segundo para o terceiro. Por isso decidimos colocar a responsabilidade de cada pai “visual” destruir seus filhos.

Se por um acaso tivéssemos passado nil como Owner, criaríamos um Memory Leak enorme, porque não teríamos referência a nenhuma das dezenas de filhos que criamos, então ao fechar o formulário principal os filhos permaneceriam na memória sem serem destruídos. Esse vazamento iria se revelar apenas quando fechássemos o formulário principal com os filhos abertos. Se fechássemos os filhos antes isso não iria ocorrer, porque cada um ia ser destruído no momento do seu fechamento.

Analogamente, o botão btAbrirTerceira no segundo formulário fará a mesma coisa, mas criando um objeto TFrmTerceira. Veja como ficou a ...