Em determinadas situações pode haver a necessidade de criar um lookup com filtro de dados e/ou retornar várias informações. 


Vamos estudar o exemplo do frmCadCLIENTES.




Acesse o frmCadCLIENTES, aba COMERCIAL, para acompanhar a explicação do código dos eventos ONCLICK e ONENTER






O código do evento ONCLICK será dinamicamente associado ao ONCLICK do BOTÃO de pesquisa que será criado em RUNTIME.


A procedure rc_LookUpSearchFilter passa para o RadCORE as informações para pesquisar "CLIENTES" desde que o "CLIENTE ATUAL( registro )" não seja exibido e passa uma lista de campos que poderão ser usados tanto para pesquisa quanto para retorno, ou seja, passamos um parâmetro com um "WHERE" para filtrar a pesquisa que será feita pelo lookup.


Após a seleção da pesquisa ser feita, é testado se o registro está em edição então, acionamos a função rc_GetLookUpField para preencher os dados que precisamos.


Como a QUERY/DATASOURCE de pesquisa lookup é criada dinamicamente, esta função, é usada para acessar esta query e seu respectivo campo.


Alimentando um lookup como retorno


Se você precisar retornar uma informação para alimentar também um lookup, você deve adicionar o campo na lista do "rc_LookUpSearch" e usar como referência as linhas comentadas.


No caso do BAIRRO( apenas um possível exemplo de uso ), como este campo também é um LOOKUP, associamos o CODIBAIRRO( código da chave primária ) e atualizamos o lookup para poder ser preenchido com sua respectiva descrição( rc_LookUpUpdateData ).





O código do evento ONENTER foi adicionado por quê no exemplo que estamos estudando, o LOOKUP de CLIENTES vai exibir também a pesquisa pelo código do cliente, logo, ao informar um código precisamos atualizar os dados, pois, assim que é o lookup perde o foco, aciona o ONENTER.


EXIBINDO VALORES DE RETORNO AUTOMÁTICO


Uma necessidade comum é exibir um valor de retorno de um lookup apenas para exibição, ou seja, não será editado, mas é possível salvar o valor no banco de dados - caso precise.


Nesse caso, temos mais uma possível variação na formação da 'sintaxe' do lookup:


edLkpTABELA_SetDS_FIELDNAME



Veja a imagem abaixo:




Ao selecionar uma CIDADE em edLkpCIDADES, o campo "Código IBGE" é atualizado automaticamente SEM NENHUM código.


A mesma condição utilizada no ONCLICK do LOOKUP da conta, é aproveitado. 


Ao criar um campo com o sufixo _SETDS o RadCORE vai associar dinamicamente o DATASOURCE que foi criado exclusivamente pra esse LOOKUP, tornando fácil a exibição.


É possível salvar o retorno do "setds" adicionando o seguinte pseudo-comando no propriedade HINT:


[[saveto:field]]


"field" é o nome do campo no dataset de destino que receberá o conteúdo.


Informando apenas "saveto:" sem um "field" explícito, o RadCORE assume que, na tabela de destino, existe um campo de mesmo nome da tabela de origem, ou seja, se montamos:


edLkpCIDADES_SetDS_CODIIBGE com [[ saveto: ]]


é por quê existe um campo com o nome "CODIIBGE" para salvar o retorno.




Created with the Personal Edition of HelpNDoc: Easy EBook and documentation generator