Propriedades obsoletas ou removidas

Durante mais de 30 anos, nosso objetivo principal é melhorar nosso produto (usando novos conceitos e tecnologias) ao mesmo tempo que garantimos a compatibilidade das aplicações 4D. Como sabem bem os primeiros usuários de 4D, sempre colocamos muito esforço na compatibilidade e podemos encontrar aplicações 4D no mundo todo que foram criadas anos e anos atrás, com versões antigas de 4D e de  sistema operativo, e que ainda funcionam com as últimas revisões do produto.

Infelizmente, às vezes é dificil mesclar tecnologias antigas e novas:

• 4D deve oferecer novas tecnologias, APIs e novos paradigmas aos desenvolvedores
• Os sistemas operativos mudam todos os dias e, às vezes, deixam de utilizar suas próprias APIs antigas

É por isso que 4D às vezes  necessita etiquetar alguns comandos e funcionalidades como obsoletos, o que significa que algum dia serão eliminados da linguagem em uma versão principal futura

Deixar que os desenvolvedores saibam o que está em desuso e que tipo de substituto pode ser usado em seu lugar toran muito mais cômodo implementar a mudança em seu código: não há urgência, não há pressão, e o desenvolvedor tem tempo de sobra para realizar as mudanças necessárias.

Cada comando obsoleto tem o prefixo "_o_" e não está disponível em listas 4D (editor de código, funcionalidade de autocompletar, etc.). Os comandos obsoletos (ou desaprovados) não são eliminados do código existente e continuarão funcionando normalmente enquanto sejam compatíveis. Ainda é possível (mas não recomendado) agregar um comando obsoleto em um método simplesmente ingressando seu nome com o prefixo "_o_"; Se interpretará corretamente.

Uma lista alfabetica destes comando pode ser consultada no anexo Deprecated Commands de Manual de linguagem 4D.

Os comandos abaixo, anteriormente em desuso, foram eliminados de 4D e não devem ser utilizados no seu código. Se os chamar, ativarão um erro (Error 33 - Comando ou função não implementado).

Atenção: as funcionalidades de verificação de sintaxe ou compilação não podem detectar as chamadas aos comandos eliminados. Deve verificar seu código para ter certeza de que não contenha nenhuma chamada aos comandos eliminados.

Projetos 4D representam uma evolução importante de arquitetura de banco de dados 4D. Já que projetos 4D se baseiam nas últimas exigências de interface de software e as mais modernas tecnologias, eles não são compatíveis com propriedades legados, listadas abaixo. Estas propriedades estão agora obsoletas e não devem mais ser usadas em seus bancos de dados, para uma melhor conformidade com a arquitetura futura de projeto 4D.

Para informação detalhada na arquitetura de projeto em 4D, veja 4D projects documentation em developer.4d.com. 4D fornece uma ferramenta de exportação automática para converter bancos de dados .4db para projetos. Durante a exportação, propriedades obsoletas são convertidas automaticamente, removidas ou geram erros (ver Converter bancos de dados a Projetos).

Os objetos e propriedades de formulário abaixo não cumprem com os requisitos atuais da interface e estão em desuso. Não são compatíveis com Formulários Dinâmicos , e geram um aviso ou erro no arquivo de registro de conversão de projeto (ver comentários).

As opções de estrutura de banco de dados estão obsoletas e podem gerar erros no arquivo de histórico de conversão de projeto (ver comentários).  

Os editores e funcionalidades de Caixa de ferramentas abaixo estão em desuso não são compatíveis com projetos:

Os modos de compatibilidade herdados não são compatíveis com projetos. As configurações de compatibilidade são restabelecidas para um novo banco de dados  durante a exportacção do projeto. Se seu banco de dados ainda for baseada em configurações de compatibilidade antigas, deve considerar ao atualizar.

Lhe recomendamos que leia a série de publicações de blog dedicadas a como se desfazer da configuração de compatibilidade.

A partir de 4D v17 R5, as versões 32 bits de 4D já não são produzidas ou entregues. Só estão disponíveis as versões 64 bits, o que permite às aplicações 4D aproveitar ao máximo esta poderosa arquitetura.

XSLT não está disponível em 4D. Chamar um comando XSLT gerará um erro 33 "Comando ou função não implementado".

