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.

Explicação dos valores para a coluna “Estado”:

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.

A partir de 4D v19, os plug-ins 4D ODBC Pro não estão mais disponíveis em todas as plataformas. Recomendamos o uso do passthrough/consulta-passagem integrado ODBC/SQL (ver SQL LOGIN e Introdução aos comandos SQL) ou 4D REST API para manejar as funcionalidades de conexão de ODBC/SQL.  

A partir de 4D v19, o plug-in 4D for OCI já não está disponível em macOS. Recomendamos utilizar a consulta de passagem (passthrough) integrada ODBC/SQL (ver SQL LOGIN and Introdução aos comandos SQL) ou 4D REST API  para manejar as funções de conectividad nesta plataforma.

A partir de 4D v19, o Driver 4D ODBC já não está disponível em macOS. Recomendamos utilizar o API 4D REST para o acesso a dados externos nesta plataforma.

A opção de armazenamento Outside data file não é mais compatível com campos tipo objeto (ver Armazenado no registro). Se esta opção for selecionada para um campo, é automaticamente convertido para  In data file e usado para novos registros. Dados existentes em campos objetos é reescrito de forma transparente no novo local quando o registro pai é salvo. Para forçar que todos os registros sejam reescritos imediatamente, pode compactar o arquivo de dados com a opção  "Update records". 

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

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.

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.