Saiu um artigo meu na
Revista Clube Delphi 120 sobre
strings no Delphi 2010, como migrar, como usar, como elas funcionam e o que mudou com o Unicode.
Na verdade esse assunto daria muito mais "pano pra manga" e apenas os esboçamos. Sugiro que o leitor acesse o site do
Unicode Consortium e observe a quantidade de material que exsite por lá: desde tabelas de caracteres até algoritmos para implementar todas as novas peculiaridades que um sistema multilingue, multicaracter e "multitamanho" deve ter. Especialmente como são formados os caracteres e como são mapeados e classificados, utf8, utf16, utf32 e assim por diante.
Esqueça de vez a antiquíssima tabela ASCII com seus meros 127 caracteres mais os extendidos. As novas linguagens, principalmente as dinâmicas, já são todas unicode e essa mudança no Delphi 2010 não é só esperada como é muito bem-vinda.
Recentemente eu estava conversando com o
Marlon Nardi sobre o problema de você ter um sistema feito em Delphi 7 que usa o SQLServer e tentar migrar para o Delphi 2010. Ao tentar salvar um registro você pode receber exceptions de tipos incompatíveis: string e WideString. Isso se dá porque as strings que estão vindo para o DataSet, sejam constantes, variáveis, edits ou controles data aware já são todas widestrings, mas os TPersistentFields adicionados aos formulários não. Solução: apagar os persistent fields de todos os formularios e adicionar novamente.
Talvez ajude a agilizar se você abrir com o notepad++ todos os dfm e .pas e trocar o nome da classe antiga (TStringField dependendo da versão do delphi, do banco, do dataset/tecnologia usado) pelo nome da classe nova para lidar com widestrings (TWideStringField dependendo de um monte de fatores, claro).
O melhor a fazer seria evitar de se usar os persistent fileds e controles data aware e usar uma camada intermediária para fazer esse "meio de campo". Isso tornaria essas migrações muito mais fáceis.
Espero que gostem do artigo. Os estudantes de linguas/letras gostarão especialmente das tabelas de caracteres do site da Unicode. Lá existem até tabelas dos alfabetos élficos do universo de Tolkien, muito interessante.
Estou migrando para o Delphi 2010 e está sendo literalmente um desgraça, tudo que vc fez deve ser mudado, alguns relatórios estão com as colunas maiores, alguns erros que nunca tiveram agora aparecem do nada, simplesmente essa mudança para mim ficou uma bosta.
ResponderExcluirToda migração é difícil, não importa a tecnologia ou versão. Migrar de versão é mais fácil do que migrar de linguagem com certeza.
ResponderExcluirExiste um whitepaper muito interessante no site da embarcadero que pode te ajudar nesse processo.
São os documentos "Delphi and Unicode" e "Delphi unicode migration for mere mortals"
Na melhor das hipóteses um código bem escrito daria pouquíssimos problemas de migração, mas um código cheio de warnings e hints daria muito mais problemas.
Uma das regras máximas é: nunca assuma que um char = um byte, nem seus ponteiros ou derivados. Se você usa SQL Server os varchars são ansistrings, pois os unicode strings (nativos) são na verdade nvarchar no banco.
Se estiver muito complicado uma alternativa é refazer o sistema, aproveitando só o know how. Refazer um sistema antigo é muito importante e um exercício muito bom pelos seguintes motivos:
1) Você consegue limpar o código de firulas e funcionalidades que os usuários não usem mais.
2) Você consegue detectar bugs ou falhas de concepção/requisitos ou de projeto e corrigi-las.
3) Você não para no tempo, o que é importante.
Qualquer dúvida use o fórum da DevMedia. Vez por outra eu passo lá :)
Vitor refazer o sistema ?
ResponderExcluirVocê sempre faz brincadeiras assim ?
Ou tempo não é mais dinheiro, para quem desenvolve ou para quase todo mortal !
Ficar meses trabalhando, sem remuneração, para atender um capricho da Embarcadeiro !
Desafio e projetar e desenvolver um novo sistema, ganhando dinheiro para fazer isto.
A questão é:
Tinham que ter criado um novo tipo string, como SeílaString, e deixado o anterior compatível, o fizeram foi uma sacanagem mesmo!
Sim, refazer o sistema.
ResponderExcluirSempre faço brincadeiras assim, mas nesse caso falei sério.
Nada precisa ser mudado nas regras de negócio. Um tipo de dado ou outro, uma variável ou outra e lugares onde se usam ponteiros e alocação dinâmica de maneira errada, assumindo que 1 char = 1 byte. Esses lugares devem ser refeitos.
Aplicações são refeitas em novas linguagens a cada x anos, então porque não refazer uma aplicação em uma versão mais nova da mesma linguagem?
Já vi sistemas feitos em clipper serem refeitos do zero em Delphi 6, refeitos em Delphi 7 (trocando-se alguns componentes e todos os relatórios) e depois refeitos em .Net, ou Ruby.