Para dar assistência a nossos clientes que continuam utilizando XSLT em 4D, escolhemos confiar na livraria XSL PHP, que oferece uma completa API que lhe permite realizar todas as operações necessárias para suas transformações XSL. Esta livraria é uma ferramenta eficaz que pode substituir facilmente os comandos removidos  _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER e _o_XSLT GET ERROR.  4D produziu um documento específico para lhe ajudar a utilizar PHP XSL como uma substituição para os comandos XSLT de 4D:  Baixe XSLT com o documento técnico PHP (PDF).

Também lhe sugerimos que considere o uso de etiquetas 4D quando se trata da geração dinâmica de páginas HTML, já que na maioria dos casos é mais fácil gerenciar código HTML como texto sem formato (ver também o comando PROCESS 4D TAGS).

A compatibilidade para QuickTime (via os parâmetros do banco de dados) foi eliminada de 4D a partir de v17 R5. Os codecs de imagem relacionados com QuickTime já não são compatíveis com macOS e Windows.

A partir de v18, o tipo de campo de dados float já não é compatível com o banco de dados 4D. Este tipo de campo apenas era utilizado pelo motor SQL de 4D. Se seu banco usava um campo Tipo flutuante, ele é convertido automaticamente para Tipo real quando o banco de dados for aberto em v18 ou superior. Os datos existentes não são convertidos, a menos que compacte os dados ou volte a salvar registros.

A compatibilidade com o modo ASCII (sinônimo de "modo não Unicode") foi eliminada a partir de 4D v17 R5 e superiores. Ao abrir um banco de dados convertido que não foi definido em Unicode, 4D mostra o seguinte quadro de diálogo de alerta:

Esta alerta se mostrará em cada inicio enquanto que a opção de modo Unicode não estiver marcada na página "Compatibilidade" da configuração do banco de dados. Deve, para as estructuras convertidas, ativar o modo Unicode. O documento PDF Conversão a 4D v14 dá sugestões sobre este tema.

O formato PICT(em desuso por Apple desde 2005) já não é compatível com 4D a partir de v17 R5. Isto significa que as imagens em formato PICT não podem ser renderizadas de nenhuma maneira, devem ser convertidas.
Utilize o comando GET PICTURE FORMATS para detectar e filtrar imagens utilizando o formato PICT em seu aquhivo de dados.

Já não se admite o modo de lançamento específico para aplicações 4D monoposto na plataforma mac utilizando uma chave DatabaseOutsidePackage em info.plist. A partir de 4D v17 R5, a chave DatabaseOutsidePackage é ignorada.

Desde 4D v17 R4, 4D já não oferece compatibilidade para interfaces de direita para esquerda em Windows. As opções correspondentes já não estão disponíveis na configuração do banco de dados ou nas propriedades de formulário. Nos bancos de dados convertidos, a configuração de direita para esquerda será ignorada no momento da execução.

A partir de 4D v17 R4, os formulários de usuário estão em desuso. Para oferecer interfaces de usuário personalizáveis, agora é recomendado utilizar formulários dinâmicos (ver Formulários Dinâmicos em Manual de Desenho 4D). Todos os comandos dentro do tema "Formulários de usuário" ficaram obsoletos.

Os formulários de usuário ainda são mantidos por compatibilidade, entretanto, já não devem ser usados. Sua compatibilidade será eliminada em versões futuras

4D Mobile feature está obsoleto a partir de 4D v18 e não deve mais ser usado. Acesso aos dados 4D através de petições REST agora é compatível com tecnologia ORDA e o Servidor 4D REST.

Nas versões anteriores de 4D, o servidor web recopiava automaticamente o valor das variáveis enviadas através de um formulário web ou um URL nas variáveis 4D quando tinham o mesmo nome.

Por razões de otimização e controle, este princípio não se mantém a partir de 4D v14: o valor das variáveis Web já não se atribui automaticamente as variáveis 4D. Para recuperar as variáveis enviadas utilizando um POST ou um GET, deve utilizar o comando WEB GET VARIABLES exclusivamente.  Para recuperar as imagens enviadas, deve utilizar os comandos WEB GET BODY PART/WEB Get body part count.

Nota: a atribuição dinâmica também está desativada por padrão nas bases de dados 4D criadas a partir da versão 13.4.

No entanto, por compatibilidade, este mecanismo se mantém por padrão nas bases de dados criadas com uma versão de 4D anterior a 13.4. Neste caso, pode ser desativado o uso da opção de compatibilidade de atribuição de variável automática na página Compatibilidade das Propriedades da base.

Dado que este mecanismo é obsoleto, se recomenda desmarcar esta opção em suas bases de dados convertidas (e adaptar seu código se for necessário) com o propósito de facilitar futuras evoluções.

Em várias versões principais, 4D advertiu aos desenvolvedores em contra do uso das sub tabelas. Desde 4D v11, é impossível criar um campo do tipo sub tabela. Os sub registros têm algumas limitações conhecidas. Por exemplo, sempre se carregam em memória; não se gerenciam pelos comandos SEND RECORD ou DUPLICATE RECORD.

Não temos planos de eliminar o suporte para as sub tabelas em um futuro próximo, mas é realmente o momento de que os desenvolvedores convertam suas sub tabelas a tabelas N-> regulares porque temos a intenção de eliminar em uma futura versão principal de 4D. Os desenvolvedores que utilizam sub tabelas por razões de rendimento (algumas situações específicas nas que a carga dos registros relacionados era lenta) fiquem tranquilos, especialmente com v12: utilizar as relações N <-> 1 clássicas é bem rápido.

Basicamente, há duas formas principais para eliminar sub tabelas (nota: o seguinte não é uma tecnologia completa de ponta; só uma visão geral rápida):

• Antes da conversão de uma estrutura pre-v11: em 2004, criar a tabela N apropriada e o campo ID na tabela 1 (se não já está ali). Logo, mude o código em todas as partes se for necessário (ver mais a frente).
• Depois da conversão: nesta situação, 4D substitui a sub tabela com uma tabela N usando uma relação especial, que permite que a linguagem para trabalhar com a sub seleção e os sub registros. O desenvolvedor 4D necessita eliminar esta relação especial, substituir ela por uma relação normal e mudar o código por todas partes se for necessário (ver mais a frente).

O que queremos dizer com "mudar o código por todas partes se for necessário" é, basicamente:

• Criar os novos formulários, atualizar os formulários incluídos
• Nos métodos (projeto, formulário, objeto, etc.):
  • Substitua todos os comandos do tema "Sub registros" com o comando Selection ou Record correspondente (por exemplo, substituir CREATE SUBRECORD com CREATE RECORD, enchendo os campos ID)
  • Explicitamente carregar os registros N quando for necessário

Note: a partir de 4D v14 R3, pode atribuir valores aos campos "id_added_by_converter" especiais que se agregam automaticamente por 4D quando converte uma base de dados que contém sub tabelas. Isto lhe permite manter o link "relação sub tabela", e agregar ou modificar registros relacionados, sem necessidade de usar comandos em desuso tais como _o_CREATE SUBRECORD. Uma vez que tenha atualizado seus métodos, estas relações especiais podem ser substituídas por outros estandartes com nenhuma mudança em seu código.

O uso de números de identificação QuickDraw para designar fontes é obsoleto e não deve ser utilizado mais. Os comandos e  _o_Font name se conservam em 4D v14 por compatibilidade, mas serão eliminadas em versões posteriores. O comando OBJECT SET FONT agora só aceita nomes de fontes.

Há dois tipos de plug-ins: os que utilizam o novo plug-in API e os que seguem utilizando o velho (com QuickDraw). Para os plug-ins que utilizam a velha caixa de ferramentas (com QuickDraw): para manter a compatibilidade, o desenho/renderização já não se realiza diretamente em uma porta QuickDraw, como nas versões anteriores, mas em seu lugar através de uma área GWorld QuickDraw offscreen dedicada ao plugin.

Em consequência, há que respeitar algumas regras, como os plug-ins não devem modificar a porta atual definido pelo recipiente (objeto formulario).

Para os plug-ins que utilizam a nova caixa de ferramentas: só se utiliza esta nova caixa de ferramentas e no QuickDraw: (ver https://github.com/4D/4D-Plugin-SDK)

A partir de 4D v16 R6, APIs Mac OS 9-based para gerenciamento de arquivos e pastas ficaram obsoletos em 4D. Essas APIs já estavam obsoletas em Apple a bastante tempo.

Comandos 4D que dependem das antigas API foram renomeados: _o_Document type, _o_Document creator, _o_SET DOCUMENT TYPE, _o_SET DOCUMENT CREATOR e _o_MAP FILE TYPES.  Estes comandos são mantidos por compatibilidade, mas estão em desuso e já não devem ser usados. 4D inclui dois novos comandos para manejar nomes de rotas e extensões de arquivos: Path to object e Object to path.

Ações padrão foram internamente reformuladas em 4D v16 R3. Agora são baseadas em padrões de string e parâmetros de suporte (para saber mais, veja a seção Ações padrões).

Em suas aplicações convertidas, ações padrão são remapeadas de forma transparente ao novo design. Entretanto, na linguagem 4D, ações padrão eram previamente baseadas em valores de código. Este princípio é obsoleto e não deve mais ser usado:

• Ações padrão de texto baseado em código no tema de constante Ação estandarte  (previamente nomeado "Text Values for Associated Standard Action") são prefixados com "_o_" e não devem mais ser usados.
• Todo o tema de constante Valores para ação padrão associada está obsoleto.
• O comando _o_OBJECT Get action  (que retorna um código) agora é obsoleto e deve ser substituído pelo comando atualizado OBJECT Get action  (que retorna um nome).

Esta é outra antiga tecnologia Mac OS, em desuso desde Mac OS X 10.4 (Tiger, 2005). Os recursos se utilizam para armazenar dados estruturados, como texto e cadeias (localização), assim como também ícones, etc. Basicamente, podemos dizer que não são os recursos que estão em desuso, é seu suporte em disco, conhecido como o resource fork. O resource fork é parte do sistema de arquivos de Mac OS e desde o início de Mac OS X, Apple tratou de eliminar este suporte, já que não é compatível com outros sistemas de arquivos (Unix, Windows), e é a fonte de uma grande quantidade de problemas quando os arquivos se transferem através da rede.

Em Windows, este mecanismo se emula e os recursos Mac residem em um arquivo .RSR.

Mas ainda assim, inclusive se há ainda APIs para gerenciar os recursos (e Mac OS gerencia de forma transparente os recursos armazenados em um data fork), já não se recomenda utilizar este velho mecanismo por várias razões:

• Os textos e as cadeias são Mac-roman. Não pode ser armazenado Unicode em recursos de tipo TEXT ou STR #
• Os recursos PICT armazenam PICTs: não é moderno, obsoleto, sem transparência, etc. (Consulte o tema "PICT" acima.)
• A contagem dos recursos e o tamanho dos recursos são limitados (uns 2.700 recursos ou 16 MB)

Eliminamos suporte para comandos de escritura/criação de recursos

A grande maioria das aplicações 4D que utilizam recursos estão, de fato, utilizando recursos "Strings List", 'STR#'. 4D oferece as ferramentas para mudar facilmente do STR # a XLIFF:

• O componente 4D Pop pode criar automaticamente os arquivos XLIFF mediante a leitura e transferir o conteúdo do STR #.
• Todas as rotinas e as expressões que fazem referência a trabalho STR# sem mudança com XLIFF. Por exemplo, Se a etiqueta de um botão ou um menu era ":15000,3" (que significa "conseguir o terceiro elemento de STR# ID 15000"), 4D carregará o XLIFF apropriado (caso exista).

Para outros tipos de recursos:

• Colocar os recursos em arquivos separados dentro da pasta Resources (criar sub diretórios se for necessário):
  • Guardar recursos 'TEXT' em arquivos XLIFF ou .txt
  • Guardar recursos 'PICT' como arquivos .jpg/.png/etc. separado
  • Guardar recursos 'PICT' + MASK’ como arquivos png
  • Utilizar (em Mac) icns em lugar de ICON ou ícones de cores
  • Guardar todos os recursos privados como seja apropriado para você (normalmente: guardar como um arquivo binário com uma extensão específica)
• Utilize a pasta "Recursos" para armazenar seus recursos. Utilize Get 4D folder (pasta de recursos atuais) para obter de forma dinâmica a rota pai para seus recursos.

Modificar a prioridade da CPU é um ajuste obsoleto. A gestão de memória para as aplicações 4D foram otimizadas nas diferentes versões e é desnecessária e  pode até ser contraproducente modificar os ajustes predeterminados. Como resultado:

• A área "Prioridade da CPU" (página "Geral" da Configuração de banco de dados) se mostra agora só nos bancos de dados convertidos nas que previamente foram estabelecidos um valor personalizado. Se recomenda clicar no botão Configuração padrão neste caso para reiniciar estes parâmetros e eliminá-los do diálogo. 
• A partir de 4D v16 R2, os selectores obsoletos de comando SET DATABASE PARAMETER foram renomeados (_o_4D Remote mode scheduler, _o_4D Local mode scheduler e _o_4D Server scheduler) e já não devem ser utilizados.